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?

[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.