This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: portYIELD_WITHIN_API behavior

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN,

Tool/software:

This is a continuation of the previous thread that has been locked.

I've found that the HALCoGen generated port macro portYIELD_WITHIN_API does not properly yield. My interpretation of the TRM is that writing the proper key to the SSIR register will trigger the corresponding software interrupt (default mapped to vPortYeildWithinAPI) immediately. However, in practice, I find that writing the register only causes the interrupt to be taken after an unspecified number of clock cycles.

In the attached sample project, I've inserted two assembly breakpoints: one at the end of portYIELD_WITHIN_API, and one at the beginning of vPortYeildWithinAPI. If the interrupt is taken, then the breakpoint in vPortYeildWithinAPI will trigger. If not, the one in portYIELD_WITHIN_API will trigger.

main simply enables interrupts and then makes a call to portYIELD_WITHIN_API;

As is, the breakpoint at the end of portYIELD_WITHIN_API is (incorrectly) triggering. 

I can "fix" the problem by adding some contrived delay in the portYIELD_WITHIN_API- either by inserting NOPs, additional ISB/DSB, or a read of a register. That is, this causes the BKPT in the interrupt to be hit (correct):

#define portYIELD_WITHIN_API() { portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; asm( " DSB " ); asm( " ISB " );  asm( " ISB " );  asm( " ISB " ); asm("BKPT"); }

As does this:

#define portYIELD_WITHIN_API() { portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; volatile uint32_t dummy = *(0xFFF7BC00U); asm( " DSB " ); asm( " ISB " );  asm("BKPT"); }
So it seems there is some latency associated with triggering the software interrupt with the register and the interrupt actually being taken. Are there any guarantees about what this latency is? Is there a suggested method for guaranteeing that the interrupt gets taken?
This leads to all kinds of strange issues when running FreeRTOS, particularly with waiting on events
Thanks!