vPortSuppressTicksAndSleep semantics

tzc0der wrote on Tuesday, June 18, 2013:

FreeRTOS 7.4.2, Atmel SAM3U (ARM Cortex-M3), Atmel Studio 6.1
HI there, I am working on modifying the SAM4L low-power tickless idle implementation (from the demo) for the SAM3U and I’m finding the comments around the interrupt disable confusing in the demo version of 



	// Enter a critical section but don't use the taskENTER_CRITICAL() method as
	// that will mask interrupts that should exit sleep mode. 
	__asm volatile( "cpsid i		\n\t"
					"dsb			\n\t" );

Essentially the same thing shows up in the standard CM3 port code.

If I understand the assembly correctly, this is disabling ALL interrupts (except NMI & faults) so the timer used to wake the processor doesn’t get it’s interrupt handled until "

cpsie i

" is called later. HOWEVER, the comments indicate that the quoted code will somehow mask off fewer interrupts than


. I looked at the code involved there, and it just changes the BASEPRI register to some intermediate value, which, if I understand correctly, will mask off interrupts with lower priority (higher numeric value on a CM3) than BASEPRI, but not all interrupts (unless it is set to zero).

Am I missing something or are these comments not applicable and misleading?


tzc0der wrote on Tuesday, June 18, 2013:

Oops, sorry about the misuse of the code tags. Didn’t realize they would format that way.

rtel wrote on Wednesday, June 19, 2013:

When in a low power mode the Cortex-M3 *will* allow an interrupt to bring the MCU out of sleep mode even when interrupts are globally disabled using the i bit in the CPSR (set by the CPSIE i instruction).  The interrupt will not actually be processed by the MCU until interrupts are again re-enabled.

However….only interrupts that are not masked by the BASEPRI setting will do this.  Therefore, if you use taskENTER_CRITICAL() interrupts will remain enabled, but the interrupt you want to bring the system out of sleep mode will be masked, and therefore the MCU will not exit sleep mode even though the interrupt fired.


tzc0der wrote on Thursday, June 20, 2013:

Thank you Richard! That clarifies things immensely.