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);
}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
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.
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:
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.
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 
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).
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.
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 
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.
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?
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
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!
