Other Parts Discussed in Thread: CC1352R
器件型号： CC1352R
您好：
在 CC1352 (SimpleLink SDK 8.30) 上使用 FreeRTOS 无节拍空闲时、我在处理长睡眠/长计时器时遇到了问题。
环境中
-
设备：CC1352R
-
SDK：simplelink_cc13xx_cc26xx_sdk_8_30_01_01
-
RTOS：FreeRTOS
-
电源策略：PowerCC26XX_standbyPolicy
-
configUSE_Tickless_idle = 1
观察到的行为
-
大约~30 分钟或更短的计时器会正确过期。
-
大约~40 分钟或更长时间的计时器看起来永不过期。
-
系统进入待机状态并保持的时间比预期长得多。
实际上、计时器会在几小时后到期、而不是在请求的超时之后到期。
根本原因分析
在 FreeRTOS 待机策略中、通过比较两个时域来选择下一个唤醒源：
-
ClockP 时间：节拍* ClockP_tickPeriod
-
FreeRTOS 空闲时间：ticksOS * freertos_TICKPERIOD_US
在 SDK 实现中、两次转换都是使用 32 位算术完成的。
当 ClockP 没有挂起的事件时,ClockP_getTicksUntilInterrupt () 返回一个非常大的值（≈3.2e9 ticks）。
将其乘以 ClockP_tickPeriod (10us) 会溢出 32 位算术并将该值截断至大约 38–39 分钟。
因此：
-
比较不正确地选择了 ClockP 路径。
-
但是、编程的超时使用原始 ClockP 节拍计数（~3.2e9 个周期）、对应于大约 9 小时。
-
这就给人留下了这样一种印象：长时间计时器不会过期、而实际上它们的到期时间比预期的要晚得多。
我是如何解决的
我对 PowerCC26X2_freertos.c 应用了最小补丁：
-
将 uint64_t 用于时间、时间 OS 和东部
-
执行 64 位中的所有时间转换
-
仅在对 ClockP_setTimeout () 进行编程时转换回 uint32_t
-
在减去待机唤醒延迟时、应添加保护措施以避免下溢
更改后、40 分钟、1 小时及更长的计时器会正确过期。
问题
-
使用 FreeRTOS 和待机功耗策略时、这是否是 SDK 中的已知问题？ 还是我做错了？
-
TI 是否有官方修复方法或推荐修复方法？
-
TI 是否计划在未来的 SDK 版本中解决这些问题、或者本地补丁是否是预期的方法？
感谢你的帮助。
