Hi guys!
I’ve moved most of the Kia Soul code from V2 to V3. I set the vehicle module and everything is just fine, until I connect it to my car. Then the Kia module crashes. I can’t make out why looking at the little info it prints out.
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?
Hope someone has a simple guide for a noob like me 😜 Thanks!
Geir
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.
-- SteveThanks a lot, Steve! Great explanation :-)
I’m using Mac, so please send the binary and library.
Best regards, Geir
- nov. 2017 kl. 23:03 skrev Stephen Casner <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 http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
- 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
Nice! This is just what I needed. Thanks Mike and Steve! 🙂
Geir
- nov. 2017 kl. 23:20 skrev Michael Balzer <dexter@expeedo.de>:
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
- 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 <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 <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Oh, and when you are finished with exploring a crash, use the "quit" (abbreviated "q") command to exit gdb, then it will tell you something about abandoning the process to which you answer "y", and then the python monitor code presents four options for re-flashing, etc. For me the most reliable response at that point is just to hit return which causes the device to be rebooted, then I either try another test at that point or use the buttons on the device to put it back into download state.
-- SteveOn Wed, 22 Nov 2017, Stephen Casner wrote:
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
participants (3)
-
Geir Øyvind Vælidalo -
Michael Balzer -
Stephen Casner