cancel
Showing results for 
Search instead for 
Did you mean: 

strange interrupt behaviour

mmensch
Associate II
Posted on August 18, 2014 at 16:39

Hi,

I hope someone can explain this strange behaviour using interrupts on a STM32L151:

I send out data via a UART using a software ring buffer. To know how much data are there to be send I use an integer counter variable. Data is fed into DR register in an interrupt routine (TXE). So there is a need to change the counter inside (reading the buffer) and outside (filling the buffer) the interrupt service routine. Therefore outside the isr before incrementing the counter I disable the interrupt (clearing TXEIE) and enable it again afterwards.

But that fails. Still my buffer gets corrupted after pretty short time.

A solution I found is to insert a number of nop after clearing TXEIE and I found that I need exactly 7 nops to make it run, well at least much longer without any corruption as far as I can tell now. With 6 nops it still fails pretty fast.

Where does this behaviour come from?

How can I make an interrupt disable become active at once after the respective line of code ?

Thanks a lot for any hint.

Martin

#volatile
2 REPLIES 2
os_kopernika
Associate II
Posted on August 18, 2014 at 19:09

volatile?

Posted on August 19, 2014 at 19:15

Doesn't resolve potential atomic issues. Don't have two threads doing RMW operations on the same variable. Could guard with __disable_irq/__enable_irq or cpsie i/cpsid i

Best to compute used/free space by doing math on head/tail values, and only ONE is changed by interrupt (emptying side), the other only by the filling side.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..