STM32Cube UART1 receive interrupt issues: Interrupt handler not linked (using IAR)

geof · ‎2014-09-18

Posted on September 18, 2014 at 18:08

Hello Friends,

Can you please advise me on an issue (which is most likely to be due to an error I am making).

Using STM32Cube version 4.3.1, I put together a project for a Cortex M4 that will use USART1 in asynchronous bidirectional mode. I am using IAR (not that that should matter but just in case).

I am able to send strings of data out of UART using the HAL_UART_Transmit() function, no problems.

However I want to obtain and process an interrupt every time a single character gets received by the UART. (I have my own input string handler.) To move in this direction, I added a line of code to USART1_IRQHandler() as follows:

void USART1_IRQHandler(void)

{

HAL_NVIC_ClearPendingIRQ(USART1_IRQn);

HAL_UART_IRQHandler(&huart1);

cin = huart1.Instance->DR & 0x00FF; // this is a uint8_t declared elsewhere

}

I will eventually do something else.

Well, that interrupt never gets generated when I send data to the processor. More telling though, when I try to set a breakpoint withint he USART1_IRQHandler() function, I am unable to do so. I can set a breakpoint in SysTick_Handler() so I know that file is being included.

In the STM32Cube project under the Configuration tab, I did configure the USART1 so that USART1 global interrupt is enabled. The Preemption Priority and Sub Priority are both set to zero. When I click on the NVIC button, I see again that USART1 global interrupt is enabled.

Thank You for reading this.

Geof

Edit: I modified the title of this thread to clarify it's contents.

#stm32cube-working-now?

Montassar BEN ROMDHANE_O · ‎2014-09-18

Posted on September 18, 2014 at 18:44

Hi Geof,

It seems a duplicate [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM32Cube%20%20UART%20Receive%20Interrupt&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=77]thread.

Regards,

Heisenberg

geof · ‎2014-09-18

Posted on September 18, 2014 at 19:59

Hello Heisenberg (and others),

Thank You for your fast reply! I did see and study that other thread you linked before posting the above.

Let me put it another way- It appears that the USART1_IRQHandler function is somehow not linked. I looked at the .map file and could not find that function in the report. The .map file *did* include the SysTick_Handler function so I do know that the compiler took the stm32f4xxx_it.c file.

I would have thought that STM32Cube would set up the project so that everything, including interrupt handlers, needed would be compiled/linked, but this seems not the case. Is there something silly I am missing?

Thank You Kindly,

Geof

Tesla DeLorean · ‎2014-09-18

Posted on September 19, 2014 at 01:17

I would have thought that STM32Cube would set up the project so that everything, including interrupt handlers, needed would be compiled/linked, but this seems not the case. Is there something silly I am missing?

Well the evidence suggests Cube hasn't quite met/exceeded the Shakespeare-Monkey Criterion for automatic code generation yet.

It's a bit odd it's in the .C but not in the .MAP, did it get into the .O file? Is there some date/time issue stopping it from incrementally building properly? Rebuild All? Perhaps you can objdump/fromelf a disassembly of STM32Fxxx_it.o

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

geof · ‎2014-09-19

Posted on September 19, 2014 at 20:17

Clive- Thank You for your response.

I tried two things: First, I contacted IAR and they suggested adding the __root keyword to the interrupt handler. When I did that, the USART1_IRQHandler *did* finally appear in the .map file as well as in the disassembly window and so was linked. However the interrupt was still not properly handled- when I sent a single byte to the UART, the program just went to an infinite loop in NMI_Handler. So something still is not right.

''Rebuild all'' did not help any. I'm not sure how to do an objdump but will look into it.

If anyone from the Cube team can suggest anything else to try, I am all ears and will try to help out since I do like the premise of Cube.

frankmeyer9 · ‎2014-09-22

Posted on September 22, 2014 at 14:09

Not only must the interrupt handler be present in the executable, its start address must be at the right place in the vector table. This is usually achieved by giving the handler the same name as the appropriate symbol in the vector table. The latter is usually situated in the startup.S file, i.e. assembler code. The rest is managed by the linker.

Not sure how IAR manages it.

I'm not sure how to do an objdump but will look into it.

Using objdump, you can disassemble the built project, and check for the above mentioned circumstances. Can't cite the proper call flags by heart, but shouldn't be too difficult ...

If anyone from the Cube team can suggest anything else to try, I am all ears and will try to help out since I do like the premise of Cube.

After the first bug reports, and invoking several years of experience with ''first versions'' of development tools in general, I decided to shun Cube indefinitely.

The standard peripherals libraries, albeit far from being perfect, are much more stable.

Montassar BEN ROMDHANE_O · ‎2015-01-19

Posted on January 19, 2015 at 12:10

Hi all,

After discussion with our development team, it turned out that this implementation is not adequate as the interruption sub-routine is polling the status register during the 2 last characters period.

We have already the limitation in the STM32Cube HAL bugs list, and it will be fixed in next releases of F4. Please continue submitting your valuable feedback.

Regards,

Heisenberg.

geof · ‎2015-08-27

Posted on August 27, 2015 at 23:43

Heisenberg, everyone,

I'm trying another go at 'Cube, using the most recent version available as of today (27 August 2015). I am still not able to generate a UART interrupt, e.g. the function USART1_IRQHandler() never gets called when I send data via UART. (The processor transmits UART just fine though.)

This time, the USART1_IRQHandler function *is* in the .map file. But, alas, still no interrupt.

Is it fair to say that STM32Cube is still not working, or is there still something I am missing?

Thanks!

Geof

Nickname5522_O · ‎2015-08-28

Posted on August 28, 2015 at 16:55

Hi barrows.geoffrey,

Did you turn the example under

STM32Cube_FW_F4_V1.7.0\Projects\STM32F429I-Discovery\Examples\UART\UART_TwoBoards_ComIT? Have a look at it.

-Shahrzad-

manelvidala · ‎2016-07-18

Posted on July 18, 2016 at 09:44

I had the same problem.

Interrupt

handler never

jumped

.

Solution: Use for

USART1_RX

PB7 pin instead of PA10.

/ * RX USART1

PB7

* /

#define

USARTx_RX_PIN

GPIO_Pin_7

#define

USARTx_RX_GPIO_PORT

GPIOB

#define USARTx_RX_GPIO_CLK

RCC_AHB1Periph_GPIOB

#define USARTx_RX_SOURCE GPIO_ PinSource7

#define

USARTx_RX_AF

GPIO_AF_USART1

Analysis of the problem: I looked at the oscilloscope senyal receiving PA10 when my

converting

USB-USART sending data . The low

signal level

was above 1/2 VCC. Actually, my STM32F429I was not getting

anything.

Therefore, the interrupt is not activated.

Possible cause: the pin PA10 is prepared for USB communication

and has

different value of resistance Pull_Up and Pull_Down.

Another possible solution: Try a different USB-USART

or amplify

TX

senyal

of our USB-USART to ensure that we get correct

digital values.