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

          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.

            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 replied to this.

              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.

                  • Nwre replied to this.

                    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

                        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 replied to this.
                          14 days later

                          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 🙂

                            4 days later

                            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.

                                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 replied to this.

                                    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?

                                        • Nwre replied to this.

                                          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

                                              Terms and Conditions | Privacy Policy