NRF Connect SDK Builds/Pristine Builds Ignore Child Image Configuration With Custom Boards

Hi,

I am using the VSCode nRF Connect extension with nRF Connect SDK v2.0.0 (according to the Toolchain Manager). I have a custom board with a U-Blox NRF5340 module on it. I am running into an issue with the Throughput example where the very first compilation (after running "nRF Connect: Add Build Configuration" in VSCode) will work exactly as expected as it does on the NRF5340DK with a throughput of around 1.25 Mb/s.

However, when I do a pristine build (using the button from the extension) without changing anything, the new build will not use the configuration for hci_rpmsg.conf in the child_image folder and instead seems to use defaults from the sample's configuration. Essentially, this sets CONFIG_BT_BUF_ACL_RX_SIZE to 27 for the network core instead of 251, resulting in extremely slow throughput which is how I noticed this problem in the first place.

This can be easily reproduced without any hardware:

  1. Copy the nrf5340dk_nrf5340 folder from ncs/v2.0.0/zephyr/boards/arm into a custom boards folder
  2. Add the custom boards folder to VSCode
  3. Restart VSCode
  4. Create a new application using the NRF Connect extension
  5. Choose the Bluetooth: Throughput sample
  6. From Custom boards, choose the nrf5340dk_nrf5340_cpuapp board
  7. Choose the prj_nrf5340dk_nrf5340_cpuapp.conf configuration
  8. Leave everything else default and build
  9. Observe build/hci_rpmsg/zephyr/.config where CONFIG_BT_BUF_ACL_RX_SIZE=251
  10. Using the extension, click the "Pristine Build" button under the actions menu
  11. Observe build/hci_rpmsg/zephyr/.config where CONFIG_BT_BUF_ACL_RX_SIZE=27

What is it that I am doing wrong here? This doesn't seem to happen for me using the provided NRF5340DK board configuration. As far as I can tell from this page, the configuration is set up correctly so I am unsure of why my custom board will not use the configuration for the child image for any builds except the first one. This took quite a while to figure out, I never suspected a problem with the configuration or build tools since the example worked for me the first time; I just thought I messed up the code somewhere when I made a change and rebuilt.

Thank you for you help!

  • Windows 10
  • VSCode Version 1.70.1
  • nRF Connect SDK v2.0.0
  • Hi,

    Thanks for reporting this. I have forwarded it to our developers.

    Can you confirm that it only happens with custom boards for you?

    Because when I tried, I was able to reproduce it without creating a custom board.

    However, if I use West directly from the terminal, I am not able to reproduce it. So that might be a solution until we can fix it properly.

    Best regards,

    Didrik

  • Thank you for the quick reply!

    I just tested it and can confirm it is also not working on non-custom boards. That's strange as I am almost certain it was working with them earlier. However, I did reinstall the SDK trying to get it work so maybe that's a contributing factor.

    Thanks for your workaround, I had not thought about that. I'll have to figure out exactly what command line options and whatnot to use for my real application. Simply comparing the commands that the extension runs for the throughput example, on the second build it's identical except for 2 additional options. I don't understand why adding those 2 options causes the child image configuration to be excluded, or why the original build even works without them, but I'm sure you guys already have that figured out Slight smile

     -DCONF_FILE:STRING="c:/Users/rapidrs/Desktop/53ble/throughput/prj_nrf5340dk_nrf5340_cpuapp.conf" -DDTC_OVERLAY_FILE:STRING="c:/Users/rapidrs/Desktop/53ble/throughput/dts.overlay"
  • Hi ,

    is there already a solution in the pipe for the VS Code extension? I noticed, that this is still a problem in my setup. I used a custom nRF5340 development board in combination with the nRF Connect SDK version 2.5.0 and the radio_test sample. I tried to change the configuration (overlay file) in the child image, but when doing a new build, it ignores my overlay file for the build.

  • I am also finding this to be the case.

    There appear to be 2 problems with the build process.

    Immediately after configure, not all flags are passed to west. For mcuboot, -Dmcuboot_OVERLAY_CONFIG is missing.

    If you then run a pristine build, then project will now build correctly, however the west arguments have change subtly again.

    Now, instead of supplying -DCONF_FILE, west is now given -DCACHED_CONF_FILE. This seems to be critical to getting the build to work, as a subsequent build using -DCONF_FILE does not work.

    You will only notice this failing for this particular example (mcuboot) if you require the build to be minimised. When build process doesn't minimise mcuboot, but your mcuboot partition has been reduced, the image won't fit and the build will fail.


    After configure:
    
    west build --build-dir <PATH>/app/build <PATH>/app 
    --pristine 
    --board [email protected] 
    --no-sysbuild -- 
    -DNCS_TOOLCHAIN_VERSION=NONE 
    -DCONF_FILE=<PATH>/app/prj_release.conf 
    -DEXTRA_CONF_FILE=frag_mcuboot.conf
    
    Pristine build:
    
    west build --build-dir <PATH>/app/build <PATH>/app 
    --pristine 
    --board [email protected] 
    --no-sysbuild -- 
    -DNCS_TOOLCHAIN_VERSION=NONE 
    -Dmcuboot_OVERLAY_CONFIG=<WORKSPACE>/nrf/subsys/partition_manager/partition_manager_enabled.conf 
    -DCACHED_CONF_FILE=<PATH>/app/prj_release.conf 
    -DEXTRA_CONF_FILE=<PATH>/app/frag_mcuboot.conf


  • To clarify, this applies for custom and non custom boards 

Related