PIC32 Non-Atomic Interrupt clear

grahamfclark wrote on Tuesday, December 23, 2008:

A post was made at the Microchip PIC32 forum regarding the non-atomic behaviour of certain PIC32 instructions and their danger. In particular the clearing of interrupt flags.

The post was made by someone working for AVIS-RT rtos and is entitled "Wrong way to clear an interrupt flag, very important "

As a user of the FreeRTOS code I’d like to know if it also could be affected in some way?

The post is at http://forum.microchip.com/tm.aspx?m=391938&mpage=1&key=&#391938


davedoors wrote on Tuesday, December 23, 2008:

The MPLAB C32 compiler comes with all the macros you need, so I don’t see what the fuss is all about on that thread.

FreeRTOS uses just one timer, and the interrupt is cleared using the compiler provided macro mT1ClearIntFlag(), which is defined as:

#define mT1ClearIntFlag()                   (IFS0CLR = _IFS0_T1IF_MASK)

which is fine as far as I can see.

The demo (which is not part of the kernel code) uses a serial port interrupt that is cleared with mU2TXClearIntFlag so that is ok, and two high frequency timers that are cleared by writing to the IFS0bits register, so these could probably be improved although I would have to look at the code generated for them.

grahamfclark wrote on Tuesday, December 23, 2008:

No I agree the thread seems a bit alarmist. I tend to use the macros in my code which are atomic. 

I had a look a the port.c and, as you mention, it does use of IFS0bits in clearing the flag so I guess the issue this guy was talking about could arise there. I can see some strange side effects as the register would certainly be inconsistent.

To be quite frank I’m not sure how the read/modify/write sequence being interrupted by a higher priority int could cause a re-posting of that higher priority interrupt, which is what he seems to be saying. Maybe I’m being dumb.

Any other views?

grahamfclark wrote on Tuesday, December 23, 2008:

Looking again, the port.c kernel code I mentioned was for PIC24 and not PIC32. So it looks as though  the PIC32 port looks pretty clean.