Skip to main content
Visitor II
August 23, 2023
Solved

STM32H563 TrustZone - USART3 Interrupts Not Working when Non-Secure

  • August 23, 2023
  • 1 reply
  • 2793 views

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.
    Best answer by mathieuM

    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

    mathieuMAuthorAnswer
    Visitor 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!