Unable to change CONFIG_HEAP_MEM_POOL_SIZE in prj.conf

[droberson]

To preface:

• nRF Connect SDK 2.9.0
• nRF9151 DK
• Windows 11 PC

Hello,

I have been developing in the nRF Connect SDK for a few weeks now so I am fairly new. I have encountered a strange issue I don't understand. Whenever I change CONFIG_HEAP_MEM_POOL_SIZE in my prj.conf file and build the project, it never updates to the new value. It remains at a default value of 4096 as seen when I search for the config in menuconfig. Whether I do a pristine or regular build makes no difference. The same issue occurs when I try to set CONFIG_MAIN_STACK_SIZE. Other Kconfig changes work as expected. I was able to reproduce this using a nRF Connect SDK example as detailed below. Note that you don't need the actual devkit to reproduce, you just need to build the project.

Example: HTTPS Client

Steps to reproduce:

1. Open a new instance of VS Code

2. Select the nRF Connect extension -> Create a new application -> Copy a sample -> nRF Connect SDK v2.9.0 -> Filter for board "nrf9151 Non Secure" and select the DK -> HTTPS client sample

3. Select a destination for the new project. I used c:\ncs_workspace\https_client

4. Open the project when prompted

5. Select the nRF Connect extension -> Add build configuration -> Select the following:

• SDK v2.9.0  - Toolchain: v2.9.0
• Board target: nRF9151dk/nrf9151/ns
• Optimization level: Optimize for debugging
• Leave everything else as default (System build should be left to the default of "Build system default")

6. Click the blue "Build Configuration" button and wait for the build to complete.

7. Open prj.conf in VS code and observe that the current value of CONFIG_HEAP_MEM_POOL_SIZE is set to 1024. However, when you hover your mouse over it or check its value in menuconfig it actually has a value of 4096. I assume it is overridden to a higher value by a library.

8. Change CONFIG_HEAP_MEM_POOL_SIZE to the following:

CONFIG_HEAP_MEM_POOL_SIZE=8192

9. Select the nRF Connect extension -> Actions -> Build (NOT pristine), and wait for the build to finish.

10. In prj.conf, mouse over CONFIG_HEAP_MEM_POOL_SIZE and observe that it is still assigned a value of 4096  (Or use menuconfig to confirm)

11. Select the nRF Connect extension -> Actions -> Pristine Build, and wait for the build to finish.

12. In prj.conf, mouse over CONFIG_HEAP_MEM_POOL_SIZE and observe that it is still assigned a value of 4096  (Or use menuconfig to confirm)

13. At this point, no matter what value you change CONFIG_HEAP_MEM_POOL_SIZE to, or whether you use 'pristine' build or not, CONFIG_HEAP_MEM_POOL_SIZE will always have a value of 4096.

Question: Why are my changes to CONFIG_HEAP_MEM_POOL_SIZE in prj.conf not being reflected in the final build output?

Thanks,

Derek

[Håkon Alseth]

Hi,

 

Could you try to generate a new build, ie. not use pristine, and see if this helps?

You can also check your build-folder/app-name/zephyr/.config file to verify if the configuration did indeed get set to your wanted value

 

Kind regards,

Håkon

[droberson]

Hey Håkon,

Sorry for the delayed reply.

Håkon Alseth said:

Could you try to generate a new build, ie. not use pristine, and see if this helps?

What exactly do you mean by generate a new build that does not use "pristine"? My understanding is that there are 2 build methods:

1. Non-pristine

2. Pristine

Do you mean create an entirely new build configuration?

Edit:

I tried creating a new build configuration ('build_1' in the screenshot below) , built the project, and the issue persists:

What am I missing?

Thanks,

Derek

[Håkon Alseth]

Hi Derek,

 

Could this be a problem with how the sample is setup?

HEAP_MEM_POOL_SIZE is set explicitly in both the boards/nrf9151dk_nrf9151_ns.conf file as well as the prj.conf file.

The loaded configuration from the boards folder will override what is stated in the prj.conf

 

Kind regards,

Håkon

[droberson]

Hey Håkon,

Håkon Alseth said:

Could this be a problem with how the sample is setup?

No idea, I am new to Zephyr .

Håkon Alseth said:

The loaded configuration from the boards folder will override what is stated in the prj.conf

If this is true, then why does the Nordic Dev Academy state otherwise?

Source: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-3-elements-of-an-nrf-connect-sdk-application/topic/configuration/

From the link above:

"Configuration options can be set both in the application configuration file and the board configuration file. In the example, CONFIG_GPIO symbol is set in both files. In this case, the value in the application configuration file always takes precedence."

From the link above:

"You should never modify any board configuration files. Instead, rely on the application configuration file to set new configurations and subsequently overwrite any default board configurations if needed."

What am I missing? I thought prj.conf took precedence over anything else in the project. If this is not the case, it is not clearly explained in the Dev Academy course unless I am missing something.

The only possible explanation that I see is that the Dev Academy comments above are referring to the 'defconfig' board configuration files, and not the .conf files.

Thanks,

Derek

[Håkon Alseth]

Hi Derek,

 

droberson said:

"You should never modify any board configuration files. Instead, rely on the application configuration file to set new configurations and subsequently overwrite any default board configurations if needed."

I see the confusion, as this section of the course does not distinguish between a "boards" directory configuration overload/append and the actual declaration of the board itself.

This is a generic comment on that you should not change the ../ncs/zephyr/boards/nordic/ files directly, but rather add your configuration local to the application, and thus append to the chosen board configuration.

 

Within the "application scope", we include the my_appliaction/boards/ folder.

droberson said:

"Configuration options can be set both in the application configuration file and the board configuration file. In the example, CONFIG_GPIO symbol is set in both files. In this case, the value in the application configuration file always takes precedence."

This is the same situation as above, the board, for instance "nrf52840dk/nrf52840", will have a default configuration, like shown here:

https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/nordic/nrf52840dk/nrf52840dk_nrf52840_defconfig

 

Kind regards,

Håkon

[droberson]

Hey Håkon,

Ok. Is the conclusion that any board files in the local /boards folder will take precedence? Is this documented anywhere in the Dev Academy or Zephyr documentation?

I did stumble on this: https://github.com/nrfconnect/sdk-nrf/blob/main/applications/asset_tracker_v2/boards/nrf9161dk_nrf9161_ns.conf

From the file linked above:

# This file is merged with prj.conf in the application folder, and options
# set here will take precedence if they are present in both files.

I still don't know what the difference is between a .conf file and a regular board file without the '.conf' extension. According to the Dev Academy tutorial: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-3-adding-custom-board-support/topic/creating-board-files/

Board files should follow a specific naming convention, where the .conf files are used only when you have multiple board variants (Rev A, Rev B, etc). Since I am using a devkit, why do the nRF Connect SDK samples for this board use a. conf file and not just define the Kconfigs in the prj.conf file to override the existing board file found at zephyr\boards\nordic\nrf9151dk\nrf9151dk_nrf9151_defconfig?

Again, sorry for my ignorance on this subject, this is quite confusing.

Thanks,

Derek

[Håkon Alseth]

Hi Derek,

 

droberson said:

Ok. Is the conclusion that any board files in the local /boards folder will take precedence? Is this documented anywhere in the Dev Academy or Zephyr documentation?

That is correct. This is documented in the kconfig part of zephyr:

https://docs.zephyrproject.org/latest/build/kconfig/setting.html#the-initial-configuration

droberson said:

I still don't know what the difference is between a .conf file and a regular board file without the '.conf' extension. According to the Dev Academy tutorial: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-3-adding-custom-board-support/topic/creating-board-files/

A board file is the "board" itself. This can be named test_board for instance. This test_board has a initial configuration in terms of kconfig / device tree / boot-up sequence, and at some point, you might want to change this for testing-purposes. Then you append to the original configuration, and overwrite the former configuration, in the specific test-case or application project.

 

droberson said:

Board files should follow a specific naming convention, where the .conf files are used only when you have multiple board variants (Rev A, Rev B, etc). Since I am using a devkit, why do the nRF Connect SDK samples for this board use a. conf file and not just define the Kconfigs in the prj.conf file to override the existing board file found at zephyr\boards\nordic\nrf9151dk\nrf9151dk_nrf9151_defconfig?

This is because you'd have to enable alot of configs in your _defconfig to be able to add support for all samples/applications within both the "nrf" and "zephyr" tree. It would likely not compile, and if it were to compile; you would end up with loads of modules that you do not need.

To address this, one adds specific support for a board in the sample/subsys/sample-name/boards/ catalog.

 

Kind regards,

Håkon

[droberson]

Hey Håkon,

Håkon Alseth said:

That is correct. This is documented in the kconfig part of zephyr:

https://docs.zephyrproject.org/latest/build/kconfig/setting.html#the-initial-configuration

The only thing I see at the link you provided regarding 'precedence' is the following:

"See Application Configuration Directory on how the application configuration directory is defined.

If a symbol is assigned both in <BOARD>_defconfig and in the application configuration, the value set in the application configuration takes precedence."

Furthermore, at the Application Configuration Directory link, it says:

"Application configuration options are usually set in prj.conf in the application directory."

Thus, one could make the conclusion that prj.conf would take precedence over board files, which contradicts how it actually works. I realize it's talking about a 'defconfig' file, but I don't see where it talks about .conf files taking precedence. The only thing I see regarding .conf is:

"Otherwise, if board revisions are used and boards/<BOARD>_<revision>.conf exists in the application configuration directory, the result of merging it with prj.conf and boards/<BOARD>.conf is used.".

It doesn't say which takes precedence.

Edit: I guess it is what it is, at least I understand now how it should work, although I do think there is room for improvement in the documentation as it isn't clear. In addition, some of the nRF Connect SDK samples define KConfigs in both the /boards .conf file and the prj.conf file. Such as the https_client sample detailed above. This makes the developer think that the boards/.conf file can be overridden by the prj.conf file. In summary, I think these SDK samples should be updated accordingly to move the HEAP and STACK memory definitions to the prj.conf file, and not the boards/.conf file. It would be nice if the boards/.conf file could have an #ifndef to allow the prj.conf file to override it. Something like:

#ifndef CONFIG_HEAP_MEM_POOL_SIZE
CONFIG_HEAP_MEM_POOL_SIZE=1024
#endif

Not sure if this is even possible in the .conf files. Something to look into.

Thanks again for your help in clarifying this issue!