FOTA Sample

Nwre

Hi! I am using the http application update sample. I have seen several threads on this issue on the forum but no solution. The update is downloaded but not flashed on reset. I have added one of my favorite cursewords to the print out at the start of the program to make sure it is indeed the old program that is being loaded.

Anyone have any idea how to do this? I have been stuck with this for far too long. When looking at the partition layout for the feather it differs from the nrf9160DK, maybe that is the problem? I am a novice in all of this so excuse me if my thoughts are completely wrong.

Regards
Nwre

jaredwolff

Hey @Nwre

One thing that I’ve seen is that they’ve modified their scripts for the partition layout over the different versions of the SDK. So as I’ve been upgrading SDKs older bootloaders stopped working.

One thing you can try is if you can load the .bin file over USB first to see if it takes. If it doesn’t it’s likely that conflict. If it does then there’s something else afoot here.

Nwre

Hi Jared! Thank you for an incredible device!

To load over usb you would need a special connector no? I can flash over usb when I build projects so should I replace the app_update.bin in a active project with the one that the http app update sample is using, would that work? Does the sample work for you?

Regards and thank you for your patience with me 🙂

jaredwolff

Nwre Hi Jared! Thank you for an incredible device!

You’re welcome. 🙂

Nwre To load over usb you would need a special connector no?

All you need is a USB C cable to connect to your computer. Here’s more info on that: https://docs.circuitdojo.com/nrf9160-programming-and-debugging.html#bootloader-use

Nwre I replace the app_update.bin in a active project with the one that the http app update sample is using, would that work? Does the sample work for you?

It can be any app_update.bin file as long as it’s built for the nRF9160 Feather. I also have pre-built binaries on the Github Repo when I push changes to the samples repository. You can certainly try those as well.

Build page:

https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/actions/runs/5909295811

Download link:

https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/suites/15252732310/artifacts/871482004

Nwre

I see what you mean. I have tried this using my own versions of the .bin for the feather. It works via usb but not when downloading via aws. Not the sample nor my own code (which works on the dk) with a tested feather .bin. It downloads but upon reset, the old program is run.

jaredwolff

Hmm I know if you don’t call boot_write_img_confirmed somewhere it will fall back to the previous code. You should have a line in the application you’ve loaded in the main function that looks like:

err = boot_write_img_confirmed();
if (err) {
	LOG_ERR("Failed to confirm image: %d", err);
}

Nwre

jaredwolff I do and it is confirmed. I thought maybe it was looking at the wrong memory address when loading the new .bin since this is the only difference I have been able to find between the feather and the DK pertaining to this situation

AchimKraus

Do you call boot_request_upgrade? That offers you two options BOOT_UPGRADE_TEST and BOOT_UPGRADE_PERMANENT? And you need the “build/zephyr/app_update.bin”, no hex or something else.

Nwre

AchimKraus I am looking through the sample but I cant find that specific part. I am using the http application update sample. I have my own SPI config overlay but that shouldnt affect the sample? I tried following a thread on this forum on creating your own signing key but that didnt seem to work either.

Edit: This thread:

https://community.circuitdojo.com/d/109-aws-fota-download-successful-but-do-not-load-with-new-binary-file/33

AchimKraus

the sample

Do you have an link for me?

FOTA is in many cases split into phases.
The first is the download. Usually that’s done in a few minutes but sometimes it may take longer.
The second one is to apply the download. In order to tell the McuBoot to apply the download from the 2 slot as update to slot 1, that boot_request_upgrade and a reboot is needed.

Not sure, what you sample includes/shows, maybe only the download.

boot_request_upgrade

Nwre

AchimKraus Hi! I have been busy updating zephyr and nrf to latest version (I was using a very old one) and took a lot of time to get it running. I will get back to you after more testing 🙂

AchimKraus

OK. I’m looking forward.,
Just to mention. my own FOTA works with mfw 1.3.5, NCS 2.4.2.
I use appl_update.c and
appl_update_coap.c. I also support XMODEM. At least for Thingies:91 it’s very nice to update them over BLE with an Android device (see Cellular Explorer - Firmware update Command).

Nwre

AchimKraus

Hi! Now that I have updated the codebase I no longer download the update but I get this:

[00:00:14.169,830] <inf> download_client: Downloading: 10002.bin [0]
[00:00:14.298,492] <inf> download_client: Connecting to xxxxxxx.amazonaws.com
[00:00:14.799,438] <inf> download_client: Downloaded 2048/189728 bytes (1%)
[00:00:14.806,915] <err> dfu_target: No supported image type found
[00:00:14.813,873] <err> fota_download: Unknown image type
[00:00:14.820,190] <inf> download_client: Fragment refused, download stopped.

This is the app_update.bin file I have used for FOTA on the nRF9160DK.

I also see this when building:

[18/23] Generating ../../zephyr/app_update.bin
image.py: sign the payload
[19/23] Generating ../../zephyr/app_signed.hex
image.py: sign the payload
[21/23] Generating ../../zephyr/app_test_update.hex
image.py: sign the payload
[23/23] Generating zephyr/merged.hex

I am not sure what this means, I tried implementing secure boot on the feather but I bricked it (I think it used the wrong partition, my fault, and now it is dead 😢 ) but I got another one and removed secure boot all together, however this image.py sign the payload stuff still appears. I am a bit confused as to why and why my bin file is rejected. I will do some digging and guessing. Is your code suitable for use by me? I am using code from a previous sample where I have a common folder in my directory with certs and include a couple of files called update.

jaredwolff

Nwre what exactly are you doing when renaming it to something else? It’s named 10002.bin not app_update.bin. When comparing this file to the file built, are they same size/same contents? Maybe you can outline your steps of how you’re building and placing the files on AWS S3? You may find your mistake in the process 😃

Nwre

jaredwolff Hi!

Yes, when I want to update the device it looks in a directory on my server for a .txt file called patch. If it exists, it reads the content of that file (the filename) and looks for it on the aws-cloud. What I added there as a test is the same program I use but with a simple printout loop in main instead of all my different threads and what have you. It’s the app_uppdate.bin from build/zephyr but renamed. This part has worked before when I’ve tried this, it used to download the file and on the DK, actually reboot with the new program. Before updating the feather to latest version, it downloaded the file but did not use the program upon restart. Now it says invalid fragment.

Edit: Yes the file sizes are the same. If I use it with newtmgr build command and specify the file, it works fine.

AchimKraus

From your information, I guess you want to perform a mcuboot based update. You may check the subsys/dfu/dfu_target/src/dfu_target_mcuboot.c

bool dfu_target_mcuboot_identify(const void const buf)
{
/ MCUBoot headers starts with 4 byte magic word */
return *((const uint32_t *)buf) == MCUBOOT_HEADER_MAGIC;
}

so, the file you download must start with these 4 bytes.

For some reasons, it doesn’t. That reasons may be, that you upload the wrong file to S3, or download the wrong file. Not sure, if it’s possible for you, but maybe you can check the first 4 bytes of the file in S3?

Nwre

AchimKraus

I checked and it seems correct. Also, there is only one file in the aws repo, I tried giving it a name that didnt exist and the response is different than that of a name that does exists. So it find the file, tries to download it but refuses. Might this have something to do with this “image.py: sign the payload” that I see when building? I can’t remember every seeing that before I started to fiddle with securing the bootloader but now I can’t get away from it.

Here is a pic of the byte comparisson
https://ibb.co/vx0Z0Fv

Nwre

Hi guys, I got it working. I followed this thread:

https://devzone.nordicsemi.com/f/nordic-q-a/91180/nrf9160dk-fota-using-external-flash-ncs-2-0-2

Thank you very much for your help and happy coding, brothers!