Part Number:AM5718
在查看论坛中的帖子时,我在 MSP 低功耗微控制器论坛中找到了以下相关帖子:
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
发现的问题似乎是相同的: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,然后问题消失了。一切都按预期运行。
我希望通过该主题可以帮助大家尽量避免此问题。
Annie Liu:
我们建议您在发布新问题之前先搜索 E2E支持论坛,E2E支持论坛已经拥有数十万个已得到解答的话题。 这通常是解决问题的最快方法。