[Ovmsdev] Debugging

[Michael Balzer]

Also google "gdb cheat sheet" for some helpful command overview PDFs.

If you cannot use "make monitor" or had the module disconnected from USB when the crash occurred, you can attach gdb to the crashed module like this:

xtensa-esp32-elf-gdb -ex "set serial baud 115200" -ex "target remote /dev/ttyUSB0" -ex interrupt build/ovms3.elf

(replace the device by your USB serial device, path is relative to Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3)

Regards,
Michael


Am 22.11.2017 um 23:10 schrieb Geir Øyvind Vælidalo:
> Thanks a lot, Steve! Great explanation :-) 
>
> I’m using Mac, so please send the binary and library. 
>
> Best regards,
> Geir
>
>> 22. nov. 2017 kl. 23:03 skrev Stephen Casner <casner at acm.org <mailto:casner at acm.org>>:
>>
>> On Wed, 22 Nov 2017, Geir ?yvind V?lidalo wrote:
>>
>>> I see some of your are talking about gdb-stub, but I have never used
>>> gbd and need some help.
>>> How do I debug? What options do I have?
>>
>> Happy to help with that.  To use the gdb-stub you change the parameter
>> in menuconfig / Component Config / ESP32-specific / Panic handler
>> behavior / Invoke GDBStub.
>>
>> When the crash occurs, you'll be presented with a "gdb>" command
>> prompt.  You can find references for "gdb commands" online.  Here is
>> one:  http://www.yolinux.com/TUTORIALS/GDB-Commands.html
>>
>> The first command I would expect you will want is "bt" which displays
>> a stack backtrace telling in which function each call is made,
>> including the source line number.  The frames on the stack are
>> numbered; you can give the command "frame N" where N is a frame number
>> to change to the context of that frame, since the lowest one might not
>> be the place where things started to go wrong.
>>
>> When you're at the right frame, you can use the "print" command to
>> look at the value of variables.  If variable foo is a pointer, you can
>> say "print *foo" to display the contents of the object foo points to.
>> In many cases this will be enough to figure out the problem.  I also
>> use the "x" command to examine memory by address in various ways.
>>
>> You can also use the "list" command to see a few lines of source code
>> around the point in the code referenced by that stack frame.  Usually
>> I just look at my source in a separate window.
>>
>> When using gdb on a real computer you can set breakpoints before
>> starting the program, but I have not learned whether that is possible
>> to do with the ESP32.
>>
>> As I mentioned in one of the emails, if you are running on a Mac you
>> should use the gdb binary that I made which references the newer
>> libiconv library in order to avoid gdb getting stuck in an infinite
>> loop.  If so, let me know and I'll send the binary and library to you.
>> If you are running on a different platform, you should check to see
>> what version of libiconv DLL (Windows) or shared library (Linux) is
>> referenced.  On my Mac the new one is 9.0.0 vs. 7.0.0.  The old one is
>> usable, but you have to be careful not to give any command that might
>> result in gdb tryinging to display a variable value that has non-ASCII
>> chars.
>>
>>                                                        -- Steve
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171122/186de82d/attachment.htm>