jaredwolff

Thanks for reply.

you’re talking about the line here?

MQTT AWS Jobs FOTA Sample, version: v2.0.1

Yes, I defined it in prj.conf. And I changed to a different tag before build the new binary and upload to S3, just as a indicator for different firmware.

Depending on how that version is included in your project, you may need to use the -p flag. I often need to use the -p flag for my OTA updates since I grab my version # from git describe.

Can you explain a little bit on the -p flag, I am new to it.

Additionally, it also may be rejecting your OTA package. Are you able to update the image using newtmgr and see the output change?

I guess it may be poor signal, I try with another successful download, but still same result.
I do uploaded through newtmgr, with the v2 bootloader. In case I do something wrong, I use the programmer in nRF Connect to write the v2 bootloader before I erase all, then use newtmgr to load flash the bin file.

Thanks,
Zirun

      zirunhong Can you explain a little bit on the -p flag, I am new to it.

      zirunhong when building you can run west build -b circuitojo_feather_nrf9160ns -p This will clean your build directory. This is useful to make sure that your changes to the version have propagated correctly.

            jaredwolff
            I see. I try with your suggestion, but it still with the same result.

            I noticed from the instruction, the ota download has the erasing process, like this:

            [00:02:03.748,931] <inf> download_client: Downloaded 135168/201232 bytes (67%)
            [00:02:03.794,494] <inf> fota_flash_block: Erasing sector at offset 0×00021000
            [00:02:04.893,188] <inf> download_client: Downloaded 139264/201232 bytes (69%)
            [00:02:04.938,720] <inf> fota_flash_block: Erasing sector at offset 0×00022000
            [00:02:05.933,013] <inf> download_client: Downloaded 143360/201232 bytes (71%)
            [00:02:05.978,546] <inf> fota_flash_block: Erasing sector at offset 0×00023000

            While mine only show the download percentage:

            I: Downloaded 155648/181118 bytes (85%)
            I: Downloaded 157696/181118 bytes (87%)
            I: Downloaded 159744/181118 bytes (88%)
            I: Downloaded 161792/181118 bytes (89%)
            I: Downloaded 163840/181118 bytes (90%)
            I: Downloaded 165888/181118 bytes (91%)
            I: Downloaded 167936/181118 bytes (92%)
            I: Downloaded 169984/181118 bytes (93%)
            I: Downloaded 172032/181118 bytes (94%)
            I: Downloaded 174080/181118 bytes (96%)

            It might be the SDK or library is different. Do you have any suggestions?

            Zirun

              zirunhong I do uploaded through newtmgr, with the v2 bootloader. In case I do something wrong, I use the programmer in nRF Connect to write the v2 bootloader before I erase all, then use newtmgr to load flash the bin file.

              To be clear here, were you able to update your application using newtmgr where the version number changes? i.e. the only place where you don’t see change is using FOTA?

                  @zirunhong also are you using an example with LittleFS enabled? You may have to comment out lines 3-7 in pm.yml.file_system (located in nrf/subsys/partition_manager/pm.yml.file_system)

                  #include <autoconf.h>

##ifdef CONFIG_FILE_SYSTEM_LITTLEFS
#littlefs_storage:
#  placement: {before: [end]}
#  size: CONFIG_PM_PARTITION_SIZE_LITTLEFS
##endif

                  I originally had to comment this out to give as much space to the application firmware as possible. Since there is an external flash, this is not necessary.

                  jaredwolff

                  To be clear here, were you able to update your application using newtmgr where the version number changes? i.e. the only place where you don’t see change is using FOTA?

                  Correct, using newtmgr to update my application with different hardcoded version number works, but not on FOTA

                  also are you using an example with LittleFS enabled?

                  Yes, I are using the LittleFS, but we use the external W25Q32JV on the feather board, will that be affected?

                  Zirun

                      zirunhong it’s possible since CONFIG_FILE_SYSTEM_LITTLEFS will be activated. Can you try commenting out those bits and trying again?

                          I would attempt to confirm that the image you’re uploading on AWS is the image you expect. I recommend you take a second look at how you’re uploading the images. I’ve made the mistake previously, after building on a clean project, uploading the wrong image all along.

                          Also if you can copy the outputs from upgrading newtmgr here. That way we can confirm you are indeed getting the updated code. Also you may have to post the code that you’re using to generate the version #s.

                            jaredwolff
                            Hi,

                            Here is the output from newtmgr:
                            PS C:\Users\Zirun\ncs\v1.5.0\reliance_app\nrf9160_aws_fota> newtmgr -c serial image upload build/zephyr/app_update.bin
                            176.88 KiB / 176.88 KiB [========================================================================================================================================================================================================================================================================] 100.00% 13.74 KiB/s 12s
                            Done

                            Here is how I defined version #:
                            prj.conf:

                            CONFIG_APP_VERSION="v2.0.1"
CONFIG_USE_CLOUD_CLIENT_ID=y
CONFIG_CLOUD_CLIENT_ID="nrf9160"
CONFIG_MQTT_BROKER_HOSTNAME="a2v611xt1xntep-ats.iot.ca-central-1.amazonaws.com"
CONFIG_PROVISION_CERTIFICATES=y
CONFIG_CLOUD_CERT_SEC_TAG=20210101

                            The main.c is exact the same as the aws_fota sample_.

                            I have confirmed that I have changed the CONFIG_APP_VERSIONto “v2.0.2” and build with -p tag and upload the app_update.bin to s3 bucket.

                                zirunhong I have confirmed that I have changed the CONFIG_APP_VERSIONto “v2.0.2” and build with -p tag and upload the app_update.bin to s3 bucket.

                                Can you see that you’re updating your device using the bootloader over USB that it’s also updating to v2.0.2? It’s important to confirm this locally before you upload.

                                Also, how does your device know which image to pull? How you know if it’s pulling the correct one?

                                    5 days later

                                    jaredwolff

                                    Hey, sorry for reply late.

                                    Can you see that you’re updating your device using the bootloader over USB that it’s also updating to v2.0.2? It’s important to confirm this locally before you upload.

                                    Yes, I try changing the hard-coded version to “v2.0.2” and using printk() to verify it.

                                    Also, how does your device know which image to pull? How you know if it’s pulling the correct one?

                                    Hmm..that’s something I don’t fully understand, on the instruction of aws__fota sample, it says:

                                    The sample then retrieves the firmware image over HTTP and replaces the current firmware with the downloaded firmware.

                                    I guest it may have a way in bootloader to distinguish it?

                                    Also, I tried in this way: instead of using v2 bootloader and newtmgr, I use the debugger to program the device (west flash --runner nrfjprog). Then I changed the hardcoded version, build with -p tag, upload the app_update.bin to S3 bucket, following the same process of FOTA, and in next reboot after fota download complete, it loaded with the new firmware from S3 (according to the hard-coded version using printk()). I wonder if it is because of the v2 bootloader? Do you have any comment/suggestion on it?

                                    Thanks!
                                    Zirun

                                        zirunhong I don’t have any further suggestions. Looks like it’s working now though? If not, I would carefully read the instructions related to FOTA. It’s important you indicate the correct image in. S3 for it to work. (I recommend removing the old images when you’re done with them.)

                                            4 days later

                                            jaredwolff
                                            It is working now when uploading the hex file. However, another problem came out, I cant use newtmgr to upload the firmware. When I try to enter DFU mode by holding MODE button and tap RESET button, it didn’t looks like entering the DFU mode, and newtmgr -c serial image upload build/zephyr/app_update.bin doesn’t work. I have the CONFIG_BOOTLOADER_MCUBOOT=y in my prj.conf

                                                zirunhong make sure with v2 that you’re holding the MODE button and tapping the RST. Let go of the MODE once you have a blue LED. I added a delay in the bootloader so the device wouldn’t accidentally go into bootloader mode in some operating edge cases.

                                                    jaredwolff

                                                    Hi, thanks for reply.

                                                    I have try with the instruction and still the same. I have no problem with uploading the bin file with your v2 bootloader.

                                                    My concern is when I use my our bootloader, it doesn’t go to DFU mode. First, my understanding is, when compiling the application with CONFIG_BOOTLOADER_MCUBOOT=y in prj.conf, there will be a bootloader firmware/image being created, this should be the hex file in /build/mcuboot/zephyr/zephyr.hex . Please correct me if I am wrong.

                                                    Then for application, we can use newtmgr to flash the app_update.bin to the board. The bottle neck I have here is, my bootloader firmware doesn’t allow the board into DFU mode, which I cant flash the binary file for the application.

                                                    Thanks,
                                                    Zirun

                                                        zirunhong My concern is when I use my our bootloader, it doesn’t go to DFU mode. First, my understanding is, when compiling the application with CONFIG_BOOTLOADER_MCUBOOT=y in prj.conf, there will be a bootloader firmware/image being created, this should be the hex file in /build/mcuboot/zephyr/zephyr.hex . Please correct me if I am wrong.

                                                        That’s slightly correct. When CONFIG_BOOTLOADER_MCUBOOT is selected it will generate a file call merged.hex which will contain the bootloader. zephyr.hex alone on the nRF9160 will not work. You’ll always need a merged.hex. (I believe it’s generate whether or not the bootloader is enabled.)

                                                        zirunhong these two statements seem to contradict each other:

                                                        I have no problem with uploading the bin file with your v2 bootloader.

                                                        The bottle neck I have here is, my bootloader firmware doesn’t allow the board into DFU mode, which I cant flash the binary file for the application.

                                                        Can you explain what you mean? You’re able to use newtmgr but not load via AWS FOTA? If I were you I’d compile and run the provided SDK examples and follow Nordic’s instructions explicitly. Make sure you can do it with unmodified code an then work on getting your own firmware working with it as well.

                                                              jaredwolff

                                                              Hi thanks for your reply. Sorry for the confusion.

                                                              Can you explain what you mean? You’re able to use newtmgr but not load via AWS FOTA?

                                                              There are two different tries, compiling is fine, no error:

                                                              1. Using your v2 bootloader source here, then I go into DFU mode with the instruction and flash app_update.bin with CONFIG_APP_VERSION="v1.0.0", using newtmgr -c serial image upload build/zephyr/app_update.bin.
                                                                Code works, download the app_update.bin with CONFIG_APP_VERSION="v2.0.0". Then restart and still print “v1.0.0” on the USB console, which shows the firmware running on the board is not updated.

                                                              2. I use nRF Connect v3.6.1 - Programmer to erase the device first. Then I use flash the merged.hex under /build/zephyr after seeing your reply using west flash. However, I cant enter the DFU mode, but code works, download the app_update.bin with CONFIG_APP_VERSION="v2.0.0". Then restart and still print “v2.0.0” on the USB console, which shows the firmware is updated. I try to enter DFU mode and it still cant access. I have followed the instruction on entering DFU mode.

                                                              I wonder if it is the difference in bootloader causing the problem. If so, what makes it different, clearly there is nothing on the example source code related to bootloader setting or DFU setting, plus they are using the same source code.

                                                              If I were you I’d compile and run the provided SDK examples and follow Nordic’s instructions explicitly. Make sure you can do it with unmodified code an then work on getting your own firmware working with it as well.

                                                              So I am using the AWS_fota example. I didn’t chang anything from the source code, except for adding few configurations in prj.conf:

                                                              # FOTA config
CONFIG_APP_VERSION="v1.0.0"
CONFIG_USE_CLOUD_CLIENT_ID=y
CONFIG_CLOUD_CLIENT_ID="nrf9160"
CONFIG_MQTT_BROKER_HOSTNAME="a2v611xt1xntep-ats.iot.ca-central-1.amazonaws.com"
CONFIG_PROVISION_CERTIFICATES=y # I also upload my AWS certificate in 'certificate.h'

                                                              Thanks
                                                              Zirun

                                                                  zirunhong hmm thanks for the details. So it looks like FOTA and loading via USB does not work. Since they both don’t work that makes a bit more sense.

                                                                  By the way, when you load merged.hex your overwriting the bootloader with your own. The default baud for an unmodified bootloader is 115200. (thus the likely newtmgr timeouts)

                                                                  Have you tried FOTA with #2?

                                                                      Terms and Conditions | Privacy Policy