Looking at the posts in the forum, I found the following related post in the MSP low-power microcontroller forum:
https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/843943/msp432p4111-sysbios-clock-function-swi-appears-to-be-blocking-all-tasks-from-running
The issue identified appears to be the same: the value of TicksToService is an impossible large number, close to 2^32 and the code gets stuck in the same loop, located in the function Clock_workFuncDynamic of the kernel module Clock.c;
while (ticksToService >= distance) {
serviceTick = serviceTick + distance;
ticksToService -= distance;
distance = Clock_walkQueueDynamic(TRUE, serviceTick);
}
In my case, the system works correctly for the first 3m37s of real time measured with a chronometer. Then it starts triggering the SWI function continuously. It should trigger it at 2ms intervals. The value of tickPeriod is 100 (us). So, to get a SWI execution each 2ms, I'm using 20 as the value of clockParams.period. The number of counts per tick is 1919 as used in the Timer_setNextTick function in the timer module.
3m37s or 217 seconds equates approximately to 4164230000 counts of the timer. Close to 2^32. If I count the number of executions of the SWI before it starts triggering continuously, I get 111889. So, 111889 executions made each 20 ticks of 1919 timer counts, yields 4294299820 counts. Now it is closer still to 2^32. To that count 2 extra milliseconds should be added, accounting for the first timeout. In the end, I am convinced that the overflow causes the problem to appear.
The observed behavior is repeatable. The value of ticksToService is obtained by the following code:
nowTick = Clock_TimerProxy_getCurrentTick(Clock_module->timer, TRUE);
...
/* determine first tick expiration to service (the anticipated next tick) */
serviceTick = Clock_module->nextScheduledTick;
ticksToService = nowTick - serviceTick;
I think that during the first 217 seconds of operation (approx) nowTick is larger than serviceTick and the resulting value is positive and close to zero. However, when the timer overflows, the subtraction results in a number close to 2^32, as nowTick is close to zero, while serviceTick is close to 2^32.
Following the suggestion from Alan De Mars in the referred post, I changed tickMode from TickMode_DYNAMIC (the default) to TickMode_PERIODIC and the problem disappeared. Everything works as expected.
I am starting this thread with the hope that anyone encountering this problem might avoid it faster than myself.
