• State Not Answered
  • Replies 5 replies
  • Subscribers 65 subscribers
  • Views 162 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 330239
Options

DFU on NRF54L15

dcaskey

Using the Nordic NRF54L15 as part of the nRF54L15-PDK(v0.7.0).

I am working on enabling and experimenting with adding mcuboot and enabling DFU support via BLE.

I have done this for our own application and managed to get this building sucessfully. I am also able to successfully transfer an image via BLE DFU and get that successfully stored on the device. I am able to `test` the image and also `confirm` the image so that my DFU image becomes the running image.

This is done using the `mcumgr web` client.

So far so good, but the issue comes when I want to do the second OTA with an updated image, It seems that there is an issue with preparing/erasing the secondary slot to get ready for the new incoming image.

[00:00:45.438,810] <err> flash_sync_mpsl: timeout
[00:00:45.438,828] <err> mcumgr_img_grp: image slot erase of 0x3c000 bytes failed (err -116)

I suspected that I had gone wrong somewhere in my configuration and decided to use the already provided sample located at:

`zephyr/samples/subsys/mgmt/mcumgr/smp_svr`

At this stage I also enabled the external FLASH by using the following command:

west build -b nrf54l15pdk/nrf54l15/cpuapp deps/zephyr/samples/subsys/mgmt/mcumgr/smp_svr -p -T sample.mcumgr.smp_svr.bt.nrf54l15pdk.ext_flash

Which comes from here, my only deviation from this is that there is an extra layer with the `deps` folder.

This also builds and runs fine, takes the DFU via BLE and can accept the new image, but I also get the same problem on the second DFU attempt with the error shown above.

This is using NCS v2.7.0-rc2

It is using sysbuild, and it is using partition manager.

Any ideas or thoughts on what might be going wrong here, or am I missing something that I should be doing?

Thanks

Parents
  • 0

    Hello,

    Sorry for the delay in getting back to you.

    Technically, you do not need IMG_ERASE_PROGRESSIVELY on the nRF54L15 because of the use of RRAM. Unlike the older FLASH-based NVM controller, the RRAM controller does not require the area to be erased before writing.

    Therefore, it is safe to disable IMAGE_ERASE_PROGRESSIVELY for the nRF54L15, as it is not necessary for RRAM. Ideally, the erase function should be ignored altogether in this context.

    The correct approach would be to avoid erasing and only overwrite data. However, I am unsure of how this is implemented, as the RRAMC integration into Zephyr was not handled by our team.

    Kind Regards,

    Abhijith

Reply
  • 0

    Hello,

    Sorry for the delay in getting back to you.

    Technically, you do not need IMG_ERASE_PROGRESSIVELY on the nRF54L15 because of the use of RRAM. Unlike the older FLASH-based NVM controller, the RRAM controller does not require the area to be erased before writing.

    Therefore, it is safe to disable IMAGE_ERASE_PROGRESSIVELY for the nRF54L15, as it is not necessary for RRAM. Ideally, the erase function should be ignored altogether in this context.

    The correct approach would be to avoid erasing and only overwrite data. However, I am unsure of how this is implemented, as the RRAMC integration into Zephyr was not handled by our team.

    Kind Regards,

    Abhijith

Children
No Data
Related