How to avoid NRF faults after breakpoints?

[jcondon]

As most developers using Nordic's SoftDevice quickly find out, halting the processor (e.g. hitting a break point) results in a fault and requires a reboot. This makes debugging on Nordic's platform infuriating. Yes, we can use RTT or constantly restart your code, but that takes lots of time and doesn't provide the visibility required to quickly diagnose issues.

Knowing that I'll get undefined issues with BLE functionality, is there anyway to temporarily disable the SoftDevice's watchdog functionality when I'm debugging other areas of my code? Perhaps by manually changing the RTC0 parameters? 

[haakonsh]

No, not really. But there is another way. 

Monitor Mode Debugging allows you to halt all CPU activity below a set execution priority, by jumping into an ISR with an endless loop. The SoftDevice will have a higher execution priority and will preempt this ISR, but the application will not. Segger has implemented a feature where it will execute this blocking ISR whenever it reaches a breakpoint or is halted via Jlink driver commands from your IDE. Though you will need a license for this feature, you can try it out for free. 

Check out our tutorial on MMD https://github.com/NordicPlayground/j-link-monitoring-mode-debugging. 

[jcondon]

It looks like that code is written for the SES and Keil/ARM compiler... is there a version that is meant for the GCC compiler?

[haakonsh]

You can ask Segger for the necessary files. Porting it is not that hard. You can read my tutorial for an explanation for how it works and do the necessary porting. Segger can also help you get it set up.

I've done so myself, but I don't have the time to work on the MMD tutorial for the next few weeks. 

[jcondon]

Heads up to everyone reading this in the future, GCC file extensions are case sensitive. The SES version incorrectly uses ".s" where GCC requires it to be ".S" to compile

[haakonsh]

Thank you! Good to know.