nRF Connect SDK child image per-board configuration discards associated prj.conf in 2.6.1

[Kelso]

When building a project using a custom board, as well as both the b0 and mcuboot bootloaders enabled, board-specific child image configuration causes the build system to ignore the project-specific configuration.

I'm using the following directory structure:

<wk> - Workspace directory
<wk>/<prj> - Project directory
<wk>/<prj>/prj.conf - Core project configuration
<wk>/<prj>/build - Builds
<wk>/<prj>/boards - Boards
<wk>/<prj>/boards/arm/<example>/ - a copy of the nrf5340dk configuration, renamed to something other than nrf5340dk to test if the build system handles custom boards differently than in-tree boards
<wk>/<prj>/child_image/b0/boards/<example>_cpuapp.conf

core project configuration includes the following:

CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_SECURE_BOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

The file <wk>/<prj>/child_image/b0/boards/<example>_cpuapp.conf must contain the contents of <wk>/nrf/samples/bootloader/prj.conf and <wk>/nrf/samples/bootloader/boards/nrf5340dk_nrf5340_cpuapp.conf or it will fail to build.

This relates to https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/nrf/config_and_build/multi_image.html#permanent_configuration_changes_to_child_images

and  Compile ERROR "undefined reference to `sys_clock_cycle_get_32'" with custom board

[Vidar Berg]

Hello,

When the board specific configuration is added, you also need to include the prj.conf (copy of the nrf/samples/bootloader/prj.conf) for the child-image:

child_image/
├── b0
│   ├── boards
│   │   └── <example>_cpuapp.conf
│   └── prj.conf
├── mcuboot.conf
└── mcuboot.overlay

Best regards,

Vidar

[Kelso]

While that sounds like it should fix it, I don't see the new file being picked up on a clean build:

=== child image b0 -  begin ===

...

Parsing <wk>/zephyr/Kconfig
Loaded configuration '<wk>/<prj>/boards/arm/<example>/<example>_cpuapp_defconfig'
Merged configuration '<wk>/<prj>/child_image/b0/boards/<example>_cpuapp.conf'
Merged configuration '<wk>/nrf/subsys/partition_manager/partition_manager_enabled.conf'
Merged configuration '<wk>/<prj>/build_mb/b0/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '<wk>/<prj>/build_mb/b0/zephyr/.config'

...

=== child image b0 -  end ===

I should see a line in there that reads
Merged configuration '<wk>/<prj>/child_image/b0/prj.conf'

[Kelso]

Copying my board files into your project in the new workspace picks things up correctly... I'm able to build for my board.

It's gotta be something about the workspace itself.  I'm going to see if reconstructing things from scratch again helps...

[Kelso]

This appears to be a caching issue with vscode.  I was able to get a workspace that was failing to pick prj.conf up to pick it up by changing the setting for Configuration to "prj.conf" instead of "Use build system default" when adding a build configuration.

This was after cloning into a new workspace and everything.  The way vscode caches configuration it has detected is surprising.  Clearing out the automatically generated cmake arguments isn't always sufficient, and deleting a configuration file can break a build.  Seems like this is related to that.

[Vidar Berg]

That's strange. I don't recall seeing or hearing about this before. Do you notice any differences in the cached configuration when it fails versus when it works?

[Kelso]

I'll clarify... the behavior implies I do not fully understand where things are being cached because the places I'm looking appear to be a symptom, not a cause.

In vscode, if I've built and I try to adjust .conf files, I find extra cmake arguments populated under "edit build configuration" that I often need to clear out. Failing to do so causes the build to fail because the conf files have been intentionally removed.

If there is another place where the cache is editable, I'm not aware of it.

Saving the build config as a preset shows mismatches from expectation with both the failing and the updated workspace.

<wk failing> is missing child_image/b0/prj.conf under b0_CONF_FILE

<wk working> is missing boards/<example>.conf under CACHED_CONF_FILE

[Vidar Berg]

If you open the terminal in VS Code, you can compare the west build command when it works and when it fails. I'm wondering if the extension might be appending some arguments to the build command that override the default behavior when it fails.

[Kelso]

At this point, since forcing the build configuration to use prj.conf instead of the cache, I haven't been able to reproduce the problem I was running into.  On the other hand, I've run into 3 blue screen of deaths plugging in and removing the USB cable, as well as apparently permanently locking the access port on an nRF52DK during one of those BSODs.  I think we can close this issue for now, but I need to open tickets for the other things that have cropped up.