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]

 At the beginning of application main(), there is 

    int rc = boot_write_img_confirmed();

Without FOTA and Enable access protect, the MCUboot should be able to run the application, but seems the system will hangs on the calling of boot_write_img_confirmed()

[Amanda Hsieh]

Hi, 

Access port protection should do nothing at all, it just means that a debugger cannot access the flash, the internal access of flash should always work the same.

Yanpengwu said:

Without FOTA and Enable access protect, the MCUboot should be able to run the application, but seems the system will hangs on the calling of boot_write_img_confirmed()

You can refer to this https://github.com/nrfconnect/sdk-nrf/tree/v2.5.2/samples/cellular/smp_svr. Add CONFIG_UART_CONSOLE=n to  child_image/mcuboot.conf, and the sample can run on the nRF5340DK.

Regards,
Amanda H.

[Yanpengwu]

Hi Amanda,

I agree that the Access port protection only applies to debugger/SWD access. But what I see is very strange.

Maybe the error was not caused by MCUboot. I simplified the test as:
(1) Removed all logic in my applicaiton, just keep a led flash and debug trace to see if the application is alive.
(2) MCUboot enabled, but not do the upgrade, just compile and flash in VS code through JLink.

The result:
(1) Flash the application. It works well, I can see the led flash and log trace.
(2) Run the below code in Power Shell to enable Access Protection:
          nrfjprog.exe --memwr 0x00FF8000 --val 0x00000000 --family NRF53 --force
(3) I can see a pause on LED flash and log trace, after about 20 to 30 seconds, it resumes as normal.
(4) I reset the device and let Access protect take effect. At this moment, the behavior is very strange: I can see the led flash for 10 seconds, then it stops and the application dies.
After the reset, no log trace, this is the expected behavior of access protection enabled.

Is it correct to enable the access protection in the above way? Why is the behaviour so strange?
Thank you very much.

Best regards,
Yanpeng Wu

[Yanpengwu]

I'm using ncs V2.5.2, how to set Access protection in the application code?

[Amanda Hsieh]

See the Enabling access port protection mechanism.

[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:).