Using CONFIG_DEBUG_OPTIMIZATIONS with Thingy:91 and Asset Tracker v2

[Cambridge_dev]

I'm getting started with the nRF Connect SDK v2.6 and the Asset Tracker v2 application on a Thingy:91.

I can build and flash the unmodified app, and it pushes sensor data to nRF Cloud, using both `overlay-debug.conf` and `overlay-low-power.conf`.

When I set CONFIG_DEBUG_OPTIMIZATIONS=y for the debug conf the build fails with memory problems when building TFM:

[20/461] Performing build step for 'tfm'
[170/174] Linking C executable bin/tfm_s.axf

/usr/local/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1a460 of bin/tfm_s.axf section `.TFM_UNPRIV_CODE' is not within region `FLASH'
/usr/local/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.psa_interface_thread_fn_call' will not fit in region `FLASH'
/usr/local/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1fc40 of bin/tfm_s.axf section `.gnu.sgstubs' is not within region `FLASH'
/usr/local/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1a460 of bin/tfm_s.axf section `.TFM_UNPRIV_CODE' is not within region `FLASH'
/usr/local/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1fc40 of bin/tfm_s.axf section `.gnu.sgstubs' is not within region `FLASH'
/usr/local/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 32136 bytes

Memory region    Used Size       Region Size   %age Used
            FLASH:      80776 B              48640 B       166.07%
               RAM: 1.     8540 B                 32 KB         56.58%
collect2: error: ld returned 1 exit status

How can I increase the partition size for TFM ? 

Thanks

[Håkon Alseth]

Hi,

 

If you add CONFIG_DEBUG_OPTIMIZATIONS=y in your prj.conf, TF-M will also be compiled with debug optimizations, which will cause the partition size to be exceeded.

thingy91_nrf9160_ns will follow this specific partition layout: https://github.com/nrfconnect/sdk-nrf/blob/v2.5.2/boards/arm/thingy91_nrf9160/thingy91_pm_static.yml

 

One way around this is to configure your project with CONFIG_SIZE_OPTIMIZATIONS, and afterwards go into menuconfig and change the application's optimization level. This will cause TF-M to be left with the default optimization, and only set DEBUG_OPTIMIZATION for the asset tracker v2.

You can do this via vscode nRF Kconfig GUI or manually edit and save the .config file:

The .config file is located in ../asset_tracker_v2/my-build-folder/zephyr/.config - Search for "CONFIG_SIZE_OPTIMIZATION" and comment out this with a "#" and then add CONFIG_DEBUG_OPTIMIZATIONS=y and then press "build" in vscode.

 

Kind regards,

Håkon

[Cambridge_dev]

I've also tried to define a custom partition map that gives tfm more space, by creating a pm_static.yml file from the partitions.yml file in the build directory.

But the build doesn't pick this up, and continues to use thingy91_pm_static.yml from the SDK.

How can I get the build to use my partition file ?

Thanks again.

[Håkon Alseth]

Hi,

 

Cambridge_dev said:

Doing as you suggest does let me build an image with debug optimisations - thanks ! 

 

However, when I flash that image to the board it doesn't run the Asset Tracker app. When I try a debugging session with this image the console gives me:

You will need to build the whole project and flash the merge.hex file afterwards, as this changes your application. I suspect that you only updated the zephyr/zephyr.hex, while you should have flashed the zephyr/merged.hex to successfully get it to run.

 

Cambridge_dev said:

I've also tried to define a custom partition map that gives tfm more space, by creating a pm_static.yml file from the partitions.yml file in the build directory.

But the build doesn't pick this up, and continues to use thingy91_pm_static.yml from the SDK.

How can I get the build to use my partition file ?

This is the main issue with using thingy91 as a development platform - it isn't targeted as a full development kit, rather a prototyping platform device.

The .yml file is set in the board itself, more specifically here: https://github.com/nrfconnect/sdk-nrf/blob/v2.5.2/boards/arm/thingy91_nrf9160/CMakeLists.txt#L26

You will need to add your changes to the thingy91_pm_static.yml file, or change the thingy91_nrf9160 board to not load the default board .yml file. 

 

Kind regards,

Håkon

[Cambridge_dev]

It built and ran when I followed your instructions carefully :- )

I'm creating bash scripts to automate building different versions e.g debug, lowpower 

Could you suggest how I could implement the two stage build with west build ?

I can use sed or awk to modify the .config file between the two build steps, but I'm not sure what arguments to give west build to replicate the vscode workflow.

[Edvin]

Hello,

Håkon is out of office, so I will look into your ticket. Please note that I will be out of office as well from tomorrow, due to public holidays here in Norway. We will be back on April 2nd. I am sorry for the inconvenience.

What do you mean by "implement the two stage build with west build"? And what is "awk" and "sed"? 

If you are talking about having two different build configurations, you can use different sets of .conf files. Alternatively, you can include configs in your west build command. E.g. if you want to add a config like:

CONFIG_BT=y

You can use the build command:

west build -b <board> -d <build_dir> -- -DCONFIG_BT=y

For several sets of build commands, please see the ncs\nrf\applications\matter_weather_station as an example. It has prj.conf and prj_release.conf. So you can build with one or the other. By changing the name of the build folder, you can have many concurrent builds in your application.

Best regards,

Edvin