Other Parts Discussed in Thread: HALCOGEN
I am using the TMS570LC4357 with FreeRTOS, and am finding some interesting behavior when attempting to take a system software interrupt using the SSIR1 register. I've found that program execution may continue several instructions after the writing of the SSIR1 key. I am using the HALCoGen port macro portYIELD_WITHIN_API, which expands to:
#define portYIELD_WITHIN_API() { portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; asm( " DSB " ); asm( " ISB " ); }
#define portYIELD_WITHIN_API() { portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; asm( " DSB " ); asm( " ISB " ); }
I have found that the problem goes away (the interrupt is taken) if two additional DSB or ISB instructions are added, i.e.
#define portYIELD_WITHIN_API() { portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; asm( " DSB " ); asm( " ISB " ); asm("ISB"); asm("ISB"); }
Or even just some NOP instructions:
#define portYIELD_WITHIN_API() { \
portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; \
for (uint32_t i = 0; i < 4; ++i) { asm volatile("NOP"); } \
asm( " DSB " ); \
asm( " ISB " ); \
}
So it seems that this is a subtle timing related thing. Are there any kind of latency requirements related to the setting of this register to trigger a system software interrupt? This happens even with the
vPortYeildWithinAPI interrupt at very high priority (mapped to channel 3 in the VIM, just behind vPortPreemptiveTick), and is not being called from ISR context.
This is especially important when using FreeRTOS event groups, because when waiting on an event FreeRTOS places an item on the event list, makes a call to portYIELD_WITHIN_API, and then retrieves an item from the event list. If the task yields properly, the item retrieved from the list is the correctly waited on item with its proper control bits set. If portYIELD_WITHIN_API does not take the interrupt immediately and continues with program execution as described, the item fetched from the list is the item that was just placed onto the list, meaning that a call to wait on an event group does not wait at all
