nRF5340: Access protected, MCUboot can not confirm new image

[Yanpengwu]

Hi Support Team,

I met a conflict situation. Could you help give me some guidance?

The project is based on nrf5340 and ncs V2.5.2. The device supports BLE FOTA and works well now. But after I enable the Access port protection in UICR and reboot, the application can not confirm the new image by boot_write_img_confirmed() and can not read the serial number stored in UICR OTP. So it was blocked on MCUboot and can not jump to the application...

My purpose is to support in-field FOTA, which needs both access protect enabled and FOTA/MCUboot swap. Is this possible? How can I achieve this? Thank you very much.

Best regards,
Yanpeng Wu

[Yanpengwu]

Thanks for the documentation. I did not set any AP-protect in conf, so I believe the default CONFIG_NRF_APPROTECT_USE_UICR=y was used in my project.

I found the cause of the strange behaviours above is that after enabling the AP-protect, any access to the  SWD port will hang up the MCU(it seems nrf5340 in a fault state), and the device becomes a brick unless to recover it. Reset is useless in this situation. That's why I saw the applications died early or late after enabling the AP-protect.

Is this a designed behavior of nrf5340 or a fault state? I did not find any description in the document. Could you help clarify this? Thank you very much.

[Amanda Hsieh]

Hi, 

Are you using the custom board or nRF5340DK? Is it possible for you to reproduce the issue on nRF5340DK?

I use NCS v2.5.2 peripheral_lbs with CONFIG_BOOTLOADER_MCUBOOT and CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU enabled to build and flash, then enable Access Protection: nrfjprog.exe --memwr 0x00FF8000 --val 0x00000000 --family NRF53 --force, and it can update to the new image without issue. It will reset the DK if accessing the register under the AP-protect. The error log is expected because the Access protection is enabled.

Could you test with NCS v2.5.2 peripheral_lbs with CONFIG_BOOTLOADER_MCUBOOT and CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU enabled?  

-Amanda H.

[Yanpengwu]

I'm using a custom board now, I will try it on the nRF5340DK later.

Yes, what I saw had nothing to do with MCUBoot, which worked properly, and a new image can be swapped. The trigger of the fault state is accessing the debug port after enabling AP-protect.

I believe the below steps can reproduce it on nRF5340DK:
1 Run peripheral_lbs on nRF5340DK, can see the led work and debug trace output.
2 Enable Access Protection: nrfjprog.exe --memwr 0x00FF8000 --val 0x00000000 --family NRF53 --force
3 Reconnect the debugger port (I'm using Jlink RTT Viewer, I think it is the same for other terminals, just try to access the debugger port), then the led will stop and the device bricked, even a reset is not helpful unless to recover the device.

[Amanda Hsieh]

It seems you might click "yes" to unsecure the device while using Jlink RTT Viewer to connect the nRF5340DK with Access Protection.

Then, the SWD would execute a similar nrfjprog's recover operation to erase the DK. So the LED will not blink after that. If you execute "nrfjprog --reset" at the moment, it would show

 

I select "No" to not unsecure the device, and I can see the LED is blinking even though Jlink RTT Viewer could not connect to the target.

[Yanpengwu]

Yes, I agree this is the root cause of the behaviour.
I clicked the "Remember selected action" before, so the RTT viewer unsecures the device without a reminder when connecting it.

Thank you very much:).