-1

In embedded software, when the firmware crashes in the system, is there a way you can get access to something like crash dumps in desktop applications?

I want to use that information to know the CPU and registers state just at the moment that firmware has crashed.

doubleE
  • 1,027
  • 1
  • 12
  • 32
  • 2
    This can't really be answered universally. The normal way would be to hook it up to a debugger with trace, but then your hardware needs to support trace. Other than that, you'd cook up your own error handler, which can be done in numerous ways. – Lundin Dec 03 '18 at 07:40
  • 1
    "crash dumps" are created by software. You cannot "access" a crash dump if you have not implemented support for that (or are not using an OS that supports it). Critically the software has to be able to know it has crashed in order to issue the dump. That is possible through the use of exception handlers - if supported by the hardware. That is to say, you have to write the dump as an exception handler - and then using resources that are likely to still be working an available to the exception handler - typically unbuffered output. – Clifford Dec 03 '18 at 19:19

1 Answers1

1

Depending on the controller you are using, there are multiple bits which can tell you the reset cause of your controller. In most cases this will not tell you anything about the source of your problem in the application.

All controllers will jump to a Hardfault Handler after for example a null pointer exception. During debugging you might be able to inspect the call stack to find out about the source of the exception.

Every other information you want to have which is available in a desktop application must be programmed by yourself. For example you can try to safe your processor stack to some non-volatile memory before resetting the controller.

A.R.C.
  • 910
  • 11
  • 22
  • Can I find out program counter, then use that to look in map file to see which function has caused it? Code is not a debug mode so it doesn't have any symbol information, unless I compile a debug rmode and load it to system, and wait for it to crash. But then that's not the real code... – doubleE Dec 03 '18 at 08:02
  • 1
    You can store the program counter and look into your disassembly to find out about the current function. Look at this link, maybe it can give you some tipps on what information is needed for hardfault debugging: https://nathan.vertile.com/blog/2016/05/04/stm32-hardfault-debugging/ – A.R.C. Dec 03 '18 at 08:48
  • 2
    "All controllers will jump to a Hardfault Handler after for example a null pointer exception" - that's so very wrong. There are many more than ARM-based MCUs (and even a lot of those won't hardfault for accessing address `0` -including those using an MPU). – too honest for this site Dec 03 '18 at 14:03