nrf5340 Audio App with MCUBoot app verification timing

[adunk]

I am porting and existing app to nRF Connect SDK 2.7.0 from 2.6.1. Using sysbuild, MCUBoot and the app are building and I am able to load the firmware onto the PCB and it runs. The problem is in the bootloader it takes about 2 seconds to jump to the application. We have a requirement that it basically needs to jump to the application transparently to the user. For this reason I am attempting to disable the SLOT 0 Verification. The application is quite large so I don't have room for dual slot so in the sysbuild.conf I have 

SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=y.

This seems to be working fine, but the problem is I am unable to set 

CONFIG_BOOT_VALIDATE_SLOT0=n

I also tried:

CONFIG_BOOT_SIGNATURE_TYPE_NONE=y

Neither one of these last 2 are properly set when I look at the output .config file. The VALIDATE_SLOT0=y. Is there any way to have the single app option and not verify the slot0 CRC?

It looks like in the previous app, we had the 2nd slot setup as external flash but we were just not using the 2nd slot so no validation was required. I don't want to do this again because we are not using external flash to store an image.

Any assistance would be appreciated.

[adunk]

Previously I was able to see that the these settings were not taking effect by looking at the .config file in the build/mcuboot/zephyr folder. It was also obvious that the validation was taking place due to the 2 second delay before entering the application. Regardless of what settings I changed in the sysbuild/mcuboot/prj.conf file, they weren't being applied to the project.

After continuing to read about mcuboot, nordic, and zephyr, I tried making the change by selecting mcuboot in the vs code/Applications window and then using the nRF kconfig GUI Action. I changed the MCUBoot settings to Single slot and deselected "Validate image in the primary slot on every boot" and then I noticed that setting finally went away in the kconfig and then I loaded the code and it worked. This is great but the problem is it looks like the setting is being applied to the bootloader\mcuboot\boot\zephyr\prj.conf file. I want this setting to be within the project workspace such as within the sysbuild/mcuboot folder. 

If I change the sdk and do a west update, these files will revert back to their original state and those settings are lost. 

[Vidar Berg]

Hello,

I couldn’t reproduce the issue of being unable to unselect the CONFIG_BOOT_VALIDATE_SLOT0 symbol.

Did you check the build output to see if there were any Kconfig warnings that might explain why the symbol ended up being selected even though it was set to =n in your config? It’s generally easier to troubleshoot Kconfig issues when it’s the other way around where you’re trying to enable something.

EDIT: I would also recommend considering the BOOT_VALIDATE_SLOT0_ONCE config. It's a bit safer.

Best regards,

Vidar

[adunk]

I reverted the prj.conf within the bootloader back to its original state. Then I rebuilt with the desired settings in my sysbuild/mcuboot/prj.conf and I get the same results. You can see here on the right that the result is to validate the slot.

[adunk]

I do have a couple of warnings I'm looking into.

warning: UPDATEABLE_IMAGE_NUMBER (defined at C:/Projects/Reach/hp-fw/zfw-wksp/handpiece-
fw/reach_hp\dfu/conf/Kconfig.dfu:149, C:/Projects/Reach/hp-fw/zfw-
wksp/nrf\samples\common\mcumgr_bt_ota_dfu/Kconfig:89, subsys/dfu/Kconfig:95) was assigned the value
'1' but got the value ''. Check these unsatisfied dependencies: ((AUDIO_DFU = 2 && NRF5340_AUDIO) ||
((BOARD_THINGY53_NRF5340_CPUAPP || BOARD_THINGY53_NRF5340_CPUAPP_NS) && SOC_SERIES_NRF53X &&
NCS_SAMPLE_MCUMGR_BT_OTA_DFU) || (!MCUBOOT && IMG_MANAGER)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_UPDATEABLE_IMAGE_NUMBER and/or look up
UPDATEABLE_IMAGE_NUMBER in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.


warning: PM (defined at C:/Projects/Reach/hp-fw/zfw-
wksp/zephyr/soc/silabs\silabs_s2\efr32bg22\Kconfig.defconfig:12, C:/Projects/Reach/hp-fw/zfw-
wksp/zephyr/soc/silabs\silabs_s2\efr32bg27\Kconfig.defconfig:12, C:/Projects/Reach/hp-fw/zfw-
wksp/zephyr/soc/silabs\silabs_s2\efr32mg24\Kconfig.defconfig:12, subsys/pm/Kconfig:13) was assigned
the value 'y' but got the value 'n'. Check these unsatisfied dependencies: ((SOC_SERIES_EFR32BG22 &&
SOC_VENDOR_SILABS) || (SOC_SERIES_EFR32BG27 && SOC_VENDOR_SILABS) || (SOC_SERIES_EFR32MG24 &&
SOC_VENDOR_SILABS) || (SYS_CLOCK_EXISTS && HAS_PM)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_PM and/or look up PM in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.


warning: MCUBOOT_UPDATE_FOOTER_SIZE (defined at subsys/dfu/Kconfig:54) was assigned the value '0x0'
but got the value ''. Check these unsatisfied dependencies: MCUBOOT_IMG_MANAGER (=n), IMG_MANAGER
(=n). See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUBOOT_UPDATE_FOOTER_SIZE and/or
look up MCUBOOT_UPDATE_FOOTER_SIZE in the menuconfig/guiconfig interface. The Application
Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of
the manual might be helpful too.

[Vidar Berg]

None of these seem directly related to the issue. But I think the warning regarding UPDATEABLE_IMAGE_NUMBER and MCUBOOT_UPDATE_FOOTER_SIZE should go away if you add the following two lines to your sysbuild.conf

SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=y
SB_CONFIG_MCUBOOT_APP_SYNC_UPDATEABLE_IMAGES=n

CONFIG_PM is not supported on the nRF53 (has no use), so you can remove CONFIG_PM=y from your project configuration. 

Here is the project I used for test:

hello_world_serial_recovery_usb.zip

[adunk]

I already have the single app enabled in sysbuild.conf

When I pull in your project and add the setting to sysbuild/mcuboot/prj.conf, the output .config changes as I would expect. But the difference is this is a standalone project. The project I am having issues with is a West project. Do you have any way to test this same SerialRecovery project in a West environment?

[Vidar Berg]

Did you also try with SB_CONFIG_MCUBOOT_APP_SYNC_UPDATEABLE_IMAGES=n too. I don't see it listed from the screenshot you posted.

It should not make any difference whether this is a standalone project or a "west project".

[adunk]

I added that and no difference. I think the proper term for my project configuration is West t2 topology. I will continue to look for where this is getting overwritten.