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

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.

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.

zirunhong which version of the SDK are you running?

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.

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

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