asset_tracker_v2 booting with V2.5.0

[Timothy]

I have a nRF9160DK board running asset_tracker_v2 on a nRF9160 custom board. V1.7.0 loads and boots fine but when I use V2.5.0 the boot fails as shown below. The only change I have made to the V2.5.0 asset_tracker_v2 code was to change the 2 lines in prj.conf that had my AWS information. This code loads fine in a nrf9160DK board but fails when I use the V2.5.0 version in the custom board. The V1.7.0 version loads in the custom board and had been running for several years. any ideas what I am doing wrong? any way to get more information on why the boot is failing? any help would be greatly appreciated. We have V1.7.0 out in the filed in many sites for years and it is working perfectly. The decision was made to upgrade to V2.5.0 so I am stuck until I can get this to boot correctly.

I noticed there are 2 new lines in the V2.5.0 code that are not in the V1.7.0 code. since these related to boot I commented them out. below are the 2 extra lines in V2.5.0 and the error message.

CONFIG_SECURE_BOOT=y
CONFIG_BUILD_S1_VARIANT=y

when I tried to build with these commented out I got the following error message.

********************************************

C:/Nordic1/v2.5.0/nrf/modules/tfm/tfm/boards/common/assert.c:16:9: note: '#pragma message:

!!!Partition alignment error!!!
The non-secure start address in pm_static.yml or generated partition.yml is: 0x1be00
which is not aligned with the SPU region size.
Refer to the documentation section 'TF-M partition alignment requirements'
for more information.

'
16 | #pragma message "\n\n!!!Partition alignment error!!!"\
| ^~~~~~~
C:/Nordic1/v2.5.0/nrf/modules/tfm/tfm/boards/common/assert.c:22:2: error: #error "TF-M non-secure start address is not aligned on SPU region size"
22 | #error "TF-M non-secure start address is not aligned on SPU region size"
| ^~~~~
ninja: build stopped: subcommand failed.
[

************************************************************************

*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0xc0...9e
Firmware signature verified.
Firmware version 1
Booting (0x8200).

[Didrik Rokhaug]

Hi,

Just to make sure that I understand your problem correctly:

You have deployed custom boards with the asset_tracker_v2 from NCS v1.7.0, that you wish to upgrade to NCS v2.5.0.

When you build the new version and flash it (with a programmer) to a DK, it works, but when you do a FPTA upgrade for the deployed devices, it fails.

Is this correct, or you do do a FOTA upgrade of the DK as well?

Do you have a static prtition configuration? If so, can you share it with me?

Best regards,

Didrik

[Timothy]

Didrik

you are correct. we have deployed custom boards with asset_tracker_v2 from NCS V1.7.0. We want to upgrade to NCS v2.5.0. We flash it with a programmer to both the nRF9160DK board and the custom board both of which are in my lab here sitting next to each other. The DK board works fine and the custom board does not boot. We are not using FOTA at this time. We are just trying to program working version of the V2.5.0 code. I am not sure where I find the partition configuration. I did not do anything to change whatever the sample asset_tracker_v2 partitions were set to. If you tell me where I can find them I will send them

[Timothy]

Didrik

just to repeat what I am trying to load in both the DK board and the custom board is the V2.5.0 sample asset_tracker_v2. The only changes are the 2 lines to load my AWS information in overlay-aws.conf. I have made no other changes to asset_tracker_v2. This is the step I took to get V1.7.0 working. I start with a working sample and expand from there. I have never seen this behavior before. I have never seen a DK or a custom board not boot. any help would be great since I can not move forward until I can get a program to boot in the custom board.

[Timothy]

Didrik

another data point. I can power cycle the board many times and occasionally it will boot up properly and run perfectly. Getting it to run is may 10% or less but when it does boot the board is fine.

[Timothy]

below is an existence proof that the code is programmed correctly and runs perfectly (very rarely). I have no idea how to get it to boot consistently.

*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0xe0...f4
Firmware signature verified.
Firmware version 1
*** Booting nRF Connect SDK v2.5.0 ***
*** Booting nRF Connect SDK v2.5.0 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0xe0...f4
Firmware signature verified.
Firmware version 1
*** Booting nRF Connect SDK v2.5.0 ***
*** GPIO Init ***
SW2CTRL device is ready
SPI CS2N device is ready
SPI CS3N device is ready
BAT MON EN device is ready
GPIO_09 device is ready
CHRG device is ready
ACPR device is ready
*** ADC Init ***
ADC device is ready
adc setup: 2nd channel passed
adc setup: 4th channel passed
*** SPI Init ***
SPI device is ready
*** I2C Init ***
I2C device is ready
I2C config passed
[00:00:00.252,441] <err> spi_nor: Device id 00 00 00 does not match config c2 28 17
*** Booting nRF Connect SDK v2.5.0 ***
Calibrating PWM for channel 0...
Application Event Manager initialized
[00:00:00.288,970] <inf> app_event_manager: APP_EVT_START
[00:00:00.484,680] <inf> app_event_manager: MODEM_EVT_INITIALIZED

[Didrik Rokhaug]

If you use a programmer to flash the new version, including the bootloader, the problem is not the flash partitions.

Here's the documentation for how to get a static partitioning configuration, as that that is something you will need when you start looking at how to upgrade your deployed devices: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/scripts/partition_manager/partition_manager.html#static_configuration

Do you have custom board files for your board, or are you building for the DK when building for your custom board?

In NCS v2.5.0, the default version of the DK was changed from 0.7.0 to 0.14.0. The main difference is that the 0.14.0 revisions and newer have an external flash. If your custom board does not have that external flash, that might be the problem.

The solution in this case would be to either create a custom board definition for your board, or to build for the 0.7.0 revision of the DK.

[Timothy]

Didrik

I have some additional information with our custom board. A colleague found if I use the following command to build it will build and boot every time after a flash and with a software reset. 

 west build -b nrf9160dk_nrf9160_ns@0.7.0 -- pristine -DDTC_OVERLAY_FILE=boards/nrf9160dk_nrf9160_ns.overlay

This has the following memory layout

Memory region Used Size Region Size %age Used
FLASH: 272408 B 384 KB 69.28%
RAM: 164940 B 211608 B 77.95%
IDT_LIST: 0 GB 2 KB 0.00%

if I use the default 0.14.0 below to build

west build -b nrf9160dk_nrf9160_ns -- pristine -DDTC_OVERLAY_FILE=boards/nrf9160dk_nrf9160_ns.overlay

this has the following memory layout and will not boot after a flash or with software reset. I must power cycle in order to get it to boot. Both binaries do run once started.

Memory region Used Size Region Size %age Used
FLASH: 275576 B 736 KB 36.56%
RAM: 165228 B 211608 B 78.08%
IDT_LIST: 0 GB 2 KB 0.00%

I have attached my overlay file and my prj.conf file. I am not an expert in setting of the configuration so maybe I messed something up. Can you look at my files and let me know if I have made some mistakes. I have 2 questions.

1. why should one version (0.7.0) boot and not the other (0.14.0).

2. why is there a memory difference in the versions. The nRF9160 has 1 MB of flash correct? why is there such a difference. 

summary: if I use 0.7.0 I can get it to boot and run automatically but I have a lot less memory to work with. I am adding code and sensor drivers daily. I may need all of the memory possible.

0160.nrf9160dk_nrf9160_ns.overlay2146.prj.conf

[Didrik Rokhaug]

Hi,

The difference between the 0.7.0 revision and the 0.14.0 revision is that the 0.14.0 revision has an external flash.

The asset_tracker_v2 will use the external flash for MCUBoot's secondary slot. This frees up space on the internal flash, which can then be allocated to the primary slot.

I don't know why it doesn't boot though.

[Timothy]

Didrik

so should I continue to use the 0.7.0 or is there a way to disable the external flash. my custom board does NOT have the external flash it is expecting on the nRF9160DK board.

also why the difference in Flash usage. How do I get the extra memory back.

[Didrik Rokhaug]

Timothy said:

also why the difference in Flash usage. How do I get the extra memory back.

The flash usage is almost the same in both cases, but a bit higher when you build for 0.14.0.

The reason for why you have more flash "available" is that you use the external flash for the secondary slot for MCUBoot.

So instead of the flash layout beeing something like

<| MCUBoot | MCUBoot primary | MCUBoot secondary |> (TF-M and the application must share the MCUBoot primary partition)

You get something like

<| MCUBoot | MCUBoot primary                                         |> and on the external flash <| MCBoot secondary |>

Timothy said:

so should I continue to use the 0.7.0 or is there a way to disable the external flash. my custom board does NOT have the external flash it is expecting on the nRF9160DK board.

You can disable the extra config options and device tree node that the 0.14.0 adds. However, this doesn't really have any benefits over using 0.7.0 other than not having to specify the board revision.