Software updates with Device Manager App

Hello Team,

we are using Device manager app update to test software updates.

Q1. After choosing the update, there is an option to choose between image0(main), image 1,image 2, and image 3.. I tried to to do software update with image 0 and image1. Both Works.  What is actually the goal/need of this option  ? what does it do  ?

Q2. there is a "Permamanen flag" showed in the App. As far as I know,MCU boot knows only about bootable,pending and confirmed flags.
I have noticed that the Permananet flag is set to true when the image set to "Confirm". What is goal/need of this permanent flasgs ? does MCUboot use this anyway ? 

Q3. I see that the SMP BLE services and characteristics are hardcoded in Zephyr subsys source code. Is it always constant for SMP protocol ? Can we change this and use our own UUIDs ? 

Regards

Adarsh

Parents
  • Hi Adarsh, 

    Q1. Could you let me know where you click to get the Images listed ? My understanding is that if you have multiple images in the .zip file you can select which image you want to do DFU update. For example if you have MCUBoot image or if you have network core image. 

    Q2. There is a permanent swap option as mentioned here: https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/design.html#boot_swap_types . My understanding is that it's the same as when you do confirm instead of test. 


    Q3. The UUID for SMP server is fixed. But you are free to use your own UUID instead of SMP. Of course in that case the nRF Device Manager app won't work.  You will need to implement your own app or modify Device Manager to work with the new UUIDs. 


    I will try to get the app developer to comment here in case my understanding is not correct. 

  • Hi Hung,

    Q1. First I choose the "Advanced" option in the App.then I click on the "Select File" in the "Firmware Upgrade" section in the app. then i choose the app_update.bin for software update . Then I click "start" button.After this a popup window opens as seen in the screenshot.

     Q2. Ok thanks its clear

    Q3. Does that mean that wealso need to change the zephyr source code ? I dont see any Kconfig to change the UUID.

    Regards

    Adarsh

  • Hello,

    Let me answer in more details. 

    Q1. Some devices have multiple images that must be sent for the DFU to succeed. This is a case in nRF53 (which has app core and net code) or for nRF54H (with SUIT bootloader, where additional images can be sent as cache partitions). The drop-down lets you specify the "image" parameter, as a plain .bin file is missin this information.

    The "Basic" view allows you to select a ZIP file, which usually includes a manifes.json file with metadata for each binary. This metadata contains the "imageIndex" field which is set automatically in that case.

    If your device has just one core and doesn't support other images, this parameter most probably isn't even read, so whatever value would you set, it will work. The app doesn't "know" what device you're connected to, so it can't filter out this list or skip showing.

    Q2. Each image in a "slot" contains set of flags. Each one has a meaning, and they are far from obvious, so I understand your confusion. The "pending" flag is set when a Test or Confirm commands wers sent and the image isn't "active". It means, that on the next reboot the MCUboot will swap/apply this image and make is "active". The "permanent" flag means, that after swap/apply this image will be marked as permanent - that won't be reverted after subsequent reboot. This is the different between Test and Confirm commands. First one sets only "pending" flag, while the other both. The "active" flag means, that the device is currently running this image. The "confirmed" flag (not to be associated with Confirm command) means, that the MCUboot confirmed this image as valid, and it can become "active" (or something like that). "Bootable" should be more or less clear.

    Q3. These UUIDs are hardcoded both in Zephyr / mcumgr /SMP subsystem and in mobile apps. You're free to modify but you need to modify mobile libraries/apps to be compatible.

Reply
  • Hello,

    Let me answer in more details. 

    Q1. Some devices have multiple images that must be sent for the DFU to succeed. This is a case in nRF53 (which has app core and net code) or for nRF54H (with SUIT bootloader, where additional images can be sent as cache partitions). The drop-down lets you specify the "image" parameter, as a plain .bin file is missin this information.

    The "Basic" view allows you to select a ZIP file, which usually includes a manifes.json file with metadata for each binary. This metadata contains the "imageIndex" field which is set automatically in that case.

    If your device has just one core and doesn't support other images, this parameter most probably isn't even read, so whatever value would you set, it will work. The app doesn't "know" what device you're connected to, so it can't filter out this list or skip showing.

    Q2. Each image in a "slot" contains set of flags. Each one has a meaning, and they are far from obvious, so I understand your confusion. The "pending" flag is set when a Test or Confirm commands wers sent and the image isn't "active". It means, that on the next reboot the MCUboot will swap/apply this image and make is "active". The "permanent" flag means, that after swap/apply this image will be marked as permanent - that won't be reverted after subsequent reboot. This is the different between Test and Confirm commands. First one sets only "pending" flag, while the other both. The "active" flag means, that the device is currently running this image. The "confirmed" flag (not to be associated with Confirm command) means, that the MCUboot confirmed this image as valid, and it can become "active" (or something like that). "Bootable" should be more or less clear.

    Q3. These UUIDs are hardcoded both in Zephyr / mcumgr /SMP subsystem and in mobile apps. You're free to modify but you need to modify mobile libraries/apps to be compatible.

Children
No Data
Related