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.
Tool/software: TI-RTOS
Hello,
I have issue with TI-RTOS on TM4C129 CPU.
I create simple task:
#define MS_TO_TICK(x) ((x) * 1000 / Clock_tickPeriod)
static void TestTask_Fxn(UArg arg0, UArg arg1) { while(1) { APP_INFO("%d\n", Clock_getTicks()); Task_sleep(MS_TO_TICK(1000)); } }
It works correctly with Clock module configuration:
BIOS.cpuFreq.lo = 120000000;
Clock.tickMode = Clock.TickMode_PERIODIC;
Clock.timerId = 0;
Clock.tickSource = Clock.TickSource_TIMER;
In debug UART I can see messages:
Default INF: main:cpuFreq.lo 120000000
Default INF: main:Clock_tickPeriod 100000
Default INF: TestTask_Fxn:0
Default INF: TestTask_Fxn:10
Default INF: TestTask_Fxn:20
Default INF: TestTask_Fxn:30
....
Default INF: TestTask_Fxn:1760
...
But if I change mode to Clock.tickMode = Clock.TickMode_DYNAMIC;
Task is stop execution after some time.
Debug output is:
Default INF: main:cpuFreq.lo 120000000
Default INF: main:Clock_tickPeriod 100000
Default INF: TestTask_Fxn:0
Default INF: TestTask_Fxn:10
...
Default INF: TestTask_Fxn:340
Default INF: TestTask_Fxn:350
Default INF: TestTask_Fxn:707
Default INF: TestTask_Fxn:707 is the last message that I see. In the ROV I see that task is blocked on Task_sleep(357 (stale data)) but in normal operation it shows Task_sleep(10 (stale data)).
I add Idle task with following code:
UARTprintf("s %d\n", Clock_getTicks());
Got debug output:
Default INF: main:cpuFreq.lo 120000000
Default INF: main:Clock_tickPeriod 100000
Default INF: TestTask_Fxn:0
s 0
s 0
...
s 9
s 9
Default INF: TestTask_Fxn:10
s 10
...
s 350
Default INF: TestTask_Fxn:350
Default INF: TestTask_Fxn:707
s 708
s 708
...
s 709
...
s 1064
s 707
After my task stop execution idle task continue prints Ticks value. It is strange that next value after 1064 is 707.
I want to use Clock.TickMode_DYNAMIC mode to improve power consumption, want go to sleep in Idle task.
Add sleep in Idle:
uint32_t start_ticks = Clock_getTicks(); UARTprintf("s %d\r\n", start_ticks); SysCtlSleep(); uint32_t stop_ticks = Clock_getTicks(); UARTprintf("%d %d\r\n", start_ticks, stop_ticks);
Output:
[2018-04-13 14:53:51.047] Default INF: main:cpuFreq.lo 120000000
[2018-04-13 14:53:57.920] Default INF: main:Clock_tickPeriod 100000
[2018-04-13 14:53:57.925] Default INF: TestTask_Fxn:0
[2018-04-13 14:53:57.927] s 0
[2018-04-13 14:53:57.928] 0 1
[2018-04-13 14:53:58.018] s 1
[2018-04-13 14:53:58.018] 1 10
[2018-04-13 14:53:58.918] Default INF: TestTask_Fxn:10
[2018-04-13 14:53:58.921] s 10
[2018-04-13 14:53:58.921] 10 20
[2018-04-13 14:53:59.918] Default INF: TestTask_Fxn:20
[2018-04-13 14:53:59.921] s 20
....
[2018-04-13 14:54:31.923] Default INF: TestTask_Fxn:340
[2018-04-13 14:54:31.926] s 340
[2018-04-13 14:54:31.927] 340 707
[2018-04-13 14:54:32.924] Default INF: TestTask_Fxn:350
[2018-04-13 14:54:32.927] Default INF: TestTask_Fxn:707
[2018-04-13 14:54:32.929] s 708
[2018-04-13 14:54:32.930] 708 707
[2018-04-13 14:55:08.625] s 707
[2018-04-13 14:55:08.626] 707 707
[2018-04-13 14:55:44.418] s 707
[2018-04-13 14:55:44.418] 707 707
[2018-04-13 14:56:20.211] s 707
[2018-04-13 14:56:20.211] 707 707
As you can see CPU sleeps in Idle task and wakeup periodically (time0 interrupt is wake up source I think)
But after some time (340 - 350 ticks) Clock modules stops counting.
What is wrong with TI-RTOS Clock module?
I use tirtos_tivac_2_16_00_08
Best regards,
Michael
Michael,
Unfortunately the Clock dynamic tickmode feature is not supported on TivaC devices.
Judah
Hello Judah,
Can you propose some workaround how can I implement similar behavior?
I think if I configure clock in mode Clock.tickSource = Clock.TickSource_USER and will call Clock_tick() by my self. I can suspend unnecessary interrupts.
How can I get information when the next time CPU should wake up?
How to know Task_sleep(some_ticke)?
Or migration to the MSP432 is the right way? I hope TI-RTOS for MSP432 supports advanced power management.
Best regards,
Michael