cancel
Showing results for 
Search instead for 
Did you mean: 

Infinite_Loop during UART operation

hamid hassannejad
Associate II
Posted on February 28, 2018 at 11:35

Hi,

I am using

STM32F446RETxNucleo board formy application. It was working fine till I added a new operations including asynchronous data exchange on UART5. Now

, sometimes during data exchange on the serial channel, the debbuger (the application is written in Truesudio, using HAL libraries) jumpes into thisInfinite_Loop:

/**
 * @brief This is the code that gets called when the processor receives an 
 * unexpected interrupt. This simply enters an infinite loop, preserving
 * the system state for examination by a debugger.
 * @param None 
 * @retval None 
*/
 .section .text.Default_Handler,'ax',%progbits
Default_Handler:
Infinite_Loop:
 b Infinite_Loop
.
.
.

The comment of the loop says that there might be an 'unexpected interrupt', however inside the startup file (startup_stm32f446xx.s) I see all my interrupts and their 'weak descriptions'. I also controlled the code several times and it seems to be fine.

So, I have two questions: first, how can I discovert which interrupt caused this problem? then, do you have any advice to handle this problem?

I appreciate any hint on this matter! Thank you!

#infinite_loop #startup-file #uart-interrupt-stm32f4
7 REPLIES 7
Posted on February 28, 2018 at 12:20

Almost always a missing or misspelled IRQ Handler name.

You could have a build where you make them non-weak and see which ones the linker indicates are already defined. You could check the enabled peripherials for an active interrupt flags.

Check UART vs USART naming .

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
AvaTar
Lead
Posted on February 28, 2018 at 12:20

Wouldn't Truestudio have a call stack display in debugger mode, where you see what it came from ?

Otherwise, check the SCB registers for error flags.

But the UART interrupt would be the prime suspect.

Posted on February 28, 2018 at 14:32

Thank you for the reply!

First of all, as far as I know, stack display or analyzer of TrueStudio is not available on the free version that I am using.

Then, I don't think that it is the UART interrupt, because the problem does not happen with all the serial data exchanges. Usually, I can have several data exchanges before encountering the Infinit_Loop.

About the SCB, I looked in it, but, actually I do not really know what should I look for. 

Posted on February 28, 2018 at 14:40

TrueStudio is now free of charge for all STM32 users. Meaning the previous Pro version now is free:

https://atollic.com/resources/download/windows/

 

Maybe some code would be useful do understand what's wrong.

Posted on February 28, 2018 at 14:46

Thank you Clive One,

Actually, the startup file is created automatically. I used CubeMX to start the project and everything is done using the standard procedures. Moreover, I confronted, manually and by using search feature of the editor, each interrupt implemented inside stm32f4xx_it with the contens of the startup file. They were all identical. However, I also need to check the interrupt flag that you mentioned! 

Posted on February 28, 2018 at 15:56

Thank you! I've just installed it.

Posted on February 28, 2018 at 15:59

About the SCB, I looked in it, but, actually I do not really know what should I look for.

The linked document should give you some explanations:

http://www.keil.com/appnotes/files/apnt209.pdf

 

I don't use Cube, and don't comment on this kind of auto-generated code.

Perhaps you end up in the hardfault handler, either because of a stack overflow, or another, unhandled exception.

The SCB register flags will tell you.