Part Number: MSP432P4111
We've been trying to track down an issue that occasionally occurs in our system.
Following it down in Clock.c within Simplelink 3.40.1.2, we notice that the issue occurs when the ticksToService in Clock_workFuncDynamic returns the maximum (in our case 0x1999) ticks.
Having put out a test point and rebuilt the RTOS we can see there there are no gaps in allowing the Clock_workFuncDynamic to fire within this ~2 second period.
For catching the instance, I have added a check to ensure the tickstoService is longer than 100 ticks (in our system we have a period task which occurs more frequent than this, so this is our high watermark.
On the expressions tab you can see the large difference between now_arr_u32[8] and now_arr_u32[9].
Signal Yellow below is Pin 42, and Green is 41, you can see, we had the last Clock_workFuncDynamic occur ~3.2ms ago, not 2 seconds as the gap between now indicates.
Strangely... this difference in time seems far too close to a roll over, so thats where I started looking next.
There are two bits of code that I can see that increment the rollover counter, which is used to getCount for timer ticks.
UInt32 Timer_getCurrentTick(Timer_Object *obj, Bool saveFlag)
{
currCount = Timer_getCount(obj);
rollovers = obj->rollovers;
if (currCount < obj->prevThreshold) {
rollovers += 1;
} ....
Where prevThershold is set by Timer_periodicStub (Timer A0 HWI), which also has a rollover check in it.
if (obj->prevThreshold >= timer->cc_compare_0) {
obj->rollovers += 1;
}
Monitoring both of these with test points, I see the rollover incrementing correctly every 2 seconds with the Timer_periodicStub, however... randomly, I also see Timer_getCurrentTick incrementing it also, this means you get 2 rollover increments for the same rollover event, would someone be able to explain why there are two that can both occur?
This however was not my problem; I continue to dig and found that on occasion; Timer_getCurrentTick would get a situation, where the Timer_getCount() returns a count, which is smaller than prevThreshold, but not at a zero rollover, but instead at random values in between (as shown in the screenshot below).
I believe this is the issue that I am trying to track down.
We have examined our code, and are not able to find anywhere where we could be modifying the CCR0 or TimerA0 timer.
I've checked to see that the TimerA0 HWI is not firing twice and pre-empting, but the below DSO capture.
Blue - Signal Set on Entry to TimerA0 HWI, and cleared on Exit
Green - Clock_workFuncDynamic Set on Entry
Yellow - Rollover from Timer_getCurrentTick
I am sadly out of ideas on how to further debug this and the reliability of the timers is critical to our system.
Summary:
1) Why is there two different rollover functions?
2) How could getCount() (for ticks) return a value less than prevThershold, if the real world timing is correct?
