Serial DFU with nRF9160 as DFU controller

[esisk]

I'm downloading a firmware image from AWS via cell onto the nRF9160. I want to perform a serial DFU over UART. The DFU target is the nRF52840. Are there any existing samples outlining this process?

[Hung Bui]

Hi Ethan, 

Could you let me know more about what firmware running on the nRF52840 ? 
If it's running NCS , please have a look at this case: https://devzone.nordicsemi.com/support-private/support/269959

ould you try to test using the repo that Simon pointed to in the case. 

Simon is on vacation  but here is the instruction I got from him: 

• cd into <..>\nrf\samples\other\test_lte_uart_dfu_lib and run
  • west build -b nrf52840_pca10090 && west flash
• Set SW5 to nRF91
• cd into <..>\nrf\samples\nrf9160\http_application_update and run
  • west build -b nrf9160_pca10090ns && west flash
• Wait till you see the following log from the 9160: "Press Button 1 to start the FOTA download", then press Button 1 on the 91 DK
• When you see the log "UART DFU transmission complete" in the log from the 9160 and the logging from the 52840 stops up (I forgot to enable log on the 52840 side signifying that the DFU was finished) do the following:
  • Set SW5 to nRF52
  • Press the RESET Button on the 91 DK
• If everything works as expected, you will see the following log:

Text

 *** Booting Zephyr OS build v2.1.99-ncs1 **

[00:00:00.120,208] [1B][0m<inf> mcuboot: Starting bootloader[1B][0m

[00:00:00.126,312] [1B][0m<inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3[1B][0m

[00:00:00.136,108] [1B][0m<inf> mcuboot: Boot source: none[1B][0m[00:00:00.141,479] [1B][0m<inf> mcuboot: Swap type: test[1B][0m

[00:00:02.377,655] [1B][0m<inf> mcuboot: Bootloader chainload address offset: 0xc000[1B][0m

[00:00:02.385,162] [1B][0m<inf> mcuboot: Jumping to the first image slot[1B][0m

** Booting Zephyr OS build v2.1.99-ncs1 ***Hello world! nrf52840_pca10090

[esisk]

Hey Hung, I am downloading the image and sending it over UART successfully; however, the image does not seem to be loaded correctly on reboot. I changed the labels in my board file as described here: Building and using MCUboot with Zephyr — MCUboot 1.7.99 documentation (nordicsemi.com) Is there something obvious I'm missing?

[Håkon Alseth]

Both your original firmware, and the "app_update.bin" firmware must share the exact same partition layout.

You can find this in the build folder of your original project under application-v1/build/partitions.yml. Copy this to application-v2/pm_static.yml and rebuild.

 

Kind regards,

Håkon

[esisk]

Hey Håkon,

Thanks for your response. Followed your instructions and still not updating. Any other common issues that I'm missing?

[Håkon Alseth]

Hi,

 

Try flashing the build/zephyr/app_test_update.hex directly to the device you're updating. This will show if the configuration that mcuboot expects is followed in the new application image.

 

Kind regards,

Håkon

[esisk]

I flashed it directly and the update worked as expected

[Håkon Alseth]

What is the error message that you get? Do you have a debug trace or similar?

Is your new update image calling "boot_write_img_confirmed()" ?

 

Kind regards,

Håkon

[esisk]

The strange thing is I get no error message. No I don't have a trace, but whenever I print the error messages from dfu_target_mcuboot library functions, I get 0s. Yes I'm calling boot_write_img_confirmed(). EDIT: Ok double checked and I am not getting any errors from dfu_target_mcuboot functions but I am getting -5 as an error from boot_write_img_confirmed() on reboot. EDIT 2: printed the value returned by boot_set_confirmed() and it is -4 which stands for BOOT_MAGIC_BAD

[Håkon Alseth]

Hi,

 

esisk said:

I am not getting any errors from dfu_target_mcuboot functions but I am getting -5 as an error from boot_write_img_confirmed() on reboot

This is on the nRF52840 side, right? Does this mean that it boots the image successfully, but is not able to verify itself, meaning that it will revert back after a reset?

 

Could you please share the uart log?

 

Kind regards,

Håkon 

[esisk]

Yes, I'm actually using a nRF52820 but shouldn't make a significant difference. Anyway, I assume it means that it boots the image successfully and reverts but not entirely certain. Currently, I cannot enable UART logging for MCUBoot because it interferes with the UART communication between the 9160 and 820 during the DFU process which is strange. I assume it has something to do with the UART queue having data still in it from the MCUBoot log, not sure on this though. Maybe if I flushed the queue I could see the log and communicate between the two chips successfuly, but I can't find anything in the docs about flushing the queue using NCS EDIT: I actually don't think that it's trying to boot the new image at all. I set CONFIG_UART_CONSOLE=n on the current image, then changed that to y, reloaded the project in SES and rebuilt, and put the new app_update.bin on AWS. So if MCUBoot was actually trying to boot the new image it would show the MCUBoot header right? But it does not on boot and I actually just get a 0 error from boot_write_img_confirm() which is very confusing.

[esisk]

Is there maybe an issue with pm_static.yml not lining up with the flash partitions I defined in our board file? The partitions.yml file generated in the build directory (which is what I made pm_static) does not really make sense to me