Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

PIC32 Non-Atomic Interrupt clear

Posted by graham clark on 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

Graham

RE: PIC32 Non-Atomic Interrupt clear

Posted by Dave on 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.

RE: PIC32 Non-Atomic Interrupt clear

Posted by graham clark on 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?




RE: PIC32 Non-Atomic Interrupt clear

Posted by graham clark on 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists