cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H725ZGT6 suspected error in documentation - interrupt table

JCase.1
Associate III

I am using the STM32H725ZGT6 for a new client application.  I have used it many times before.  This application requires three UARTs running, so I am using USART10 for one of them.  I have not used USART10 before.

My code runs all 3 UARTs the same -- interrupt service on RX (which just reads the byte and puts it in a buffer), while TX is driven by code clocking. 

My problem is that the USART10 interrupt is not interrupting.  The other two behave textbook (USART1, UART7), but USART10 is dead.  The UART hardware is configured ok and runs ok when polled, but the symptoms act as if I am enabling the wrong interrupt bit.    I have seen some oblique references doing web searches to offsets / errors in the interrupt table documentation, past some point in the table.  That would be consistent since USART10 is near the end of the table.   I have searched the chip documentation and errata, however, and found nothing.

I am using 0x02B0 for the vector location, and as the documentation says this is interrupt #156 I am enabling it with bit 28 of NVIC_ISER4.

Am I doing something *** or have I stumbled across an error not in the Errata pages?    Help please.

Jeff Casey  /  Rockfield Research Inc.,  Cedar City, Utah, USA.     casey@rockfieldresearch.com

 

2 REPLIES 2
TDK
Guru

Works fine for me on an H723, should be the same internals. New project, initialize USART10 and use HAL_UART_Transmit_IT to send. All working.

Your offsets and interrupt numbers look correct. Must be something.

Show your USART10 registers and process stack at a point when you think an interrupt should be happening. You could be in a different interrupt of same/higher priority that isn't yielding priority. Could be that data just isn't coming in, so no interrupt necessary.

If you feel a post has answered your question, please click "Accept as Solution".
JCase.1
Associate III

Thanks, but the answer was far more *** -- I had previously disabled the UART for some debugging, and the line to disable it wasn't commented out.   Apologies to all, disregard post.