• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 209 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: CC1352R and SDK 8.30 with FreeRTOS and Standby power policy. Wake up timers issue

Marc Martin
Prodigy 10 points

Part Number: CC1352R

Hello,

I am experiencing an issue with long sleep / long timer handling when using FreeRTOS tickless idle on CC1352 (SimpleLink SDK 8.30).

Context

  • Device: CC1352R

  • SDK: simplelink_cc13xx_cc26xx_sdk_8_30_01_01

  • RTOS: FreeRTOS

  • Power policy: PowerCC26XX_standbyPolicy

  • configUSE_TICKLESS_IDLE = 1

Observed behavior

  • Timers around ~30 minutes or less expire correctly.

  • Timers around ~40 minutes or longer appear to never expire.

  • The system enters standby and remains there much longer than expected.

In practice, the timer does expire, but only after several hours, not after the requested timeout.

Root cause analysis
In the FreeRTOS standby policy, the next wakeup source is selected by comparing two time domains:

  • ClockP time: ticks * ClockP_tickPeriod

  • FreeRTOS idle time: ticksOS * FREERTOS_TICKPERIOD_US

In the SDK implementation, both conversions are done using 32-bit arithmetic.

When ClockP has no pending events, ClockP_getTicksUntilInterrupt() returns a very large value (≈3.2e9 ticks).
Multiplying this by ClockP_tickPeriod (10 us) overflows 32-bit arithmetic and truncates the value to approximately 38–39 minutes.

As a result:

  • The comparison incorrectly selects the ClockP path.

  • However, the programmed timeout uses the original ClockP tick count (~3.2e9 ticks), which corresponds to roughly 9 hours.

  • This creates the impression that long timers do not expire, while in reality they expire much later than expected.

How I have solved it
I applied a minimal patch to PowerCC26X2_freertos.c:

  • Use uint64_t for time, timeOS and soonest

  • Perform all time conversions in 64-bit

  • Convert back to uint32_t only when programming ClockP_setTimeout()

  • Add a guard to avoid underflow when subtracting the standby wake delay

After this change, timers of 40 minutes, 1 hour and longer expire correctly.

Questions

  • Is this a known issue in the SDK when using FreeRTOS and standby power policy? Or I am doing something wrong?

  • Is there an official or recommended fix from TI?

  • Is this something TI plans to address in a future SDK release, or is a local patch the expected approach?

Thank you for your help.