Skip to main content
Associate II
August 23, 2023
Solved

STM32H563 TrustZone - USART3 Interrupts Not Working when Non-Secure

Hi, 

I'm currently working on a project that uses TrustZone with non-secure peripherals, but I'm having problems with non-secure interrupts.

When I configure USART3 as a secure peripheral in my project, USART3_IRQHandler and GPDMA1_Channel0_IRQHandler interrupts are working fine (in Secure/stm32h5xx_it.c). However, when I configure USART3 as non-secure, these same interrupts don't fire now (now in NonSecure/stm32h5xx_it.c). I verified that the interrupts and DMA are enabled, and that they are included in the NVIC_NS. The USART3 seems to be initialized the right way because using HAL_UART_Transmit works in secure and non-secure modes. However HAL_UART_Transmit_IT and HAL_UART_Transmit_DMA work with USART3 as secure, but not as non-secure.

To deepen my investigation, I wanted to see if the problem was with ALL non-secure interrupts. In a different project, I configured ThreadX as non-secure (using TIM1 as SYS) with the same USART3. The TIM1_IRQHandler is firing, but I get the same problems that the USART3_IRQHandler and GPDMA1_Channel0_IRQHandler interrupts are not firing.

I tried configuring the SAU and GTZC, but I'm new to TrustZone and maybe I'm missing something... I've made sure that the interrupts are marked as non-secure in the partition file:

// <o.29> GPDMA1_Channel0_IRQn <1=> Non-Secure state

// <o.31> USART3_IRQn <1=> Non-Secure state

Can someone help me with this problem or give me some paths towards a solution? I added screenshots of CubeMX configs and the partition file.

Thanks in advance,

This topic has been closed for replies.
mathieuMBest answer
Associate II
September 5, 2023

Turns out that there is a bug in CubeMX code generation. The NVIC vector table contains errors: IWDG_IRQn and SAES_IRQn are not at the right position in the partition_stm32h563xx.h file and there is shifting with some other interrupts.

In STM32H563/H573 and STM32H562 Arm<Sup>®</Sup>-based 32-bit MCUs - Reference manual, IWDG_IRQn and SAES_IRQn are position 35 and 36 respectively (see manual_vector_table.png), but in the generated partition_stm32h563xx.h file, they are placed at position 27 and 28 (see partition_vector_table.png). The result is that interrupts after position 27 are shifted by two positions in the NVIC_INIT_ITNS0_VAL and GPDMA1 interrupts are not at their right position in NVIC_INIT_ITNS1_VAL. There are also errors regarding USART3 position in NVIC_INIT_ITNS1_VAL. Everything is working if I change the values of NVIC_INIT_ITNS0_VAL and NVIC_INIT_ITNS1_VAL to the good ones:

 

[412] #define NVIC_INIT_ITNS0_VAL 0x20000000
...
[458] #define NVIC_INIT_ITNS1_VAL 0x80000400

 

TO

 

[412] #define NVIC_INIT_ITNS0_VAL 0x08000000
...
[458] #define NVIC_INIT_ITNS1_VAL 0x10000400

 

I hope that STM can fix this bug in the next release of CubeMX!

1 reply

mathieuMAuthorBest answer
Associate II
September 5, 2023

Turns out that there is a bug in CubeMX code generation. The NVIC vector table contains errors: IWDG_IRQn and SAES_IRQn are not at the right position in the partition_stm32h563xx.h file and there is shifting with some other interrupts.

In STM32H563/H573 and STM32H562 Arm<Sup>®</Sup>-based 32-bit MCUs - Reference manual, IWDG_IRQn and SAES_IRQn are position 35 and 36 respectively (see manual_vector_table.png), but in the generated partition_stm32h563xx.h file, they are placed at position 27 and 28 (see partition_vector_table.png). The result is that interrupts after position 27 are shifted by two positions in the NVIC_INIT_ITNS0_VAL and GPDMA1 interrupts are not at their right position in NVIC_INIT_ITNS1_VAL. There are also errors regarding USART3 position in NVIC_INIT_ITNS1_VAL. Everything is working if I change the values of NVIC_INIT_ITNS0_VAL and NVIC_INIT_ITNS1_VAL to the good ones:

 

[412] #define NVIC_INIT_ITNS0_VAL 0x20000000
...
[458] #define NVIC_INIT_ITNS1_VAL 0x80000400

 

TO

 

[412] #define NVIC_INIT_ITNS0_VAL 0x08000000
...
[458] #define NVIC_INIT_ITNS1_VAL 0x10000400

 

I hope that STM can fix this bug in the next release of CubeMX!