Bootloader from SDCard

[warcomeb-am]

Hi, 

I need to add to my project that uses NRF5340 a bootloader that reads new firmware from SDCard. Is there an example where I can find information? Someone has just encountered this kind of issue and can tell me some tips?

Thanks

Marco

[Vidar Berg]

Hello Marco,

I'm not aware of any SDK examples that demonstrate DFU via a SD card, unfortunately. Have you considered other supported alternatives such as DFU through BLE or USB?

Best regards,

Vidar

[warcomeb-am]

Hi Vidar,

thanks for the reply. The customer wants to maintain the same behaviour of the previous version of the project (without Nordic device), where the new firmware was stored into SDCard and at reset, the bootloader read the hex from the sdcard, copies the application, removes the file and reboot the device with the new application. Some tips?

Best regards,

Marco

[Vidar Berg]

Hi,

Provided you have enough internal flash, I think the easiest approach might be to have the application load the binary image from your SD card into the MCUBoot's secondary slot (Ref., Image slots, Disc access), then let MCUBoot activate the update on the following reboot by moving the update image from the secondary to the primary slot. Another alternative may be to modify MCUBoot to support serial recovery from an SD card (serial recovery is currently supported through USB/UART).

Best regards,

Vidar

[warcomeb-am]

Dear Vidar Berg ,

During this time I worked on the other parts of the applications, but now it's time for me to finish the application with the bootloader! 

Just to understand better, the code that I need to add to my application is:

• the user copies the file app_update.bin into SDCard
• the application copies the contents of the file into the image_1 region by using the flash_* function
• At the reboot, the bootloader copies the contents of image_1 into image_0 by itself

now the application is updated, right?

Best

Marco

[Vidar Berg]

Dear Marco,

Yes, this should work. The bootloader will check if a new FW update is available in the secondary slot on boot. If there is, it will proceed to copy the image into the primary slot and boot the new application.

Best,

Vidar

[warcomeb-am]

Dear Vidar,

Yesterday I implemented this solution but seems not work.
The firmware copy the file into image_1 without any errors, but when the microcontroller reboots the firmware is not updated. The output is:

*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Hello from AM Microsystems!

Do I need to add something to notify the new firmware to mcuboot? 

Best

Marco

[Vidar Berg]

Dear Marco,

The magic word should be set to "good", not "unset", if the secondary image has been stored correctly. 

As a test, can you try to program the 'app_moved_test_update.hex' with nrfjprog without going through the SD?

$ nrfjprog --program build/zephyr/app_moved_test_update.hex --sectorerase --verify --reset

Another thing is to check if the start address used to store the update candidate in flash matches the secondary address shown in the 'memory report'.

Best,

Vidar

[warcomeb-am]

Hi Vidar, 

By using the nrfjprog the update works:

*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: revert
I: Starting swap using move algorithm.
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Hello from AM Microsystems!

I also checked the address and it is correct. Why doesn't work with SD? Maybe need I to enable some flag after copy the firmware?

Best

Marco 

[Vidar Berg]

Hi Marco,

Can you read the memory content in the secondary slot after loading it from the sd card and after programming the .hex to see if there is any difference? 

$ nrfjprog --memrd <secondary slot start address> --n <size of secondary slot in bytes > secondary_slot.txt

Best,

Vidar

[warcomeb-am]

Hi Vidar, 

sorry, I need to fix my last answer: yes, I can send the new firmware by using your command into the second partition and mcuboot recognize it (the code of my last answer), but the firmware is not updated! 

Anyway, I try to read the secondary partition and the two version differ only on the last 256Byte. But I don't know why!

Best,

Marco

[warcomeb-am]

Hi Vidar,

Sorry again, but there is something strange: after a firmware update correct (only with your method, not by SD), the microcontroller start with a string that print the new version value... but after a reset a new firmware update was performed without my command and turn back to the first version. What is it wrong? The log is the following.

*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Hello from AM Microsystems!
Version: 1.0.1

update from usb by using nrfjprog

*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Hello from AM Microsystems!
Version: 1.0.5

... application running

*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: revert
I: Starting swap using move algorithm.
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
Hello from AM Microsystems!
Starting SGuideV3 from VOX
Version: 1.0.1

application running

By SD no magic word was set!

Best,

Marco

[Vidar Berg]

Hi Marco,

After the image was copied from the SD card to the secondary slot, did you run boot_set_pending()? This marks the image as a pending update, which includes writing of the magic word.

warcomeb-am said:

but after a reset a new firmware update was performed without my command and turn back to the first version.

MCUBoot will revert the update if the image is not confirmed as the hex file contains a "test" image. You can read more about the different swap types here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/design.html#boot-swap-types.

To make a "test" image permanent, you can call boot_set_confirmed() from the new app.

Best,

Vidar