• State Verified Answer
  • Replies 11 replies
  • Subscribers 74 subscribers
  • Views 2521 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301398
Options

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

Parents
  • 0

    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

Reply
  • 0

    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

Children
  • 0 in reply to AscherA

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

  • 0 in reply to Didrik Rokhaug

    Hello Didrik,

    thank you for the information. I checked my partitions.yml and have gone through all its entries.

    The flash partition I am trying to access is at the address 0xfa000 and the flash_size I am tying to access is 0x6000.

    The first entry in my partitions.yml is:

    EMPTY_0:
  address: 0xf4000
  end_address: 0x100000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0xc000
app:
  address: 0x1c200
  end_address: 0x80000
  region: flash_primary
  size: 0x63e00

    This should mean that the portion of the flash I am trying to access should be empty and not used by any other part of the application, if I am reading the partitions.yml right.

    Also all the others partitions.yml entries to not use the specified flash memory partition. 

    Best regards, 

    Andreas

  • 0 in reply to AscherA

    Hello Didrik,

    after finding out the exact address of our empty flash portion I tried to change our flash read function accordingly, but unfortunately this did not work and the nrf9160 still just restarts, when trying to read the flash partition.

    Is it possible that with the addition of the bootloader this empty flash partition was somehow locked by the TF-M secure functions and that is why I am not able to access it?

    Best regards,

    Andreas

  • 0 in reply to AscherA
    AscherA said:
    Is it possible that with the addition of the bootloader this empty flash partition was somehow locked by the TF-M secure functions and that is why I am not able to access it?

    Yes. The application (and non-secure flash area) must start at a 32kB boundary. If the TF-M partition isn't large enough to fill a whole sector, an empty partition will be inserted to enusre proper alignment of the non-secure area.

  • 0 in reply to Didrik Rokhaug

    If I understand correctly this means, that the "EMPTY_0" partition is only a "filler", but it is automatically assigned to the secure partition of the TF-M. Is there a way to assign it to the none-secure partition?

Related
Terms of service