store error infomation

[Jim]

      Hello! I occasionally have a crash during the development of nrf52832 (SDK14.2), but this phenomenon is not very reproducible. All the information about the error that I want to  stored in the built-in flash of nrf52832. After restarting, the error message is sent to the mobile phone through BLE. These issues include:
1. Problems caused by APP_ERROR_CHECK
2. Problems caused by HardFault_Handler

Is there any relevant routine reference, what should I do? Thank you!

[tesc]

Hi,

Depending on what best fits your need, here are some suggestions:

1) If you set the DEBUG preprocessor define, then the fault handlers will enter infinite loops on error, at which point you can read out the details from within a debug session.

2) Also with DEBUG set, in case you cannot do all the testing in a debug session, it may be possible to connect after-the-fact and read out the stack frames, depending on the debugger. This may also be possible manually, through the use of nrfjprog to read out memory contents, although tedious.

3) You can change the fault handlers, so that they write the details to a region in non-initialized RAM. To do that in SES you can use the section(".non_init") attribute, like this:

static char error_info[128] __attribute__((section(".non-init")));

The trick is that RAM is not reset on soft reset, and so you can read the error from RAM on startup. It may be wise to also add a flag indicating that a value has been written to the error_info array, that you clear once it is handled. Even better you can use a crc field, that you clear once the error info is handled.

If you use this approach, make sure that the fault handler does not enter an infinite loop. (By default it will enter infinite loop if DEBUG is set.)

4) Depending on when/where the error occurs you may be able to write to flash directly from the error/fault handler, but since you cannot use supervisor calls (SVCs) from within the handler this will not be possible if the SoftDevice is still enabled. (As then NVIC calls must go through the SoftDevice API, and even disabling the SoftDevice requires a SoftDevice call, using SVC.)

Regards,
Terje

[Andy]

What do you mean with you can't use SVC calls from within the handler in #4? Why? I implemented this for my application and it works fine. I'm not expecting it to be reliable in case of a SoftDevice fault, but at least on other errors it's working good I think.

I only tested by forcing errors by deliberately writing APP_ERROR_CHECK(NRF_ERROR_INTERNAL), and the error was successfully written to flash from the error handler.

If it doesn't work all the time, fine, but some logs are better than none.

[tesc]

Hi,

Sorry for not being precise in my previous response. It would of course work for the APP_ERROR_CHECK, but AFAIK it would not for the hardfault handler.

Regards,
Terje

[Andy]

Ok that makes sense. I wouldn’t expect it to work with HardFaults. 

[Jim]

Thank you very much for your prompt response. I still have a problem. What information does it need to save after a HardFault_Handler error? And how can you find out where the problem is based on this information?