nRF5340: Access protected, MCUboot can not confirm new image

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

Parents Reply Children
  • 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.

  • 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

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

  • 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.


Related