dfu issues after migrating from ncs2.9.2 to ncs3.0.2

[ziv123]

hello Nordic

we are working with nrf52840/nrf52832 with ncs (currently on v3.0.2)

i have noticed that when i try to dfu a merged artifact of my version with the new mcuboot of ncs3.0.2 the device does not work after the dfu at all, it seems bricked no matter if i try to reset it after or even try to re flash the same version of merged file with the same mcuboot of ncs3.0.2 it does not respond .. only after flashing a lower version it returns to work (this part is very strange i think)

in previous version with ncs2.9.2 there was no issues with the dfu ..

under app/
sysbuild.conf
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
SB_CONFIG_PARTITION_MANAGER=y
SB_CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y

sysbuild_swap.conf
SB_CONFIG_MCUBOOT_MODE_SWAP_SCRATCH=y

sysbuild_no_swap.conf
SB_CONFIG_MCUBOOT_MODE_SWAP_SCRATCH=n
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

prj.conf under app/sysbuild/my_app/mcuboot/
CONFIG_FLASH=y
CONFIG_FLASH_xxxx_API=x
CONFIG_MAIN_STACK_SIZE=xxxx

1. any ideas what can be the cause and how can this be fixed ?

2. any idea how to debug the mcuboot using rtt ? i don't want to flash a version via cursor or vscode because then dfu will not work for some other signature reason 

best regards

Ziv

[Vidar Berg]

Hello Ziv,

Do I understand correctly that the application does not boot even after completely re-flashing the device with the merged.hex from the latest version? That would suggest that there is an issue with the new project/app and not really related to the DFU process. First step I would recommend is that you try to debug the new project to find out where the program hangs. Does the app run ok if you build without the bootloader?

Best regards,

Vidar

[ziv123]

the app runs fine and it was also dfued to our setups, which runs with older mcuboots on them, with no issues.

it also runs fine after first flash of the merged hex with mcuboot and app of ncs3.0.2, but after dfu it seems briked and only after few flashes with older version merges the device run again (this was very strange to me since i flash with the flag of --chipearse" i did not expect that first flash will not work)

[Vidar Berg]

Are you using external flash (SPI/QSPI) for staging FW updates and are you using the same static PM file for both versions of your project?

[ziv123]

we do dfu via ble 

we have external flash via spi .. and we use it for saving one image slot and other things off course

we have a pm_static_board_name.yml for each board

hut we also have board_name.overlay for each board.. i think i read in the past one of them is overwritten or ignored in zephyr if you have the other (don't really remember) 

[Vidar Berg]

ziv123 said:

we have external flash via spi .. and we use it for saving one image slot and other things off course

The bootloader will not boot the application if it fails to access the secondary slot in external flash so I wonder if the issue might be that the SPI fiash has gotten into a bad state somehow. Does your HW allow you to power cycle the board so that both the SPI flash and nRF get reset?

ziv123 said:

we have a pm_static_board_name.yml for each board

You can check the pm .yml file in the build folder to verify that the same pm file is applied in both builds. Alternatively, run "west build -t partition_manager_report".

ziv123 said:

hut we also have board_name.overlay for each board.. i think i read in the past one of them is overwritten or ignored in zephyr if you have the other (don't really remember) 

Devicetree partitions are ignored when using the partition manager, yes.