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]

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

[esisk]

Also, not sure if this makes a difference, but I'm using an overlay config for MCUBoot. Would that affect functionality somehow?

[Håkon Alseth]

Hi,

 

esisk said:

Yes, I'm actually using a nRF52820 but shouldn't make a significant difference.

 This makes a difference on the max. size of the partitions. The mcuboot_primary size must match the mcuboot_secondary partition size.

esisk said:

But it does not on boot and I actually just get a 0 error from boot_write_img_confirm() which is very confusing.

 0 is success, and if you are able to run this function on the updated device; it means that the image was booted.

Could you please be explicit on which nRF-device is being updated, and is calling this function? What you are stating now indicates that you have both booted and not booted the new firmware.

 

Can you please share some logs / debug info related to your current scenario?

 

Kind regards,

Håkon

[esisk]

Håkon Alseth said:

This makes a difference on the max. size of the partitions. The mcuboot_primary size must match the mcuboot_secondary partition size.

Yes I understand this. I'm testing the ability to perform a DFU on the nRF52820 given our board constraints, so I'm attempting this with a simple hello world program. There should be more than enough flash space on the 820 to successfully do this.

Håkon Alseth said:

 0 is success, and if you are able to run this function on the updated device; it means that the image was booted.

I understand; I'm confused because the hello world print statement should be different if I do not receive an error code from this function because MCUBoot would have booted the new application with a different print statement.

Håkon Alseth said:

Could you please be explicit on which nRF-device is being updated, and is calling this function?

I am downloading the file with the nRF9160. There is a UART connection between the 9160 and an nRF52820. The 9160 receives a 2KB fragment of the update, sends it via UART, the 820 receives the fragment and uses the dfu_target_mcuboot library accordingly. This process repeats until the last 2KB fragment has been downloaded and transmitted to the 820, and at this point, the 820 calls dfu_target_mcuboot_done(true) and reboots.

Håkon Alseth said:

Can you please share some logs / debug info related to your current scenario?

Here are print statements generated by the dfu_target library. The print statement "err is 0" corresponds to the return value generated by boot_write_img_confirmed(), "init err" is from dfu_target_mcuboot_init, "write err" is from dfu_target_mcuboot_write(), and the offset of the update is printed before every write.

*** Booting Zephyr OS build v2.4.99-ncs2 ***
00> err is 0
00> Hello there, this is main app :)
00> init err: 0
00> offset: 0
00> write err: 0
00> offset: 2048
00> write err: 0
00> offset: 4096
00> write err: 0
00> offset: 6144
00> write err: 0
00> offset: 8192
00> write err: 0
00> offset: 10240
00> write err: 0
00> offset: 12288
00> write err: 0
00> offset: 14336
00> write err: 0
00> offset: 16384
00> write err: 0
00> offset: 18432
00> write err: 0
00> offset: 20480
00> write err: 0
00> offset: 22528
00> write err: 0
00> offset: 24576
00> write err: 0
00> done err is 0
00> *** Booting Zephyr OS build v2.4.99-ncs2 ***
00> err is 0
00> Hello there, this is main app :)

Thanks for your help Håkon!

[esisk]

I actually figured it out. There was an issue with how I was interpreting the stop of the UART transmission. I was using a string to denote start and stop of transmission, but those strings are explicitly defined in my file so when app_update.bin is compiled, the actual stop and start strings were being put into the binary file. Whenever my parse function encountered the magic stop in the .bin file being sent over, it interpreted that as end of transmission when there was actually more of the file to write. So I just used the reverse of the magic stop string (computed at runtime) to avoid this issue. After that, the DFU worked as expected