Hi
I did more precise test.
125 uSec interrupt that posts semaphore to task, whcih in turn posts another semaphore.
CPU time stamp counter is sampled in 2 places. Each time after semaphoreTake.
There is a jitter in delay related to system tick (1 msec), with each hop (semGive/semTake, latency/reaction time grows).
Any thought?
are you not using port_yield_from_isr at the end of your isr?
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(schdulerSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);//request a context switch
You can clearly see that 7 times low jitter, but when it close to system tick (1 mSec) we have a problem.
Again, as requested in answer #18, can we see your code?
Also, you might want tu run your system under control of tracealyzer.
How do you count questions? Which one is 18?
How can I help you with tracealyzer?
extern "C" void TimerTick(void) // cleaned from comments
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(schdulerSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);//request a context switch
}//TimerTick
extern "C" void task(void) // cleaned from comments s
{
while(1)
{
if(OSAL_SemaphorePend(schdulerSemaphore, OSAL_MAX_DELAY) == OSAL_PASS )
{
endCounter = CycleCounterP_getCount32();
SystemServices::StartTicks = endCounter;
clShd->Signal(); // **signal lower priority task that will put SystemServices::StartTicks to the buffer**
}//semaphore ok
}
}
you will find the numbers of the answers on the right when you scroll down the topic. Its’s not done very well in the UI, I agree.
Tracealyzer can assist you in following the timing by threads/isrs, ie on the OS side of things.
You are using third party extension (OSAL_xxx). Do you see the same issue with native API calls, or are you positive that those wrappers do not add any code that may affect the timing? Also, is your TimerTick() function the one that the entry in the ivt points to, or are there some kind of eco system enforced wrappers in between that may affect your timing?
OSAL_BaseType_t OSAL_SemaphorePend(OSAL_SemaphoreHandleType sem, OSAL_BaseType_t to_ticks)
{
return ((OSAL_BaseType_t)xSemaphoreTake(sem, (TickType_t)to_ticks));
}
I’m bit surprized about complexity/length of TickHandler , especially taking into account that configUSE_TIME_SLICING is set to “0”.
Where does your timer tick handler come into play in that call stack?
As I suspected, your eco system may add additional wrappers around several call chain including isrs which may affect the timing. You may wish to repeat your experiment with barebone FreeRTOS and contact TI if they are responsible for the jitters you see.
this is full timer tick stack trace. A lot of enable/disable interrupts, memory barriers, Interrupt controller clean ups, but nothing that can explain grows in latency of the next semgive/take hop.
but your isr function is called TimerTick. It is obviouly not your system timer. Do you have a stack trace inclunding your Timer tick?
My timer ISR
That does not make sense at all. In the code you provide, your TimerTick() function does not call into Hwip_irq_handler(), so your code is not complete, or there are some kinds of wrappers in your eco system. Those will very likely be responsible for whatever timing phenomena you see. Try to remove all eco system dependencies and repro the issue with barebone FreeRTOS. If you can not repro it, contact IT. If yes, post your complete code here.
I think that it is debugger glitch.
Ignore bottom line, start looking up from HwiP_irq_handler.
But then your TimerTick function does not come into play at all. What exctly are we discussing then here? Again, try barebone FreeRTOS to eliminate all causes related to your eco system.
TI port provides minumim wrapper for interrupts. Nothing to throw away.
I’m less concerned about my Timer interrupt. Because it works 7 times as expected, by once in a system tick (each 1 mSec) there a disturbance. System tick ISR and things that happens in incrementTick take too long. Maybe TI’s port does not call right function for System Tick notification?
Do you have some time for teams?
well yes. It obviously is an issue on TIs side, possibly some periodic background processing claiming the critical section, or something like that. Have you tried contacting TI support? For once more, I strongly recommend rebuilding the app for barebone FreeRTOS and comparing the results.
Tracealyzer is a valuable tool for tracking these kinds of issues.
Apologies, I do not currently have capacities for P2P support.
@stx-sas Are you able to solve your problem? Did you hear anything from TI? Did you try running Tracelyzer as suggested by @RAc ?
Problem is in DDR/cache, under investigation of TI.
Thank you for reporting back!
@stx-sas, please post back if they get back with you with a solution.