Electronic – What happens on STM32 when multiple (UART) Interrupts are triggered at the same time? is there an interrupt stack

cortex-mstm32uart

I'm implementing a uart daisy-chain communication scheme with a Cortex M4.
When a node receives a byte over one UART, an interrupt is generated (RXNE) and the byte is written out over another UART – since I use a send and receive buffer, this places the byte in the send buffer and enables the TXE interrupt which should be triggered subsequently.

This means for every byte received, two interrupts are triggered.

Now both UARTs can receive and transmit, and it is very much possible that both UARTs do receive a byte at the same time – now both will get a RXNE interrupt and trigger a TXE interrupt on the other UART.

But only one ISR can be processed at the same time – what happens with the other ones?

Is there an interrupt stack that can get full or interrupts simply called until all corresponding interrupt bits are cleared?

The thing is that my application tends to lock up under the situation described above (with multiple bytes being received). Not however when the UARTs are set to a lower speed (this seems counter intuitive) or when there is only one side connected.

Best Answer

What you are doing is quite normal and it should be possible to get it to work correctly.

The M4 processors have several dozen interrupt sources and it is very common for 2 or more interrupt requests (IRQ's) to become active at the same time. The IRQ's are "latched" by the interrupt logic and the interrupt controller decides on the basis of priority which one to process first (by vectoring to the interrupt handler). The 2nd IRQ is still latched, and is termed a "pending interrupt". In simple terms when an interrupt handler has completed its processing it has to execute a special instruction called a "return from interrupt" which allows the interrupt controller to process the next pending IRQ.

Although we sometimes talk about "stacked interrupts" in a situation like yours, they are not kept on a "stack" as such, and so it cannot run out of space and loose IRQ's. Generally the IRQ's remain latched until the corresponding IRQ bit is cleared by software.

It is difficult to know exactly why your system is locking up, you may have to provide more details. A couple of things to look at:

Is your interrupt handler always clearing the corresponding IRQ flag? If the flag is not cleared then the processor can get locked in a loop constantly vectoring to the handler and not allowing other things to run.
Does your interrupt handler always exit correctly by executing a "return from interrupt" special instruction? If it does not then it will not allow the interrupt controller to handle another IRQ at the same priority level, and it will appear that your processor is no longer responding to these interrupts.

Related Solutions

Electronic – Interrupt handling for a UART on PIC32 with C32 v2.00 compiler

Your example code doesn't show any of the initialization for the UART.

Are you enabling the receive interrupt for the UART? You need to do something like this:

#define BAUDRATE1       (115200)     // the desired BaudRate
#define BRATE1    (FPB/4/BAUDRATE1) 
#define UART1_CONFIG1   UART_EN|UART_BRGH_FOUR      // defaults to 8,N,1
#define UART1_CONFIG2   UART_RX_ENABLE|UART_TX_ENABLE|UART_INT_RX_CHAR              // only RX interrupts

void ConfigureUart1(void)
{
    OpenUART1(UART1_CONFIG1, UART1_CONFIG2, BRATE1); // approx 115200 baud
}

where FPB is defined as your peripheral bus frequency, e.g. 10000000L for 10 MHz.

Then in main or elsewhere:

ConfigureUart1();
INTEnableSystemMultiVectoredInt();         
INTEnableInterrupts();

Electronic – What can be the cause of an exceptionally large latency for the UART receive interrupt

I'm assuming that you're using the same debugging process I would do in this case -- one of the first instructions in the interrupt routine turns on a LED, and one of the last instructions in the interrupt routine turns that LED off.

Then you used a dual-trace oscilloscope with one probe clipped to the appropriate pin to watch the bytes going into the UART, and the other probe clipped to the pin driving the LED.

I'm assuming your UART-handler interrupt routine ends with the return-from-interrupt instruction (rather than using the return-from-subroutine instruction used by normal instructions).

There are 4 things that can cause a long latency between the end of the last byte of a message and the start of the UART handler:

Some previous byte in the message triggering the UART handler, and somehow it takes a long time before interrupts are re-enabled. Some people structure their interrupt routines so that after the UART handler finishes storing a byte in the appropriate buffer, it checks a bunch of other stuff before executing the return-from-interrupt instruction -- it increases jitter and latency, but sometimes those people do it anyway because it improves throughput.
Some other interrupt taking a long time to execute before it re-enables the interrupts by executing the return-from-interrupt instruction. (If you can make each and every interrupt turn on and off some other LED, it's pretty easy to see on the o'scope if this is the problem or to rule this out).
Some non-interrupt code "temporarily" turning off interrupts. (This increases jitter and latency, but people do it anyway, because it's often the easiest way to prevent data corruption when both some interrupt and some main-loop background task both work with the same piece of data). (If you can make every bit of code that does this turn on and off some other LED, it's pretty easy to see on the o'scope if this is the problem or to rule this out).
Instructions that take a long time to execute.

The traditional way to figure out exactly what is causing the problem is to save the current version of your code (you're using TortoiseHg or some other version control system, right?), and then deliberately hack and slash at a temporary copy of your code, stubbing out and completely removing code a few subroutines at a time, re-testing after each round of deletions, until you have a tiny -- yet technically "complete" and runnable -- program that exhibits the same problem.

Far too often people show us bits and pieces of a complete program -- the parts those people think are relevant -- and we can't help them because one of the pieces they omitted is causing the problem.

The process of reducing a program to a small test case is a very useful skill, because often while going through that process, you quickly discover what the real problem is.

Once you have such a tiny -- yet runnable -- program, please post it here. If you figure out what the problem is during that process, please tell us that as well, so the rest of us can avoid that problem.

Best Answer

Related Solutions

Electronic – Interrupt handling for a UART on PIC32 with C32 v2.00 compiler

Electronic – What can be the cause of an exceptionally large latency for the UART receive interrupt

Related Topic