nRF5340: Access protected, MCUboot can not confirm new image

RE: nRF5340: Access protected, MCUboot can not confirm new image

Yanpengwu — Tue, 15 Apr 2025 16:17:26 GMT

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

RE: nRF5340: Access protected, MCUboot can not confirm new image

Amanda Hsieh — Tue, 15 Apr 2025 15:38:14 GMT

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.

RE: nRF5340: Access protected, MCUboot can not confirm new image

Yanpengwu — Tue, 15 Apr 2025 06:45:53 GMT

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.

RE: nRF5340: Access protected, MCUboot can not confirm new image

Amanda Hsieh — Mon, 14 Apr 2025 15:15:43 GMT

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.

RE: nRF5340: Access protected, MCUboot can not confirm new image

Yanpengwu — Mon, 14 Apr 2025 06:57:16 GMT

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.

RE: nRF5340: Access protected, MCUboot can not confirm new image

Amanda Hsieh — Fri, 11 Apr 2025 20:12:50 GMT

See the Enabling access port protection mechanism.

RE: nRF5340: Access protected, MCUboot can not confirm new image

Yanpengwu — Fri, 11 Apr 2025 12:11:18 GMT

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

RE: nRF5340: Access protected, MCUboot can not confirm new image

Yanpengwu — Fri, 11 Apr 2025 11:14:24 GMT

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

RE: nRF5340: Access protected, MCUboot can not confirm new image

Amanda Hsieh — Thu, 10 Apr 2025 16:32:27 GMT

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.

[quote user="Yanpengwu"]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()[/quote]

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.

RE: nRF5340: Access protected, MCUboot can not confirm new image

Yanpengwu — Thu, 10 Apr 2025 09:30:45 GMT

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()