在查看论坛中的帖子时，我在 MSP 低功耗微控制器论坛中找到了以下相关帖子：
发现的问题似乎是相同的：TicksToService 的值是一个不可能的大数，接近 2^32，并且代码卡在内核模块 Clock.c 的函数 Clock_workFuncDynamic 的同一个循环中。
while (ticksToService >= distance) {
serviceTick = serviceTick + distance;
ticksToService -= distance;
distance = Clock_walkQueueDynamic(TRUE, serviceTick);
}
在我遇到的该情况中，在使用精密计时器实时测量的前 3m 37s 中系统会工作正常。然后系统开始连续触发 SWI 函数。系统应以 2ms 的间隔触发该函数。tickPeriod 的值为 100 (us)。因此，为了每 2ms 执行一次 SWI，我要使用 20 作为 clockParams.period 的值。在计时器模块的 Timer_setNextTick 函数中，所使用的每周期计数次数为 1919。
3m 37s 或 217 秒约等于计时器的 4164230000 次计数。这接近于 2^32。如果我在 SWI 开始连续触发之前计算其执行次数，得到的值为 111889。因此，111889 次执行每次都会执行 20 个周期，每个周期会产生 1919 次计时器计数，从而一共产生 4294299820 次计数。现在计数值更接近于 2^32。对于该计数，还应额外添加 2 毫秒，以将第一次超时计入其中。最后，我确信溢出会导致问题出现。
上述观察到的行为是可重复的。通过以下代码获取 ticksToService 的值：
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;
我认为，在运行的前 217 秒（大约）内，nowTick 大于 serviceTick，产生的值为正并且接近于零。不过，当计时器溢出时，nowTick 接近于零，而 serviceTick 接近于 2^32，因此两者相减所得结果数字接近于 2^32。
按照 Alan de Mars 在参考帖子中的建议，我将 tickMode 从 TickMode_DYNAMIC（默认值）更改为 TickMode_PERIODIC，然后问题消失了。一切都按预期运行。
我希望通过该主题可以帮助大家尽量避免此问题。
