Attachments (8) Download All
Nordic Case Info
  • Case ID: 341912
Options

Simultaneous DFU on nrf5340 and NCS 2.9.0 without external flash

blue_dew

Hello,

I am using NCS 2.9.0, an nRF5340, custom board files (see attached), and no external flash and I would like to use simultaneous DFU over BLE. I believe this should be possible because my application core image is only ~118kB and my netcore image is ~175kB (it has a custom synch protocol on top of the hci icp logic). I've done my best to read through the intermediate dev zone academy lessons regarding the mcu bootloader and it mentions that simultaneous updates should be possible without external flash:

but then links to this devacedmay blog post that only shows how to do this utilizing external flash. I believe it should be possible because in my mind I see the following: 


Where mcu primary is the app core code that is currently running, mcu secondary is where the new app core code goes, and mcu secondary_1 is where the new netcore code goes when an application update happens. So I have tried to add the following pm_static.yml file:



The names are bit different than my diagram but I followed the advice of other similar posts and documentation regarding DFU and copied a build partitions.yml file from one of my successful builds. I have also added the following configs to my sysbuild.conf:



Added these two lines to my prj.conf:



Do I need to set configs for utilizing flash even tho there is no external flash? When I build with the above configs I get the following errors:



I'm not sure how to proceed because I'm having a hard time understanding what these pm_static.yaml file names are supposed to be and I'm not getting the same sort of errors as these previous related posts:

- simultaneous DFU on nRF5340 and NCS 2.6.1 without external flash
- nrf5340 custom board non-simultaneous updates without external flash with sysbuild on ncs2.7.0+

---
I know from the "Official Simultaneous multi-image DFU with nRF5340 DK" docs that I need to have the following partitions:
1) mcuboot_primary
2) mcuboot_secondary
3) mcuboot_rimary_1
4) mcuboot_secondary_1
5) pcd_sram 

and I see the note regarding the placement of mcuboot_primary_1 inside of ram_flash region but I don't understand the second comment about "CONFIG_FLASH_SIMULATOR" within the docs. I'm having a hard time understanding how to get this running because I'm not even hitting the errors I would expect to hit. Instead I'm getting stuff related to the partition_manager.py scripts' arguments... 
---

Do I need to setup a pm_static.yaml file for my custom netcore image too? I don't think so from the docs but I can't find the exact reference that makes me think this but I'm asking just in case. 

---
I utilize the following shared memory overlay within my code base and I don't think I'm correctly partitioning for it within my pm_static.yaml file:

Can you help with this too? It is the only reason I think that adding a partition file for the network core might be needed in addition but I'm really not sure. 

Thank you so much for all of your help and time. 

Respectfully,
Brady Adcock

Parents
  • 0

    Hello,

    I’m currently working on the peripheral_lbs sample to enable simultaneous DFU without external flash. However, I will be away after tomorrow, so I’m not sure if I’ll be able to provide you with the required updates before then.

    In the meantime, you can refer to the following PR for guidance: https://github.com/nrfconnect/sdk-mcuboot/pull/397.
    I recommend cherry-picking the relevant commit. Otherwise, you’ll need to manually create a PM static file.

    Kind Regards,

    Abhijith

  • 0 in reply to Menon

    Hey Menon,

    I'm really looking forward to this example! Thank you so much for helping me. 

    Respectfully,
    Brady 

  • 0 in reply to blue_dew

    Hi,

    I will continue to help with this ticket.

    I do not know if you have updated to the nRF Connect SDK v3.0.0 yet. But even so, try this on the git tag v3.0.0-rc1 in order to test the following:

    Try the sample l9_e5_nrf5340_both_sol from DevAcademy on DFU in v3.0.0-rc1. I based this academy sample on the Peripheral_lbs sample.

    In v3.0.0-rc1 you should be able to just change SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY to "n" in this sample, and simultaneous DFU should work for internal flash

    Let me know how this goes

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hello Sigurd,

    Thank you for your time. I have tried building the sample you linked using the tag v3.0.0-rc1 and I am having no luck. Can you please share the build command you used? Here is what my build looks like:



    Maybe I need a different toolchain too not just SDK? Here is my build log: 

    Fullscreen 2604.build.log Download

  • 0 in reply to blue_dew

    Just what you did, but for the nRF5340dk/nrf5340/cpuapp.

    Can you  try to build for the DK instead, just to see if there is a difference?

Reply Children
  • 0 in reply to Sigurd Hellesvik

    Hey Sigurd,

    Thank you so much for the help!!! The example builds for the secure version of the nrf5340dk but it doesn't actually allow for updates of the network core regardless of external flash use. I have tried every bin file I can find within my build folder and I'm having no luck. I am pretty sure the correct bin file is the "zephyr.signed.bin" file but maybe I'm mistaken. The example updates the app core as expected but not the network core :(

    Here is what my build config looks like now: 


    This is a list of all the bin files created by the build:


    Here is the error I get after updating over the air:


    No matter if I use external flash or not I get the "Failed to open flash area ID 1: -1" message which I believe is the network core flash. I really appreciate your time and effort. Thank you so much Sigurd. 

    Regards,
    Brady

    For some more context, I'm modifying the ipc_radio application within the directory: "C:\ncs\v3.0.0-rc1\nrf\applications\ipc_radio". I know this is correct because when I manually flash the changes the network core logs update as expected but when I try to use the DFU feature from my mobile application I don't see the changes I expect to my logs on the network core and instead see the error posted above. Here is an example of the logs updated on the net core after manually flashing:


    Except it doesn't work :(

  • 0 in reply to blue_dew

    Try follow steps explained in https://academy.nordicsemi.com/simultaneous-updates-for-both-cores-of-the-nrf5340/, where you upload dfu_application.zip instead.

    If you were to use single files: zephyr.signed.bin for app core and signed_by_mcuboot_and_b0_ipc_radio.bin. However, this should go to "image slot 1", in difference of the normal appcore.

    blue_dew said:
    or some more context, I'm modifying the ipc_radio application within the directory: "C:\ncs\v3.0.0-rc1\nrf\applications\ipc_radio".

    Yes, this is good.

    blue_dew said:
    No matter if I use external flash or not I get the "Failed to open flash area ID 1: -1" message which I believe is the network core flash.

    The nRF5340 DFU procedure uses two slots:

    1. mcuboot_secondary_1. This is a slot in app flash for storing the update candidate for the netcore.

    2.mcuboot_primary_1: This is a slot in app RAM used to simulate the netcore flash, for when we will transfer it.

    For mcuboot_primary_1, reading this simulated flash can fail, which can cause the error message you see without being an issue in itself.

  • 0 in reply to Sigurd Hellesvik

    Thank you so much!!! I feel so silly for not remembering that from the guide but I'm so happy to see the sample functional without the use of external flash memory. Y'all are the best. 

    Before I close out the issue, I'm going to verify functionality within my application. I'm thrilled, though!!! 

    Regards,
    Brady

Terms of service