MCUBOOT no external 32KHz crystal sysbuild issue

I have been trying to:

add MCUBOOT and FOTA to a custom BLE board using the nRF54L15. 

I had thought that the sole issue was that the custom board does not utilize and external 32KHz crystal. This easily managed in the main app by adding the following config lines to an included .conf file:

#Enable the RC internal 32Khz clock source
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
Initially, I added these lines to a separate .conf file and included it in the build. The main app runs fine on its own in this configuration.
When adding the ability to use MCUBOOT and FOTA, the MCUBOOT image also needs to be able to run without an external 32KHz crystal, so it is necessary to add the lines to the MCUBOOT image. Without adding these lines MCUBOOT would load and then not run, essentially the device is bricked.
My initial fix was to add the following:
{$project_dir}/sysbuild/mcuboot/prj.conf
{$project_dir}/sysbuild/mcuboot/app.overlay
{$project_dir}/sysbuild/mcuboot/boards/custom_board.conf
{$project_dir}/sysbuild/mcuboot/boards/custom_board.overlay
and adding the lines to the custom_board.conf file.
This did not work, device was still bricked.
Note that the contents of prj.conf was taken directly from the MCUBOOT prj.conf
After hours of reading, it was recommended that the fix was to add these lines into the custom board file defconfig so that they would be picked up by the MCUBOOT build.
This was done, but the device was still bricked.
I then created a baseline build off of PERIPHERAL_LBS and created two builds, one for the nRF54L15DK and one for the custom_board.
These base line builds were created and tested, both ran fine.
Then using the steps from the dev academy courses MCUBOOT and FOTA were added. Note that for the custom_board I again used the sysbuild folders and custom files for MCUBOOT.
The nRF54L15dk ran fine, the custom_board was bricked.
comparing the two builds yielded the following differences:
for the nRF54L15
for custom_board
Note the missing file, and that the build is including the sysbuild/mcuboot/ folder structure, just that it is not including the sysbuild/mcuboot/boards/ folder or the files there in
The important issue is the file that is missing from the custom_board build, nrf54l15dk_nrf54l15_cpuapp.conf, or the version of that file meant for the custom board. Note that the correctly named version of that file was created and placed in the sysbuild/mcuboot/boards/ folder, its just not being included.
The contents of the missing file are as follows:
# Copyright (c) 2024 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: Apache-2.0
#
CONFIG_BOOT_MAX_IMG_SECTORS=256

# Ensure that the SPI NOR driver is disabled by default
CONFIG_SPI_NOR=n

# TODO: below are not yet supported and need fixing
CONFIG_FPROTECT=n

CONFIG_BOOT_WATCHDOG_FEED=n
after hours of trying to find out why I could not add the files held in the sysbuild/mcuboot/boards/ folder, I simply added the mentioned lines to the sysbuild/mcuboot/prj.conf file and finally the custom board was working properly as intended.
So most likely I have missed a step in prepping the system to read the files in the added sysbuild folder structure but I have been unable to determine what step I am missing. Hopefully this is simple fix to this, and I will note that I have a separate project for another board using the nrf9151, that also uses the sysbuild folder structure that successfully adds the files in sysbuild/mcuboot/boards/ to the MCUBOOT image. 
I am simply stumped as to what the difference is or what step I am missing, maybe something in the CMAKE files?
Thanks for your assistance and hopefully the description is clear.
Cheers
Warren
Parents
  • I have found the issue finally. It was a file naming issue. although I am using the *_ns version of the build the files in:

    {$project_dir}/sysbuild/mcuboot/boards/

    had the _ns added to the end. The sysbuild system did not see them as belonging to the project even though the project is _ns. simply removing the _ns from the end of the files allowed the files to be read properly. I am not sure if this is by design or an oversight as this is true for the .conf file and the overlay file and those are certainly important distinctions in the main app.

    Thank you

    Warren

Reply
  • I have found the issue finally. It was a file naming issue. although I am using the *_ns version of the build the files in:

    {$project_dir}/sysbuild/mcuboot/boards/

    had the _ns added to the end. The sysbuild system did not see them as belonging to the project even though the project is _ns. simply removing the _ns from the end of the files allowed the files to be read properly. I am not sure if this is by design or an oversight as this is true for the .conf file and the overlay file and those are certainly important distinctions in the main app.

    Thank you

    Warren

Children
No Data
Related