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

[AscherA]

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

[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

[Didrik Rokhaug]

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.

[AscherA]

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?

[Didrik Rokhaug]

No. The non-secure partition must start at a 32kB boundary, which means that there might be some empty space e´between the secure and the non-secure firmware if the secure FW doesn't use a whole multiplum of 32kB.