cancel
Showing results for 
Search instead for 
Did you mean: 

USART1 Interrupt does not happen on STM3210E-EVAL board. Addresses in the Vector Table are off by 1, why?

Robin Kuzmin
Associate II

Eval Board STM3210E-EVAL with MPU STM32F103ZGT6.

I'm trying to get the interrupt handler triggered upon reception of the character over UART1.

For that I got the code generated by STM32CubeIDE, fixed a bit the Rx line setting, and got the hardware reception working (the char comes to the data register UART1.DR, the "Byte Received" flag RXNE gets set (to 1) in status reg USART1.SR, the interrupt is enabled with bit RXNEIE in control reg USART1.CR1). The interrupt is enabled in NVIC.ISER1, bit 5 (corresponding to interrupt 37 of USART1 global interrupt). But the interrupt handler USART1_IRQHandler() is not triggered.

I see that the USART1_IRQHandler() handler's address is 0x80007f8. And I expect that address to be in the Interrupt Vector Table (vector at 0x0000_00D4, see the STM32F103xx Ref Man RM0008, Table 63, position 37). But at address 0x0000_00D4 I see the 0x80007f9 (instead of 0x80007f8) - the address of the handler is off by 1.

I see the same (off by 1) for other vectors. And this is observed during the first-most instruction of the Reset_Handler.

In the STM32CubeIDE (after the USART1 initialization) I use the API call HAL_UART_Receive_IT() to receive the char over USART1.

What does that off by 1 mean? Is it just a bug of IDE? Can it be the reason why the int handler is not triggered? If not then what is the reason?

Please advise.

3 REPLIES 3

16-bit Thumb code has an ODD address, where as 32-bit ARM code has an EVEN address. The Cortex-M3 only runs Thumb code

Try and see if the SysTick works

Make sure the USART1 clock is enabled. Try TXE interrupt, if that works then you simply aren't receiving things, perhaps the SR flags an error that needs clearing.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Robin Kuzmin
Associate II

Thank you for the reply and clarification.

My problem got resolved by itself. So far I was instruction-stepping when expecting the interrupt handler triggering. And the handler was not triggered (I don't know why). But when running (resuming the execution) the handler gets triggered as I expected.

This is probably the peculiarity of the GDB running under the hood of STM32CubeIDE, or the JTAG/SWD interaction somehow affects the triggering of the interrupt.

I would recommend the ST developers to investigate this. A number of people can bump into it and ask the same question again and again. I can send the project if needed.

Thank you for the help and have a wonderful Sunday!

Observing UART data register in debugger clears the RXNE but in the same way as reading it by processor.

JW