ignisuti wrote on Sunday, August 19, 2012:
Well, based on that (I’m just now learning about BASEPRI), this is looking a LOT like a Freescale Bug.
I had this code in place to determine it was the BASEPRI causing my trouble. The first delay_ms() works, but the second falls into the trap I’ve set.
delay_ms( 5 );
delay_ms( 5 );
Here is my Delay_ms() function:
== FUNCTION DESCRIPTION:
== Delays to for specified amount of milliseconds.
== For safety, 1ms is added to requested ms delay because timer could technically rollover 1us later.
/* Local Variables. */
u32 current_count = 0;
u32 trouble_counter = 0;
u32 max_trouble_count = 10000; //Observed trouble counts of 8,303 up to 9,060 while testing successes at 100MHz.
/* Record the current count from the interrupt counter. */
last_count = SYSTICK__counter__1ms;
/* Loop until the local counter matches the specified delay. */
while( TRUE )
/* Check if interrupt counter has been updated. */
if( last_count != SYSTICK__counter__1ms )
current_count++; //Increment local counter.
if( current_count >= (delay_amount + 1) ) break;
last_count = SYSTICK__counter__1ms; //Record current count;
trouble_counter = 0; //Reset trouble counter.
if( ++trouble_counter >= max_trouble_count )
//TODO: Figure out why this sometimes occurs.
DEBUG__print_error_message( "SysTick Interrupt stopped triggering!" );
//DEBUG__assert( __FILE__, __func__, __LINE__ );
} /* TIMERS__delay_ms() */
Here’s a snapshot of my PIT0 interrupt priority.
With NVICIP84 set to 0 and BASEPRI set to 0x50, I can clearly see my interrupt has stopped ticking by running through the delay_ms() function. If I use my debugger to move back to the top of the function, set BASEPRI 0x00, then everything runs fine again. Setting BASEPRI to any valid value causes the interrupt to stop triggering again!!!
So, looks like a Freescale issue. I’d assume the ARM core is fine since it’s been around much longer. Is there anything I’m missing?