SDKV12 Unconditional breakpoint in NRF_LOG_FINAL_FLUSH()

[Keton]

While getting myself familiar with new SDK12 features I've noticed that when nrf_log uses deferred logging to RTT NRF_LOG_FINAL_FLUSH() results in unconditional breakpoint.

This looks like not so good idea because as the documentation states this function should be used just before system reset in error handler. Instead code execution stops regardless if there's debugger connected or not. This could easily lead to situation where the board will hang forever instead resetting on error.

What was rationale of coding it this way? Or maybe I'm doing something wrong?

[Krzysztof Chruscinski]

You are right, but on the other hand it is placed only if RTT is used as log backend. Enabling RTT logging makes sense only when you have debugger connected. We will look if it's feasible to check for debugger connection and only then do the breakpoint.

[Keton]

As RTT is computationally cheap (only writing bytes to RAM buffer) we leave it on in limited scope on our release builds so field team has a quick way of diagnosing the errors. Also please note that there's no breakpoint in case of nrf_log using UART so it's confusing and more clear advice in the documentation would be appreciated.

Also for example in case of hard fault handler the breakpoint is conditional (only when debugger is attached) and disabled by default unless DEBUG_NRF is defined. This way developer has more fine grained control over what's happening and code is safe for release by default.

This mode of action would be way better for all SDK code - don't prohibit corrective action (execution of app_fault_handler) in case of error unless developer explicitly wants so. Less surprises, less chance of error.