Issue with FDCAN and USB Interrupts in Non-Secure Loader

[macar]

Hello,

I am working on the X‑CUBE‑AZURE TFM_Azure_IoT example for the B‑U585I‑IOT02A board and would like to replace the default UART loader with CAN and USB loaders. While the non-secure loader boots and runs correctly, the non-secure interrupts for FDCAN and USB do not trigger. In the application, both peripherals work with interrupts, but in the loader, they do not.

To make this change, I modified the loader's non-secure application size to accommodate the FDCAN and USB stacks. However, I am encountering issues with interrupts not firing.

I have verified that FDCAN works in polling mode in the non-secure loader application.

Environment:

Board: B‑U585I‑IOT02A (STM32U585)

X‑CUBE‑AZURE: TFM_Azure_IoT (v2.3.0)

Toolchain/IDE: STM32CubeIDE

What I've tried:

Adjusted the non-secure application size to fit the CAN and USB stacks.

Ensured the peripherals are initialized in the non-secure context.

Checked the interrupt enablement for CAN and USB, but no interrupts are firing.

Thanks in advance!

[macar]

Also tested UART interrupt that is not working at non secure loader app.

 

[Jocelyn RICARD]

Hello @macar ,

you need to assign interrupt to non secure.

The issue here is that secure boot (TFM_SBSFU_Boot) calls directly the loader non secure instead of loader secure. (Loader secure is only called if MCUBOOT_PRIMARY_ONLY flag is set)

So, either you force the secure boot to jump to the secure part of the loader where all interrupt are assigned to non secure by detault (it may need some small adaptations in the environment) or you assign the interrupts to non secure just before jumping in the loader non secure in function execute_loader().

Something like NVIC->ITNS[i]=0xFFFFFFFF; with i in 0 .. 3

Best regards

Jocelyn

[macar]

Hello @Jocelyn RICARD ,

Thank you for your explanation.

I assigned all interrupts to the Non-Secure domain immediately before locking the Secure vector table:

/* Lock Secure Vector Table */
SYSCFG->CSLCKR |= SYSCFG_CSLCKR_LOCKSVTAIRCR;

Just before this line, I configured:

for (uint32_t i = 0; i < 4; i++)
{
 NVIC->ITNS[i] = 0xFFFFFFFF;
}

Additionally, I updated SCB->VTOR to LOADER_NS_CODE_START in the SystemInit() function of the Non-Secure loader application to ensure proper relocation of the vector table.

However, despite these changes, interrupts are still not firing in the Non-Secure loader.

Is there any additional configuration required before branching to the Non-Secure loader application?

Any guidance on what I might be missing would be greatly appreciated.

Best regards.

[Jocelyn RICARD]

Hello @macar ,

The secure boot locks the vector already, so I don't think this is necessary.

/* set the vector */
 SCB_NS->VTOR = LOADER_NS_CODE_START;

 /* Lock Secure Vector Table */
 SYSCFG->CSLCKR |= SYSCFG_CSLCKR_LOCKSVTAIRCR;

Looks like GPIO are setup to non secure, SRAM1 is non secure.

Maybe the clocking is not setup properly because one RCC component would be still secure ? To be checked.

One other point to check, in case you use DMA, please set SRAM1 in non privilege in boot_clean_ns_ram_area():

Add GTZC_MPCBB1_S->PRIVCFGR[index] = 0; in the loop.

But I doubt this is the case.

No other idea

Best regards

Jocelyn

[macar]

Hello Jocelyn,

Thank you again for the detailed checks and suggestions.

Regarding your note about adding the following line in boot_clean_ns_ram_area()

GTZC_MPCBB1_S->PRIVCFGR[index] = 0;

I tried adding this as suggested, but unfortunately it did not change the behavior.

On the TFM non-secure application side, I already have a fully working firmware update mechanism via Azure IoT, so interrupts and peripherals operate normally there. Because of this, I’m considering moving the FDCAN and USB firmware update flow from the Loader to the non-secure application. Since I know the interrupts for these peripherals work correctly in the NS application, this might bypass the issue entirely.

Before proceeding, I would like to ask:

Is there any security impact or drawback if the firmware update over FDCAN/USB is performed entirely in the non-secure application instead of in the Loader?
The secure boot will still verify the firmware image before booting, so the integrity check remains intact. However, I want to confirm whether this architecture is acceptable from a TFM/SBSFU perspective.

Any guidance you can provide would be greatly appreciated.

Best regards.

[Jocelyn RICARD]

Hi @macar ,

when you are using dual slot configuration (active + download), the standalone loader is actually optional.

It could be used as a fallback in case active application is no more able to download new application in download slot.

Now as you are using only local serial connection, you could also have a single slot setup. In such case, you would have more space for application. When update is requested, application can write a MAGIC and reset. The secure boot will detect this MAGIC in RAM or BACKUP RAM, and jump directly in the loader. Loader would wait for request to download a new image, would first erase the application (secure or not secure) and download the update.

In such configuration, the loader secure is also used to be able to access to secure slot.

In term of security, the secure boot limits the capabilities of the loader by locking the MPU.

One drawback with loader is that it cannot be updated.

To answer your question, the firmware update is not done by the non secure application.

Only download of signed/encrypted update image is performed by non secure application. Actual installation is done by the secure boot. So, there is no risk to install a fake firmware.

Best regards

Jocelyn