liamstask wrote on Monday, July 16, 2007:
I have some code that makes use of FIQs to provide callbacks for a high-resolution timing system. This code works great when I build with -O0 optimization (both under Rowley CrossWorks GCC build, and GnuArm toolchain builds). However, once I notch the optimization up to O2 (or O1 even, but I’m hoping ultimately to use O2), the FIQ code goes a bit wonky.
It’s tricky to track down exactly where it goes awry since stepping through optimized code is a bit of a crap shoot, but I can confirm that the interrupt still works (at least a few times). We’ve modified the FreeRTOS code to disable interrupts from thumb to only disable fast interrupts, as follows:
void DisableFIQFromThumb( void )
{
asm volatile ( "STMDB SP!, {R0}" ); /* Push R0. */
asm volatile ( "MRS R0, CPSR" ); /* Get CPSR. */
asm volatile ( "ORR R0, R0, #0x40" ); /* Disable FIQ. */
asm volatile ( "MSR CPSR, R0" ); /* Write back modified value. */
asm volatile ( "LDMIA SP!, {R0}" ); /* Pop R0. */
asm volatile ( "BX R14" ); /* Return back to thumb. */
}
I wonder if anybody has any general information about how FreeRTOS behaves with regard to stack space, etc when a an interrupt handler is declared with the GCC "FIQ" attribute as follows:
void FastTimer_Isr( void ) __attribute__ ((interrupt("FIQ")));
Is this likely to cause any problems on the FreeRTOS side of things at a higher optimization level? Thanks for any hints!
Liam