cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H563 TrustZone - USART3 Interrupts Not Working when Non-Secure

mathieuM
Associate II

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,

1 ACCEPTED SOLUTION

Accepted Solutions
mathieuM
Associate II

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!

View solution in original post

1 REPLY 1
mathieuM
Associate II

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!