How to keep CC3200 kernel clock running during sleep ?

Hi Angelo,

Which version of TI-RTOS are you using? What are the compiler errors that you are seeing?

I checked with our experts on Power Management. You are correct. By default, the Clock module uses SYSTICK timer which will halt when deep sleep mode is entered. The best alternative would be to configure Clock module to use RTC that keeps running during deep sleep mode.

It can be configured in *.cfg by adding these two statements:

var Clock = xdc.useModule('ti.sysbios.knl.Clock');

Clock.TimerProxy =  xdc.useModule('ti.sysbios.family.arm.cc32xx.Timer');

This support should be available in TI-RTOS 2.12.01.33 and onwards.

But note, from docs:

Some of the RTC timer registers are accessed from the 32KHz clock domain, making reads/writes to these registers on the order of 100 microseconds. If using the RTC timer for the Clock module's tick source, the interrupt latency will be as high as 200 microseconds, as the Clock ISR makes two RTC register accesses on the 32KHz clock domain.

Hope this helps,

Vikram

Thanks Vikram, this sounds promising.
I was using 2.01, and the error I was getting was this:

can't locate the package 'ti.sysbios.family.arm.cc32xx' along the path: 'C:/TI/ccsv6/ccs_base;C:/TI/tirtos_simplelink_2_01_00_03/packages;C:/TI/tirtos_simplelink_2_01_00_03/products/bios_6_40_03_39/packages;C:/TI/tirtos_simplelink_2_01_00_03/products/uia_2_00_01_34/packages;c:/ti/xdctools_3_30_06_67_core/packages;..;'. Ensure that the package path is set correctly. .xdchelp /ti_rtos_config line 185 C/C++ Problem

I went to the App Center and updated TI-RTOS to 2.13, but I continue to get the same error. I tried switching to the new version, but apparently there is some setting somewhere I'm missing because the path continues to show tirtos_simplelink_2_01_00_03.

Angelo

Select your project and navigate Project > Properties > General > RTSC. Under the RTSC tab, select the correct TI-RTOS for SimpleLink Wireless MCUs.

Vikram

I had tried that, but the error didn't change.

The build files may still be pointing to the older version. Can you clean the project and then build? 

Vikram

Right, I should have thought of that. I also needed to restart CCS for some reason, but that did allow me to finally compile without errors.

However now the device doesn't stay in LP mode. It immediately wakes after calling the PRCMDeepSleepEnter() call. This is the same thing it did when I didn't have the SysTickDisable() and SysTickEnable() calls before and after entering sleep, except I do have them there now. To be sure I only changed the line for the Clock.TimerProxy back to 'ti.sysbios.family.arm.m3.Timer' and the device stays asleep.

Are there any other changes I need to make for this? The cfg file also has a Timer.TimerProxy which is still set to xdc.useModule('ti.sysbios.family.arm.m3.Timer'). Should that one be changed to '...arm.cc32xx...' also?

Hi AQ,

I am not an expert on Power Management. The only other configuration that I know is for Timestamp:

Timestamp = xdc.useModule('xdc.runtime.Timestamp');
Timestamp.SupportProxy = xdc.useModule('ti.sysbios.family.arm.cc32xx.TimestampProvider');

Have you checked the "sprui18.pdf" in TI-RTOS docs? It has documentation for "TI-RTOS Power Management for CC3200 SimpleLink Wireless MCUs and MSP432".

Meanwhile, let me check with Power Management experts about the issue you are encountering.

Vikram

Hi Vikram, I'm still trying to understand the PDF and make this work but not having any further success. I was wondering if you found out anything from the power management team.

Thanks,
Angelo

Hi Angelo,

I checked with our power management experts. I think you probably should change the Timer.TimerProxy to ti.sysbios.family.arm.cc32xx.Timer instead of M3 timer.

A few questions for you:

Can you also post your .cfg if possible? We can take a closer look to see what may be causing the issue.

Are there any other interrupts that may wake up the device? Can you tell us from where are you invoking PRCMDeepSleepEnter() in your code?

Also, how are you checking if the device is in sleep or not?

Thanks,
Vikram

Thanks Vikram,

When you say I should change Timer.TimerProxy, do you mean in addition to changing Clock.TimerProxy, or instead of that?

I attached the cfg file.  I don't believe there are any other interrupts enabled.  I have enabled a pin interrupt which is triggered by an external device (accelerometer) periodically.  I called something like this in one of my tasks:

while (1) {
		UART_PRINT("sleep\n");
		MAP_UtilsDelay(80000);

		SysTickDisable();
//		PRCMSleepEnter();
		PRCMDeepSleepEnter();
		SysTickEnable();

		UART_PRINT("wake\n");
		UART_PRINT("%ld\n", ti_sysbios_knl_Clock_getTicks()); 
}

When I use the original Clock.TimerProxy setting (M3), the device goes to sleep, then about a second later the external pin interrupt is generated and the device wakes up. The clock time is reported to the console, and it goes to sleep again. I can see from the time values reported that during sleep the clock is not running (only several milliseconds elapse).

When I change to the CC32xx TimerProxy setting, the same code continuously reports sleep...wake...sleep...wake...etc. without waiting for the pin interrupt.

I hope that answers all your questions. Let me know if you have any other questions about this.

Thanks,

Angelo

4276.CloudBurst.cfg

Thank you Vikram, this is helpful.

As it turns out the issue I had before where it kept waking up was because I had another task running with a Task_Sleep() call and that was apparently setting an interrupt that woke it up. So with that task disabled the device stays asleep (even if I only have the clock.timerproxy set to the cc32x, and not all three (clock.timerproxy, timestamp.supportproxy, and timer.timerproxy).

But I noticed a problem ... after it wakes up again I found that if I call a function that includes this line it hangs:
time_t t_of_day = time(NULL);

The declaration for time() is:
_CODE_ACCESS time_t time(time_t *_timer);

If I remove this, so far it works fine. Any ideas why this?

In the meantime I looked briefly through the UART power example you mentioned and I'll look into that further. I'm a little concerned about this significantly increasing the code size though.