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@acm.org <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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