CC3200 Deep Sleep and LPDS

Hi Vojisalv,

Regarding your 3 queries,

1. Have you also taken a look at the cc3200-sdk\example\deepsleep_nw example? This uses the DeepSleep with an OS (FreeRTOS). Please share some more information on your code.

2. The middleware takes care of transitioning in and out of the low power modes (sleep, LPDS, HIB) by abstracting out the low level details. The middleware is only providing some services (API) to configure the wake sources and enter-exit low power modes.

The CPU as well as peripheral context is lost on entry into LPDS. The peripheral context restoration is also taken care by the middleware for some of the peripherals (UART, SPI) as an example.

Yes, you can use the API of PRCM directly. But this will mean that after the LPDS exit code execution will restart from the reset vector (main).

3. Yes the API you identified is right (in the example). The entry-exit LPDS is controlled by the application and is more driven by the usecase. The middleware only gives necessary hooks to be controlled by the application.

Best regards,

Naveen

Naveen,

thank you very much for fast answer. It helped allot. I need to look more deep into this topic. 

Also thank you for referring me to the example "deepsleep_nw".

Best regards,

Vojislav Milivojevic.

Hi naveen,

I am working on TI-RTOS and we are using CC3200 as our target device. we want to do power management when its in idle condition or no process is going on. so middleware can help us to storing and restoring the states in sleep and deep sleep modes.

In our case we are also using the I2C operations in TI-RTOS, but middleware doesn't have support for I2C drivers, so do we need to write it from the scratch or its not needed. if that is required what are the things we need to follow. please guide me to do the same.

Regards,

-Hardik 

Hi Hardik,

Thats right! We dont have support for I2C drivers in the middleware yet (that would save and restore the I2C configurations).

You would need to reconfigure the I2C everytime you wake from LPDS (I am assuming that you will be using LPDS). You could use the cc3200-sdk\example\common\i2c_if.c file and invoke the I2C_IF_Open function on wake up from LPDS. An appropriate point to do this will be in the "lp3p0_restore_soc_data" function in cc3200-sdk\example\idle_profile\lp3p0_plat_ops.c.

Do let me know if you need any more clarification.

Best regards,

Naveen

Hi Naveen and Hardik,

just to confirm, I use I2C in low power deep sleep(LPDS) mode on that way and everything works fine.

Best regards,

Srki

I am trying to get the power management to work with the TI-RTOS and am not having much luck.  I am calling PRCMDeepSleepEnter() when I want to go to sleep but this does not seem to have any effect.  I was reading the Technical Reference Manual in section 5 it said we have to call PRCMCC3200MCUInit(); when booting from Power-Off the routine is expected to be called but this locks the MCU up when I execute it.  I see in the deepsleep_nw example MAP_PRCMDeepSleepEnter(); is called, how does that differ from the PRCMDeepSleepEnter(); call?  Where is the MAP_PRCMDeepSleepEnter(); included?  Does the PRCMCC3200MCUInit() need to be called.

Any help would be greatly appreciated

al

I put the call for PRCMDeepSleepEnter(); before the BIOS_start() call with some delays and I can see the power drop.  Why would the TI-RTOS hold off the entry to Deep Sleep?

al

al,

If you call PRCMDeepSleepEnter() before BIOS_start(), the CPU should get ‘stuck’ there because no interrupts are enabled yet (that happens as part of BIOS_start()).

If you call PRCMDeepSleepEnter() after BIOS_start(), then any enabled interrupt will immediately wake the CPU and cause it to exit PRCMDeepSleepEnter().  This could be an application-configured interrupt, or a timer interrupt, either from a Timer that has been created, or from a Clock module tick, or from a timer used for timestamping.  In your test, do you have an application interrupt that may be firing, or are you using Clock, Timer, or Timestamp?

Scott

Hi Scott,

Thanks for responding, the call to PRCMCC3200MCUInit() seems to lock the device up.  The only interrupt that is enabled is for GPIO and those are not being activated because they would require a button push - and I want to leave sleep mode when they are pushed.  I am using task_sleep() calls in one of my tasks, should I disable that task before entering sleep mode?  When I single step through the software with the PRCMDeepSleepEnter() call before BIOS_start() I get the following message from the debugger:

Cortex_M4_0: Can't Run Target CPU
Cortex_M4_0: Error
Cortex_M4_0: Unable to determine target status after 20 attempts

When  I single step through the idle thread and make the PRCMDeepSleepEnter() call nothing happens??

thank you

al

al,

Sorry for the delay, it has been a crazy day.

Where is PRCMCC3200MCUInit() called?  Can you tell where within that call the device locks up?  I think that needs to be resolved first, before the seeming non-transition into deep sleep.

For a Task_sleep() call to work, the Clock module needs to be ticking, because it is the Clock ticks that will be used to wait for the specified sleep interval.  So if Task_sleep() is working before you add power management calls, I expect that the Clock is indeed ticking, probably at a default rate of 1ms ticks, and those interrupts will cause a wakeup from deep sleep.  One way that you can quickly hack your test to disable the Clock ticks (for the purpose of seeing if that is what is prohibiting deep sleep)… you can open your application configuration file (with a .cfg extension) with a text editor, and add this at the very end:

Clock.tickSource = Clock.TickSource_NULL;

Then save the file and rebuild the test.  And see if the device still doesn’t go to deep sleep.

Finally, about the debugger messages when you enter deep sleep...  I haven’t tried this myself, but a coworker was doing some testing and saw this too – a transition into deep sleep causes the debugger to lose the debug session.  I think you can do a “free run” to cause the debugger to detach before deep sleep is invoked.  In CCS, select “Run->Free Run” after loading the program.  When the device is awake again, you can reconnect the debugger.

Hope this helps.  Please reply back how it goes…

Thanks,
Scott

Hi Scott,

I hear you about the crazy day!!

PRCMCC3200MCUInit() is being called in my first instruction.  Not sure why, but when I single step into PRCMCC3200MCUInit() it goes to the last instruction of the routine?

   HWREG(0x4402F0B0) = ((HWREG(0x4402F0B0) & ~(0x00FC0000))|(0x29 << 18));

I tried to change the clock tick source but got a "Clock" is not defined error message.

Since we know the debugger looses contact with the board when the micro goes to sleep, shouldn't that happen when I single step through code in the idle thread??

Does Deep Sleep have a way to find out what caused it to wake up?  I see WakeupCauseGet routines for LPDS and hibernate, but not for sleep and deep sleep?

thank you

al

al,

I tried stepping thru PRCMCC3200MCUInit() and the assembly code steps as expected, and that step for DCDC trim is the last in the function, so that executes and then the function returns.  But watching this in the C code display, it appears the CPU is hopping all around - I think this is because of code optimizations when the library was built, which confuse the C decoder.  Are you seeing the function finish OK, it is just the stepping within the debugger is odd?  I’d thought the device was “locking up”?

For changing the tick source, sorry you’ll need to add this above that line I sent:

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

I had expected your file to already have this.

I’m not sure of the exact behavior on this device, but generally when you single step, while you are sitting at a breakpoint and an interrupt fires (like from a timer interrupting every millisecond), the CPU won’t service it until you step the CPU again.  And sometimes power saving modes may not work exactly the same because of emulation activity.  So I’m not too surprised that you are seeing different behavior single stepping versus if you were to run free.

I don’t think there is any way to detect which interrupt wakes the CPU from simple deep sleep.  For the cases of LPDS or hibernate, where context is lost, the CPU goes back thru reset upon wakeup, and the reason for release from reset can be detected there.

Regards,
Scott