Serial DFU with nRF9160 as DFU controller

RE: Serial DFU with nRF9160 as DFU controller

esisk — Thu, 26 Aug 2021 18:02:32 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Thu, 26 Aug 2021 12:29:45 GMT

[quote userid="2115" url="~/f/nordic-q-a/78203/serial-dfu-with-nrf9160-as-dfu-controller/326765#326765"]This makes a difference on the max. size of the partitions. The mcuboot_primary size must match the mcuboot_secondary partition size.[/quote]

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.

[quote userid="2115" url="~/f/nordic-q-a/78203/serial-dfu-with-nrf9160-as-dfu-controller/326765#326765"] 0 is success, and if you are able to run this function on the updated device; it means that the image was booted.[/quote]

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.

[quote userid="2115" url="~/f/nordic-q-a/78203/serial-dfu-with-nrf9160-as-dfu-controller/326765#326765"]Could you please be explicit on which nRF-device is being updated, and is calling this function?[/quote]

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.

[quote userid="2115" url="~/f/nordic-q-a/78203/serial-dfu-with-nrf9160-as-dfu-controller/326765#326765"]Can you please share some logs / debug info related to your current scenario?[/quote]

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!

RE: Serial DFU with nRF9160 as DFU controller

Håkon Alseth — Thu, 26 Aug 2021 11:57:07 GMT

Hi,

[quote user="esisk"]Yes, I'm actually using a nRF52820 but shouldn't make a significant difference. [/quote]

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

[quote user="esisk"]But it does not on boot and I actually just get a 0 error from boot_write_img_confirm() which is very confusing.[/quote]

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Wed, 25 Aug 2021 15:10:47 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Wed, 25 Aug 2021 14:06:22 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Wed, 25 Aug 2021 13:58:41 GMT

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.

RE: Serial DFU with nRF9160 as DFU controller

Håkon Alseth — Wed, 25 Aug 2021 13:45:16 GMT

Hi,

[quote user="esisk"]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[/quote]

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Wed, 25 Aug 2021 13:21:02 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

Håkon Alseth — Wed, 25 Aug 2021 13:10:39 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Wed, 25 Aug 2021 12:49:47 GMT

I flashed it directly and the update worked as expected

RE: Serial DFU with nRF9160 as DFU controller

Håkon Alseth — Wed, 25 Aug 2021 12:25:52 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Tue, 24 Aug 2021 13:18:14 GMT

Hey Håkon,

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

RE: Serial DFU with nRF9160 as DFU controller

Håkon Alseth — Tue, 24 Aug 2021 10:09:25 GMT

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

RE: Serial DFU with nRF9160 as DFU controller

esisk — Mon, 23 Aug 2021 14:12:24 GMT

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?

RE: Serial DFU with nRF9160 as DFU controller

Håkon Alseth — Tue, 17 Aug 2021 13:35:29 GMT

Hi,

As a generic note, I must express that this is a proof-of-concept implementation which is not feature complete, and it's provided as-is.

[quote user="esisk"]I see that app_update.bin is tagged with a magic header at the beginning, and a uart magic header is added in order to trigger the uart dfu. I know you're not too familiar with this code, but do you happen to know anything about generating magic headers when app_update.bin is created? I want to understand how to add a custom magic header so when I port over this code, I can utilize the dfu_target library[/quote]

Here's the logic check for application, modem delta, and full modem (more types to come if required):

https://github.com/nrfconnect/sdk-nrf/blob/v1.6.1/subsys/dfu/dfu_target/src/dfu_target.c#L43-L57

Normally you would use "imgtool.py" to generate the correct magic headers for the app update binary, but since this tool also uses this in the rest of the image, it is easier just to manually replace the first bytes with the uart magic header.

This is the uart magic: https://github.com/plskeggs/sdk-nrf/commit/6baf0e006299bb69152cf3fb7e690985cdcbcb3b#diff-fc58c71f2315c9f063d8c3bd4b43e9aa7fd0e8b42c6cef8d4a8962f56e6144ebR9

Here's an example on how it should look in the binary itself (build/zephyr/app_update.bin):

For mcuboot to accept the image, the header must be swapped back again from "uart type" to mcuboot:

https://github.com/plskeggs/sdk-nrf/commit/6baf0e006299bb69152cf3fb7e690985cdcbcb3b#diff-f4ac7128bd5b4b1b90b816602b814f6235fac82e3f67d8fc437b222a261cb7b4R167-R174

This is to work around the restriction of the dfu_target library, which does not support "sub-types" of mcuboot-images (ie: targetting internal, external, transport A, transport B, etc).

Kind regards,

Håkon

RE: Serial DFU with nRF9160 as DFU controller

esisk — Thu, 12 Aug 2021 16:59:25 GMT

I see that app_update.bin is tagged with a magic header at the beginning, and a uart magic header is added in order to trigger the uart dfu. I know you're not too familiar with this code, but do you happen to know anything about generating magic headers when app_update.bin is created? I want to understand how to add a custom magic header so when I port over this code, I can utilize the dfu_target library

RE: Serial DFU with nRF9160 as DFU controller

esisk — Thu, 12 Aug 2021 15:04:55 GMT

Thanks!

RE: Serial DFU with nRF9160 as DFU controller

Hung Bui — Thu, 12 Aug 2021 15:01:40 GMT

I would suggest to try testing the code with v1.4.0 first and after you get it running, you can study the code and try to port it to v1.5.1.

I'm not very familiar with the code but I think it's better to try step by step.

RE: Serial DFU with nRF9160 as DFU controller

esisk — Thu, 12 Aug 2021 13:46:33 GMT

Thanks Hung, do you think trying to use this code is going to be an issue if we're using NCS v1.5.1?

RE: Serial DFU with nRF9160 as DFU controller

Hung Bui — Thu, 12 Aug 2021 10:54:16 GMT

Hi Ethan,
You should clone it to the NCS v1.4.0.

Or you can look at these 2 commits to know what has been modified:
https://github.com/plskeggs/sdk-nrf/commit/6baf0e006299bb69152cf3fb7e690985cdcbcb3b

https://github.com/plskeggs/sdk-nrf/commit/4c276b8107e003a3083b9ba17569d768670d39f2

RE: Serial DFU with nRF9160 as DFU controller

esisk — Wed, 11 Aug 2021 19:52:36 GMT

When building this, should I clone the repository into my current ncs directory? I have it cloned outside right now and getting issues with west build

RE: Serial DFU with nRF9160 as DFU controller

esisk — Tue, 10 Aug 2021 13:14:59 GMT

Yes, both links take me to the same place

RE: Serial DFU with nRF9160 as DFU controller

Hung Bui — Tue, 10 Aug 2021 13:12:23 GMT

Hi Ethan,
Isn't the lte_uart_dfu.c located inside \lib\lte_uart_dfu here: https://github.com/plskeggs/sdk-nrf/tree/feature-uart-dfu-v1.4.0/lib/lte_uart_dfu

RE: Serial DFU with nRF9160 as DFU controller

esisk — Tue, 10 Aug 2021 13:11:26 GMT

Nevermind, I found the file here: sdk-nrf/lib/lte_uart_dfu at feature-uart-dfu-v1.4.0 · plskeggs/sdk-nrf (github.com)

RE: Serial DFU with nRF9160 as DFU controller

esisk — Tue, 10 Aug 2021 12:55:34 GMT

Thanks for the link Hung. Is there a way for me to view the source code for lte_uart_dfu.c? I can't find it in the repo and this precooked sample is not useful for me since I'm using a custom board and not DKs.