nRF9160 custom board bootloader problems

[AscherA]

Dear Nordic Team, 

I am working on a custom board  and I am currently implementing the firmware-over-the-air library via https.
For this I need to use the MCUBootloader. Unfortunately I ran into some troubles implementing the bootloader.

I am using Visual Studio in combination with the "nRF Connect for Desktop" and the SDK version 2.0.0.

To configure the bootloader I created a child_image folder in my project and in the folder I created a mcuboot.conf file like suggested in many of the Nordic devzone forum entries.

The changes in the mcuboot.conf are quite simple I changed the BOOT_SIGNATURE_TYPE to RSA and included a path for my key. Since I am working with a out-of-tree build I had to use a absolute file path for the key since otherwise the autogenerate file of the mcubootloader could not find the key file. 
Furthermore I activated the bootbanner and told the bootloader to use RTT for the logging interface. 

This seems to work fine when building the project and here is the bootloader logging information which I get:

*** Booting Zephyr OS build v3.0.99-ncs1  ***

[00:00:03.383,453] <inf> mcuboot: Starting bootloader
[00:00:04.655,456] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:04.655,975] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:04.656,402] <inf> mcuboot: Boot source: none
[00:00:04.656,799] <inf> mcuboot: Swap type: none
[00:00:05.176,513] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:05.176,879] <inf> mcuboot: Jumping to the first image slot

But after that the nrf9160 does nothing and also does not start my application. 

At the end I added the  mcuboot.conf and the prj.conf files

I have searched through the forum and found some entries regarding the bootloader unfortunately none of the offered answeres helped in my case. 

I have also tried to to a simple small sample to make sure my custom board is not the problem and used the tfm_hello_world sample and added
"CONFIG_BOOTLOADER_MCUBOOT=y" to the sample prj.conf. This seems to work fine so I am very sure the problem somehow originates either in my bootloader configuration or in my application itself. 

I hope someone can help me with my problem.

Best regards,

Andreas 

mcuboot.conf:

CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
############################################
# Image signing private key
############################################
CONFIG_BOOT_SIGNATURE_KEY_FILE="C:/sample_folder/src/KeyFiles/custom_private_key.pem" 

############################################
#Use hardware peripherals (BPROT, ACL, or SPU) to write-protect
#regions of flash until next reset.
############################################
CONFIG_FPROTECT=n

CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_SERIAL=n
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_BOOT_BANNER=y

proj.conf:

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_MINIMAL=y
CONFIG_TFM_BL2=n

# Reroute printk to SES Terminal
CONFIG_PRINTK=n
CONFIG_CONSOLE=n

CONFIG_SERIAL=y
CONFIG_STDOUT_CONSOLE=n

CONFIG_LOG=n
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=n
CONFIG_USE_SEGGER_RTT=n
CONFIG_LOG_MODE_IMMEDIATE=n

# Enable GPIOs
CONFIG_GPIO=y

# Enable I2C/TWI
CONFIG_I2C=y
CONFIG_I2C_NRFX=y

# Heap and stacks
CONFIG_HEAP_MEM_POOL_SIZE=77824
CONFIG_MAIN_STACK_SIZE=40960
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

CONFIG_FLASH=y
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y

# Uart Config
CONFIG_NRFX_UARTE0=y
CONFIG_UART_ASYNC_API=y

# Watchdog
#CONFIG_WATCHDOG=y
#CONFIG_WDT_LOG_LEVEL_DBG=y
#CONFIG_WDT_DISABLE_AT_BOOT=n

# Networking
CONFIG_NETWORKING=y
CONFIG_NET_NATIVE=n
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y

# LTE link control
CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_AUTO_INIT_AND_CONNECT=n
CONFIG_LTE_LINK_CONTROL_LOG_LEVEL_DBG=n

CONFIG_LTE_NETWORK_MODE_LTE_M_GPS=y
CONFIG_LTE_MODE_PREFERENCE_LTE_M=y

# Modem info
CONFIG_MODEM_INFO=y
CONFIG_MODEM_INFO_ADD_DATE_TIME=n

CONFIG_DATE_TIME=y

# Modem library
CONFIG_NRF_MODEM_LIB=y

# AT Host
CONFIG_AT_HOST_LIBRARY=y

# MQTT
CONFIG_MQTT_LIB=y
CONFIG_MQTT_LIB_TLS=y
CONFIG_MQTT_CLEAN_SESSION=y
CONFIG_MQTT_KEEPALIVE=10
CONFIG_NRF_MODEM_LIB=y
CONFIG_MODEM_KEY_MGMT=y

# Application
CONFIG_MQTT_MESSAGE_BUFFER_SIZE=512
CONFIG_MQTT_PAYLOAD_BUFFER_SIZE=4096

CONFIG_MQTT_RECONNECT_DELAY_S=10

CONFIG_LEGACY_INCLUDE_PATH=y

# FOTA library
CONFIG_FOTA_DOWNLOAD=y
CONFIG_REBOOT=y

# Download client
CONFIG_DOWNLOAD_CLIENT=y
CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096

# DFU Target
CONFIG_DFU_TARGET=y
#CONFIG_DFU_TARGET_MCUBOOT=y
#CONFIG_DFU_TARGET_MODEM_DELTA=n
#CONFIG_DFU_TARGET_STREAM_SAVE_PROGRESS=y

# Settings
#CONFIG_SETTINGS=y
#CONFIG_SETTINGS_NVS=y

# Non-volatile Storage
#CONFIG_NVS=y

# Application update support
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_IMAGE_VERSION="0.1.0"

# Image manager
CONFIG_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

[Didrik Rokhaug]

Hi,

Did I understand you correctly that the application failed to boot when you added the bootloader?

Or did it work with a bootloader, but when you changed the settings for the bootloader, it failed?

What happens if you try to run an application built for the secure domain?

E.g. try add MCUBoot (with your added configurations) to the hello_world sample, and build for the secure version of the board (the one that doesn't end with "_ns").

Best regards,

Didrik

[AscherA]

Hi Didrik,

thanks for your help.

Yes my application fails to boot after I add the bootloader. I first added the FOTA library to be able to do a firmware update and after implementing it into my application I realized that I need the bootloader because my building process did not manufacture the app_update.bin output file. 

I will try you suggestion and come back to you with the results.

Best regards,

Andreas

[AscherA]

Hi Didrik,

I tested adding the MCUBoot to the hello_world sample and I also build it with my custom secure board.

This worked fine without any problems. I tested this with the tfm_hello_world and the hello_world sample both started normal.

Best regards,

Andreas

[AscherA]

Hi Didrik,

unfortunately my original assessment was wrong. My nrf9160 does start my application even with the bootloader, but when I try to access my configuration the board restarts. Since accessing my configuration is the first point in my application it seemed like the bootloader was the cause.
But without the bootloader my application is working fine and my configuration can be recalled by the app.

Here some details about my configuration:

I am storing the configuration in the storage_partition of the nrf9160. Here you can see  my board configuration:

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x10000>;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
		};
		slot0_ns_partition: partition@50000 {
			label = "image-0-nonsecure";
		};
		slot1_partition: partition@80000 {
			label = "image-1";
		};
		slot1_ns_partition: partition@c0000 {
			label = "image-1-nonsecure";
		};
		scratch_partition: partition@f0000 {
			label = "image-scratch";
			reg = <0x000f0000 0xa000>;
		};
		storage_partition: partition@fa000 {
			label = "storage";
			reg = <0x000fa000 0x00006000>;
		};
	};
};

The custom board is derived from the nrf9160dk_nrf9160 and there are only minimal changes to the configurations as can be seen for example in the partition management which is the same as the nrf9160dk.
To be able to store the configuration we used the "zephyr/drivers/flash.h" flash functions. Like mentioned above as soon as the application triggers the my custom "flash_data_read" function, the whole board panics and restarts.

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// read flash
int flash_data_read(void)
{
    //FLASH_SIZE defined above with 0x6000
    int result = flash_read(flash_dev,0xfa000, ptr_flash,FLASH_SIZE);

    //LOG_INF("Read config from flash -> result: %d", result);

    return result;
}

I though I made sure that none of the other functions used by my application uses this partition in any way. I also looked at the MCUBoot documentation and there is not mentioning of the storage_partition: 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-zephyr.html

Without the bootloader the configuration does not cause any problem. Is the storage_partition used by the bootloader in any way?

Since this is not directly connected to my original question please let me know if i should open a new topic for this problem. 

Best regards,

Andreas

[Didrik Rokhaug]

In NCS, we don't use the flash partitioning from the device tree, instead, we use the Partition Manager, which dynamically partitions the flash when you build the project.

You can find the resulting partition map in <your build folder>/partitions.yml. Could you check if the address you try to read from is not taken by MCUBoot or TF-M (and therefore not accessible from the non-secure application).