This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Debug Assert Handler

The documentation says "This module is ONLY for debugging purposes and must never be used in final product". I know in an ideal world all possible errors are handled and device is able to recover from any erroneous state. But in the real world it would be nice to have an assertion handler that in an unexpected situation would log the error into persistent memory (ble_error_log_write) and reboot device.

Are there any other considerations that would prevent me from using Debug Assert Handler in the final product?

NB: ble_error_log_write still is not fully implemented

  • @Pektusin: Due to the fact that flash activity that blocks the CPU can cause BLE connection to be timed out. We blocked the direct access to NVMC peripheral when the softdevice is active.

    So when you are in a assert handler and the softdevice is active. It's not possible to write to flash, even with softdevice API because the API requires lower context priority level.

    So what you can do is either printing the error log out on UART, or store them somewhere in RAM and set a flag. Then when you are back in the main context, you can check if the flag is set, you can disable softdevice and access NVMC directly to store the log to flash from RAM.

  • Thanks Hung for your comment. Yes, I know that there are complications related to the flash activities and if I ever will implement it, I'll do it in an app task. However, my question is more about the Debug Assert Handler itself. Looks like Nordic doesn't recommend to implement it in the final product at all, so I was wondering about the reasons.

  • @Pektusin: Our idea of production release vs debug release is that, when in production release, we prioritize that the device should be able to recover (by a reset) after it hits a bug other than staying in a dead loop just to make sure the bug would not go unnoticed.

  • Hello . I apologize for raising this dead thread, but what if in release mode the Error_checks just freeze the MCU without reseting? I'm having trouble with that... No difference between release and debug versions...

    Thanks!

Related