6

I'm new to embedded programming but I have to debug a quite complex application running on an embedded platform. I use GDB through a JTAG interface.

My program crashes at some point in an unexpected way. I suppose this happens due to some memory related issue. Does GDB allow me to inspect the memory after the system has crashed, thus being completely unresponsive?

Šatov
  • 323
  • 3
  • 9
  • 2
    what kind of processor are you using? – TJD Jan 03 '13 at 22:23
  • Its a 32 bit processor called icyflex1 (http://www.csem.ch/docs/Show.aspx/9224/docname/CSEM-STR08-Page%2023.pdf), and I'm using a GNU based toolchain. – Šatov Jan 03 '13 at 23:41
  • 2
    Unfortunately that doc doesn't mention anything about CPU features for debug. As Carl Norum mentions, you typically catch an exception then inspect the state of the CPU. There will be a CPU specific way for you to determine what the PC was when you hit the exception. Some processors have debug/fault status registers that will tell you things like what bad address was accessed and if it was code or data bus. – TJD Jan 04 '13 at 01:18

2 Answers2

7

It depends on your setup a bit. In particular, since you're using JTAG, you may be able to set your debugger up to halt the processor when it detects an exception (for example accessing protected memory illegally and so forth). If not, you can replace your exception handlers with infinite loops. Then you can manually unroll the exception to see what the processor was doing that caused the crash. Normally, you'll still have access to memory in that situation and you can either use GDB to look around directly, or just dump everything to a file so you can look around later.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
3

It depends on what has crashed. If the system is only unresponsive (in some infinite loop, deadlock or similar), then it will normally respond to GDB and you will be able to see a backtrace (call stack), etc. If the system/bus/cpu has actually crashed (on lower level), then it probably will not respond. In this case you can try setting breakpoints at suspicious places/variables and observe what is happening. Also simulator (ISS, RTL - if applicable) could come handy, to compare behavior with HW.

dbrank0
  • 9,026
  • 2
  • 37
  • 55