strange interrupt behaviour

[mmensch]

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

[os_kopernika]

Posted on August 18, 2014 at 19:09

volatile?

[Tesla DeLorean]

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.