NRF52 RBP (Readback protection) unexpected behavior

RE: NRF52 RBP (Readback protection) unexpected behavior

Sigurd — Tue, 20 Mar 2018 14:38:04 GMT

Hi Farhang,

Thank you for this bug report. I see the same behavior as you describe. This is not the intended behavior and it have been reported internally. I will let you know when a new version with a fix have been released.

Best regards,

Sigurd

RE: NRF52 RBP (Readback protection) unexpected behavior

Farhang — Fri, 02 Mar 2018 17:56:21 GMT

It is permanently halted.

So you're saying that "nrfjprog -f nrf52 --rbp ALL" already performs a debug_reset at the end?
What is your source of information? I tried to find the source code for nrfjprog but no luck yet.

RE: NRF52 RBP (Readback protection) unexpected behavior

Simen August Tinderholt — Fri, 02 Mar 2018 14:27:57 GMT

Hi, is the device permanently halted, or does it come back after a while?

Although it is not strictly necessary for readback_protect, it halts the device to ensure data integrity while writing.

The procedure is finalized with a debug_reset to load the changes, this should also have released your device.

RE: NRF52 RBP (Readback protection) unexpected behavior

Austin — Thu, 01 Mar 2018 11:40:11 GMT

One way that setting RBP might affect the running program is due to timing for flash writing. The NVM controller will need to be active to write RBP in flash and this could conflict with uses of the NVM controller in your own application. Additionally, if you're running the SoftDevice during programming of RBP, since the SoftDevice is no longer in control of flash writes made through the SWD port, timing constraints within the SoftDevice may no longer be met and cause a fault. The SoftDevice usually carefully times flash writes with knowledge of other events in the system, but it cannot control writes from external interfaces like SWD.

Nordic engineers may have more suggestions.

RE: NRF52 RBP (Readback protection) unexpected behavior

Farhang — Wed, 28 Feb 2018 17:36:37 GMT

Austin,

Thanks for the info. However I still want to understand why writing to readback protect (sometimes) causes my program to halt or stop from running. I couldn't find an answer to that in your response.

And because you have a pin reset following your RBP you haven't noticed this issue.

Although I can confirm at my desk that having the reset after the RBP will recover the device, I need someone from the Nordic design team to explain how setting the RBP might affect the program running in the core, possibly.

RE: NRF52 RBP (Readback protection) unexpected behavior

Austin — Wed, 28 Feb 2018 11:05:26 GMT

My experience is with the nRF52840 rather than the NRF52832QFAAB0, but I think the devices are similar. The comments here relate to the nRF52840 and you can compare to see if they are relevant for your situation.

Setting read back protection via the APPROTECT register only disables one component of debug port access. The CTRL-AP port remains functional even when protected. See 'Debug and Trace' section in the objective specification. This makes sense, since there still needs to be functioning component accessible via SWD which is capable of accepting an ERASEALL type command to unprotect the unit. The CTRL-AP is also capable of issuing device resets.

I've attempted to perform a similar process for setting APPROTECT for production and the following procedure works for me when using the Python pynrfjprog API.

# Start the processor before applying readback protection so that CPU
# is operational and running directly after protection is applied.
self.nrfjprog.halt()
self.nrfjprog.debug_reset()
self.nrfjprog.go()

self.nrfjprog.readback_protect(API.ReadbackProtection.ALL)
self.nrfjprog.pin_reset()