Application fails to boot with MCUboot image in external flash and TF-M

For my project I want MCUboot with the upgrade image placed in the external flash, and TF-M. I am not able to get this combo to boot however, and I suspect the reason is that MCUboot and non-secure application is fighting over the SPI bus.

In this branch I've set up Zephyr's hello world to have the same configuration, and I see MCUboot running just fine, TF-M booting and printing jump to image, but I never see the application image boot. If I move the upgrade image back into the primary flash the configuration works right away.

Is there a chance that MCUboot running the SPI peripheral in the secure world collides with the application attempting to use the SPI peripheral in the non-secure world? The SPI is not configured to be secure, but is it a requirement that the peripheral is reset after MCUboot is done with it so the application can configure it for non-secure execution?

I'm running on a nRF54LM20A DK. I have upgrade image in external flash and TF-M running in separate projects without issues, however when I combine them I can't get them to boot. In a different project I had issues when the I2C peripheral had status="okay" in both the secure and non-secure DTS, which lead to a hard fault when I initialized it in my non-secure application. I', suspecting a similar issue, that the kernel initializes the peripheral even though it's not used and this causing issues for the non-secure application.

Thanks!

Parents
  • Hello! 

    Could you share the runtime logs and/or any error messages that you run into when trying?

    Could you share your memory map (generated partitions,yml in your build folder is fine)? 

    I'm more leaning towards the option of there being a non-correct partitioning w.r.t tf-m partitions rather than a conflict of spi resources, but I'm not excluding that this could be the case

    Kind regards,
    Andreas

Reply
  • Hello! 

    Could you share the runtime logs and/or any error messages that you run into when trying?

    Could you share your memory map (generated partitions,yml in your build folder is fine)? 

    I'm more leaning towards the option of there being a non-correct partitioning w.r.t tf-m partitions rather than a conflict of spi resources, but I'm not excluding that this could be the case

    Kind regards,
    Andreas

Children
No Data
Related