We are developing using LPC1768, we using a number of subsystems, TCP, SD card, SPI.
For some reason that we don’t understand occasionally we have some failure in the software that causes the system resets itself.
My question is what mechanism we could use to log the reason of the failure? we need to know at which precise moment the software failed so we could examine that after and correct the issue.
Thank you.
Processors seldom resets themselves after a failure. They instead tend to enter an exception handler.
Do you happen to use a watchdog? So you get a watchdog reset because your program isn't able to kick the watchdog anymore?
So output enough telemetry/diagnostic information about the state of the system via a serial port, and connect it to a terminal and have that record the information to a file.
Increase the level of information as you focus in on the cause.
As Per suggests, it could be a watchdog, presumably you can see that as a cause at reset.
Understand the flow of your code, and how it might have arrived at the failure condition.
Thanks everyone, the issue is that the failure is very random and difficult to reproduce, and we don’t have a serial connection plugged all the time so it is difficult to get continuous and detailed information flow about the progress of the program.
We could try to keep some log in the flash.
The watchdog is an option but we also want to get to the bottom of the issue, so we don’t want to mask it.
I know this is wishful thinking but is it there any black magic, i.e. register that could contain information about what caused the failure?
Best regards
Here is something you can try: Let the program fail. Configure uv4 to attach to process as JTAG is enabled: don't reset on startup, don't update binary while debugger startup and something else (I don't remember...). Then, load your .axf file using the console. If the binary is built using debug information, you will have a stack trace. Other that that you can try using a trace buffer that is not reset upon startup, and insert markers as the program runs, or send out the value of the link register after a crash via UART (assuming it still works...). There are many many other ways.
I used this technique in the part with ULink, and even nowadays - debugging a raspberry pi remotely (no JTAG) with gdb allows similar operations with remarkable success.
View all questions in Keil forum