AWS_fota: download successful but do not load with new binary file

zirunhong · Apr 30, 2021

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:

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.
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

jaredwolff · Apr 30, 2021

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?

jaredwolff · Apr 30, 2021

You can also try this bootloader. I’ll get the example running here to see if there are any gotchas. Sorry this has been such a pain!

zirunhong · Apr 30, 2021

jaredwolff Thanks for the reply!

Have you tried FOTA with #2?

Yes, I tried FOTA with #2 approach and it works and updated the image on next boot.

You can also try this bootloader.

I tried with this first, is the same result as #1 I mentioned on last reply.

Additionally, I found this github source, when I compare mine under the same directly in the SDK, it is slightly different:

# Disable Zephyr console
CONFIG_CONSOLE=n
CONFIG_CONSOLE_HANDLER=n
CONFIG_UART_CONSOLE=n

# Multithreading
CONFIG_MULTITHREADING=y

# MCUBoot settings
CONFIG_BOOT_MAX_IMG_SECTORS=256

# MCUboot serial recovery
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_0"
CONFIG_BOOT_SERIAL_DETECT_PIN=12
CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=0

# Size of mcuboot partition
CONFIG_SIZE_OPTIMIZATIONS=y

Latest found:

I check the sdk-mcuboot version using git log:

commit 858dd034f6565bcab5ed780e48aa713994ca1b7d (HEAD, tag: v1.7.99-ncs1-rc1, tag: v1.7.99-ncs1, manifest-rev)
Author: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Date:   Mon Feb 8 12:46:06 2021 +0100

    [nrf temphack] prj.conf: don't use CONFIG_LOG_MODE_MINIMAL yet
    
    MCUboot was updated to newer version which uses refactored
    LOG Kconfig keyword not available in sdk-zephyr yet.
    
    Revert this commit on the next upmerge.
    
    Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>

On github, the newest one is 1.8.0-dev . Will that be the case why my bootloader doesn’t work? Should I try with the newest version?

Zirun

jaredwolff · May 3, 2021

zirunhong which version of the SDK are you running?

jaredwolff · May 3, 2021

zirunhong after investigating some more, I definitely recommend you build your own bootloader and use that with Amazon AWS. The reasons are two fold:

There is no one bootloader that supports all versions of NCS. Every time Nordic changes something in the partition manager, it makes the previous bootloader inoperable.
You should secure your bootloader with a non-default signing key.

I updated the documentation about creating your own signing key.

jaredwolff · May 3, 2021

zirunhong Additionally, I found this github source, when I compare mine under the same directly in the SDK, it is slightly different:

NCS >1.5.0 has the bootloader code that I submitted as a PR that handles the LED plus the bootlader delay. That way you can build your own bootloader/application and have the same functionality of the factory bootloader.

jaredwolff · May 3, 2021

Working on NCS 1.5.1 and the factory bootloader here were my results:

Using the instructions here I set up my S3 bucket, etc.

Once set up I also updated

CONFIG_CLOUD_CLIENT_ID="feather-xxxx"
CONFIG_MQTT_BROKER_HOSTNAME="xxxx-ats.iot.us-east-1.amazonaws.com"

They seem to be the only things that need to be added to prj.conf

I downloaded the cert, private key and the Amazon Root CA1. Popped those in nRF Connect for Desktop and wrote them to the device.

(I used the default security tag of 12345678)

Remember the device needs to be on but not connected (Using AT+CFUN=4 in order to add the certs.) Once complete setting AT+CFUN=0 is always a good idea.

A successful connection looks like:

2021-05-03T16:29:58.240Z DEBUG modem << MQTT AWS Jobs FOTA Sample, version: v1.0.0
2021-05-03T16:29:58.241Z DEBUG modem << Initializing modem library
2021-05-03T16:29:58.447Z DEBUG modem << Initialized modem library
2021-05-03T16:29:58.449Z DEBUG modem << LTE Link Connecting ...
2021-05-03T16:30:03.254Z DEBUG modem << LTE Link Connected!
2021-05-03T16:30:03.486Z DEBUG modem << IPv4 Address 3.224.183.138
2021-05-03T16:30:03.488Z DEBUG modem << client_id: feather-xxxxx
2021-05-03T16:30:08.503Z DEBUG modem << [mqtt_evt_handler:182] MQTT client connected!
2021-05-03T16:30:09.155Z DEBUG modem << [mqtt_evt_handler:235] PUBACK packet id: 17463
2021-05-03T16:30:09.216Z DEBUG modem << [mqtt_evt_handler:245] SUBACK packet id: 2114
2021-05-03T16:30:09.472Z DEBUG modem << [mqtt_evt_handler:235] PUBACK packet id: 20067
2021-05-03T16:31:10.994Z DEBUG modem << [mqtt_evt_handler:250] default: 9
2021-05-03T16:32:12.008Z DEBUG modem << [mqtt_evt_handler:250] default: 9

Then I created a job..

Running the update with the compiled bootloader works. While using the stock v2 bootloader does not work. Exactly as you were seeing @zirunhong. My earlier recommendation still stands considering the situation.

zirunhong · May 3, 2021

jaredwolff Thanks for the reply!

which version of the SDK are you running?

I use v1.5.0, I used the instruction here.

NCS >1.5.0 has the bootloader code that I submitted as a PR that handles the LED plus the bootlader delay. That way you can build your own bootloader/application and have the same functionality of the factory bootloader.

I see, I will try v1.5.1 to see if any progress.

after investigating some more, I definitely recommend you build your own bootloader and use that with Amazon AWS.

Yes, eventually we will have our application with FOTA feature, so to have our bootloader with our own key is definitely necessary.

I updated the documentation about creating your own signing key.

Thanks for the update, I will check it out.

Zirun

jaredwolff · May 3, 2021

@zirunhong also here’s the patch for the bootloader until it gets rolled into NCS

https://community.jaredwolff.com/assets/files/2021-05-03/1620063570-271726-nrf9160-feather-bootloader-patch.diff

This enables the bootloader delay when pressing the button and also enables the LED.

jaredwolff · May 3, 2021

zirunhong NCS >1.5.0 has the bootloader code that I submitted as a PR that handles the LED plus the bootlader delay. That way you can build your own bootloader/application and have the same functionality of the factory bootloader.

I see, I will try v1.5.1 to see if any progress.

I take this back slightly. It doesn’t have the delay or the LED functionality. That means you’re likely putting the device into DFU you just can’t see it.

zirunhong · May 3, 2021

jaredwolff

When I take the conversation back, I found this:

The default baud for an unmodified bootloader is 115200. (thus the likely newtmgr timeouts)

On the factory bootaloader it was 1000000, So I changed the connection configuration into
newtmgr conn add serial type=serial connstring='dev=/dev/tty.SLAB_USBtoUART,baud=115200'

And it flash the binary with the compiled bootloader (including in merged.hex), FOTA works as well! My mistake not see your mention earlier. One thing I am curious about, how to changed the baud rate into 1000000, and it that a reason for changing it?

I take this back slightly. It doesn’t have the delay or the LED functionality. That means you’re likely putting the device into DFU you just can’t see it.

Yeah. I found the same problem, at first I thought it never goes into DFU until I saw the firmware stop running on serial console. I think they haven’t released the v1.8.0 which merged your PR on LED and delay change. So I am still using the v1.7.99.

jaredwolff · May 3, 2021

zirunhong One thing I am curious about, how to changed the baud rate into 1000000, and it that a reason for changing it?

The reason for changing it was because 115200 is slow. It takes >45 seconds to load an update. Whereas with 1M BAUD it takes < 15 seconds. That’s one thing I forgot to mention (changing that back to the 1M)

You can change circuitdojo_feather_nrf9160.dts which is located in zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160.dts to match the following:

/*
 * Copyright (c) 2018-2020 Nordic Semiconductor ASA
 * Copyright (c) 2020 Circuit Dojo LLC
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/dts-v1/;
#include <nordic/nrf9160_sica.dtsi>
#include "circuitdojo_feather_nrf9160_common.dts"

/ {
	chosen {
		zephyr,sram = &sram0_s;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
		zephyr,sram-secure-partition = &sram0_s;
		zephyr,sram-non-secure-partition = &sram0_ns;
	};
};


&uart0 {
	status = "okay";
	current-speed = <1000000>;
	tx-pin = <6>;
	rx-pin = <5>;
};

This applies to the non-secure portion of code (i.e. the bootoader). So it will default back to the 115200 for your application code. This will also merge as soon as this PR is approved and NCS is rebased to latest Zephyr.

zirunhong · May 5, 2021

jaredwolff

I updated the documentation about creating your own signing key.

I tried with the same process to build my own key. It works with AWS_FOTA example!

You will need to add those options to prj.conf :

CONFIG_SECURE_BOOT=y
CONFIG_BUILD_S1_VARIANT=y

Thanks for all your help!

Zirun

jaredwolff · May 5, 2021

zirunhong fantastic!!!

Thanks for sharing those last bits. I’m sure it will be helpful for others out there as well.