2023-08-23 03:03 PM
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,
Solved! Go to Solution.
2023-09-05 09:07 AM - edited 2023-09-05 09:14 AM
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!
2023-09-05 09:07 AM - edited 2023-09-05 09:14 AM
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!