Debugging memory issues in an embedded application

Question

I am new to embedded programming, but I need to debug a rather complex application running on an embedded platform. I am using GDB through the JTAG interface.

My program is unexpectedly triggering. I suppose this is due to some memory related issue. Does GDB provide the ability to check memory after a system crash, so it is completely unresponsive?

Answer 1

It depends a little on your setup. In particular, since you use JTAG, you can set your debugger to stop the processor when it detects an exception (for example, illegal access to protected memory, etc.). If not, you can replace exception handlers with infinite loops. You can then manually deploy the exception to see what the processor that caused the crash does. Usually you will have access to memory in this situation, and you can either use GDB for direct viewing, or simply dump everything into a file so you can inspect it later.

Answer 2

It depends on what crashed. If the system just doesn't respond (in some kind of infinite loop, deadlock or the like), then it usually responds to GDB, and you can see the backtrace (call stack), etc. If the system / bus / cpu actually crashed (at a lower level), then it probably won’t respond. In this case, you can try to set breakpoints in suspicious places / variables and watch what happens. Also, a simulator (ISS, RTL - if applicable) can come in handy to compare behavior with HW.