- 19. February 2012: Virgil
- 11. February 2012: Maximite
- 17. January 2012: Atypical Curiosity
- 4. January 2012: PIC32MX7 PIM, RB5 pin conflict (solved)
- 30. December 2011: MikroE Mini-32 Board
- 29. December 2011: Donate to Wikipedia
- 28. December 2011: PIC32 Interrupt Nesting (update)
- 20. December 2011: Graphics Library 3.02
- 2. December 2011: Home Brewed IDE for PIC32 assembly development
- 30. November 2011: Yoda Conditions, Egyptian brackets and more...
- February 2012
- January 2012
- December 2011
- November 2011
- March 2011
- February 2011
- January 2011
- March 2010
- January 2010
- December 2009
- November 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- January 2009
- December 2008
- November 2008
- October 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
PIC32 Interrupt Nesting (update)
The more recent versions of the MPLAB C32 compiler (v1.6 and later) have changed the way interrupt nesting is defined by default by making it automatically Enabled!
The effect of this change is that of making part of the “nesting.c” example (pages 97-98 of the PIC32 book) irrelevant if not a bit misleading.
Since nesting is always automatically enabled upon entry in an ISR, using the “asm( ei)” command (or commenting it out) produces always the same result: TMR3 interrupt preempts the TMR2 ISR (while(1) loop).
From this point though the simulation will not proceed as described at step 9 (page 97 and following) but the interrupt will keep occurring continuously preventing the execution to proceed through the next few instruction and up to the increment of the counter.
In fact the nested interrupt will fail to update the IPL register with the proper TMR3 interrupt priority level (IPL3 in our example), continuing to use the IPL1 value instead as defined in the __ISR macro.
This behavior could not be observed with the original compiler setting (nesting disabled by default) because the “EI” instruction was delayed until after the entire interrupt ISR prologue, giving the processor time to reach the breakpoint if only barely.
A new macro “__ISR_SINGLE()” has been introduced to handle properly such cases. At the cost of a slightly longer prologue, each ISR entry will now make sure to set the correct corresponding Interrupt Priority Level.
I posted this comment today in the Update section of the ExploringpPIC32 site and a note was made in the Errata list.Thanks to Jean, Bruce, Skyler and Geoff for point out the issue!
Leave a Reply
You must be logged in to post a comment.