Minimizing TM4C1292NCPDT current draw in USB suspend

Hello Jesse,

If I have read the USB Spec correctly, the current draw for Suspend Mode is 500uA. If that is correct, then you must have seen that the minimum current for Deep Sleep is with internal 30K oscialltor for which the USB function will not work. If on the other hand the USB function has to be used in Deep Sleep/Sleep, then the PLL must be used which will imply a larger current draw.

Can you share the code you have for enabling optimizations, so that we can trim it for better current savings in Low Power Mode

Regards

Amit

If I have read the USB Spec correctly, the current draw for Suspend Mode is 500uA.

then the PLL must be used which will imply a larger current draw.

Hello Tsuneo,

Thanks for refreshing my memory on the ECN to the current draw spec.

I don't think that the clock gating applies to the Suspend mode as it is considered an active peripheral from TM4C perspective. Yes the USBDR registers can be used to detect an asynchronous signal, but it should be followed up with quick clock start up to get the USB timings correct. This is only possible if the PLL is on and just the clocks are gated.

Regards

Amit

Amit, thanks on the explanation of USBDR registers.
After all, this register relates to the "system" clock side of the USB SIE.

In the manual, I found this description on the USB section,

25.3 Functional Description
Note: When the USB module is in operation, MOSC must be the clock source, either with or
without using the PLL, and the system clock must be at least 30 MHz.

But as long as looking in "Figure 5-5. Main Clock Tree", there isn’t any way to bypass PLL for the USB SIE. Maybe, the USB SIE could work in slower clock in Suspend, but the clock system designer didn’t count it in.

My conclusion on this issue is,
There is no way to stop the PLL/MOSC in USB suspend period,
except for an external ULPI PHY, which feeds USB0CLK.

Tsuneo

Hello Tsuneo,

The issue with lower frequency clock is the mess it creates for counters that must match the USB recommendations. The bypass of the clock for the USB cannot be done.

Regards

Amit

Amit Ashara said:

The issue with lower frequency clock is the mess it creates for counters that must match the USB recommendations.

Hah?
In Suspend condition, there is no signaling on the bus, including SOF. The bus is kept in idle (D+: pull-up, D-: pull-down, for full-speed). Why is the full-rate clock required, where there is no signal to decode on the bus?
The Resume signaling flips the polarity of D+/D- for 20ms, at least. It’s enough period to reset the internal counters on the SIE.

Disabling PLL in Suspend is common design practice among USB MCUs.

Here is Suspend description of MSP430x5xx/x6xx User’s Guide
http://www.ti.com/lit/ug/slau208n/slau208n.pdf

40.2.7.1 Entering Suspend
For most applications, the integrated 3.3-V LDO is being used. In this case, the following actions should be taken:
• Disable the PLL by clearing UPLLEN (UPLLEN = 0)
• Limit all current sourced from VBUS that causes the total current sourced from VBUS equal to 500 uA minus the suspend current, ISUSPEND (see the device-specific data sheet).

Disabling the PLL eliminates the largest on-chip draw of power from VBUS. During suspend, the USBCLK is automatically sourced by the VLO (VLOCLK), allowing the USB module to detect resume when it occurs.

I can refer to many reference manuals of other companies, but this is TI’s board ;-)

Most of USB SIEs follow this practice, just Tiva-C USB SIE can’t stop PLL.

Tsuneo

Hello Tsuneo,

I think we have come full circle. You can gate the PLL under auto control mode only in Deep Sleep, with the USBDR register set to detect the wakeup signalling and then restarting the clock. However in this mode the counters will start working of the slower clock before switching to the high frequency clock. This will cause the counters to extend longer than 20ms in absolute time. Now to get to the lower current numbers, the configuration sequence must be

1. Configure the DCGCUSB and any other peripheral required in deep sleep to 1

2. Configure the DSCLKCFG for LFIOSC in deep sleep as clock source, DSLPPWRCFG and LDODPCTL for Flash-SRAM low power and LDO voltage to be lowered. Enable Auto CLock Gating in RSCLKCFG

3. Configure SUspend for USB. Once USB is suspended, CPU asserts Standby by calling SysCtlDeepSleep and then waits for a USB wakeup signalling.

4. On USB Interrupt due to wakeup signalling the clocks and power is restored.

Regards

Amit

Ah, Auto CLock Gating.
Thanks Amit for your effort.

Now that this errata makes sense for me.
I had wondered how we could put the core in Deep Sleep, while the PLL couldn’t be sopped.

Tiva C Series TM4C129x Microcontrollers Sillicon Revisions 1,2, and 3 - Silicon Errata
http://www.ti.com/lit/er/spmz850c/spmz850c.pdf

USB#05 USB Resume Occasionally does not Wake Device from Deep Sleep

Amit,
Please pass document update request,
so that the procedure on your post should be written in "18.3.1.6 Device Mode SUSPEND" section on the data sheet (or 21.3.1.6 on full data sheet). Also for TM4C123x, too.
No one could imagine such procedure just reading current description ;-)

Tsuneo

Hello Tsuneo

We plan to do a application note for low power mode in TM4C12x devices and the USB chapter there would make a good addition

Regards

Amit

Hi All,

I am attempting to implement the SUSPEND/RESUME scheme described above by Amit (for the TM4C1294).

For ease of debugging, I am not using bus power, but intend to in the final design.

I have this problem: Shortly after USB driver initialization (usb wire not connected) I receive a USB_SUSPEND event When I plug the USB wire into my computer, I get 1 more SUSPEND, then a CONNECT event.

I never see a DISCONNECT or RESUME events. (Removing the cable also results in SUSPEND).

I have modeled my program after usb-dev-bulk example. Any ideas were to look?

Thank you - Isaac

Hello Issac,

I think that is what is expected from the USB device to be able to suspend if it is not able to detect a enumeration.

Regards

Amit

Okay, so I supposed to go into low power mode while the device enumerates?? Remember, I plug the cable in and first i get a SUSPEND interrupt, and a few milliseconds later I get the CONNECTED interrupt (because of successful enumeration).

Assuming this is the way it should work, please verify my steps for setting up deep sleep during suspend:

1. Initial Configuration:

//-------------------------------------------------------------------
// Set up deep sleep mode for USB in suspend
//-------------------------------------------------------------------
MAP_SysCtlPeripheralDeepSleepEnable(SYSCTL_PERIPH_USB0); //USB needs to be running
MAP_SysCtlDeepSleepClockConfigSet(0, SYSCTL_DSLP_OSC_INT30 | SYSCTL_DSLP_PIOSC_PD | SYSCTL_DSLP_MOSC_PD);
SysCtlDeepSleepPowerSet(SYSCTL_FLASH_LOW_POWER | SYSCTL_SRAM_LOW_POWER);
SysCtlLDODeepSleepSet(SYSCTL_LDO_0_90V);
MAP_SysCtlPeripheralClockGating(true);

2. When I receive the SUSPEND event I set a flag to tell my system to go into low-power mode. Outside of interrupt context I then call: SysCtlDeepSleep().

Is this it? To USB will send an interrupt to bring me out of suspend - the CONNECTED event, and then my program will continue running.

Hello Issac

Yes, it is correct. But as far as I know, the USBDRIM will only detect a RESUME. So a connect operation may not be detected. In the application you may have to wait for a CONNECT only after which a SUSPEND operation will allow deep sleep entry.

Regards

Amit

Thank you Amit,

I've put all of this into place and it almost works. When I "disable" the device in the Windows device manager or put my computer to sleep, the Tiva goes into deep sleep (current draw drops to about 6 mA), but it only seems to remain there for about 3 seconds.

I tried using the debugger to see what happens and it goes into the "loader_exit" routine at this time. I think that without the debugger connected the CPU is reset.

Isaac

Hello Issac,

What are the source of wakeup enabled in the device?

Regards

Amit

It Turns out Timer 0, Timer 1, and Hibernate were configured to wake it from deep sleep. Maybe RTOS configured the timers this way??

I disabled the two timers before going to sleep and now it successfully sleeps, but never wakes up. 

Hello Issac,

There must be atleast one source of wakeup for the device. Did you try putting the device out of suspend (USB wakeup)?

Regards

Amit

Yes, I left USB enabled during Deep Sleep and attempted to send it a RESUME event.

From my earlier testing (when I didn't actually go to sleep on SUSPEND), I never receive RESUME interrupts from the USB driver. I suspect that this is what is happening.

I just set up a test to see what interrupts occur when the device is not put into deep sleep, and I am getting the correct sequence of events.

I log the USB Rx Interrupts in internal memory and then report them back later. I see these three events; 1. Connect, 2. Suspend, 3. Resume. So RESUME is not causing the device to wake up.

Hello Issac,

Please check if the USBDRIM is set or not? Since in deep sleep you are dropping the system clock it is required for the USB wakeup to be detected asynchronously.

Regards

Amit

USBDRIM was NOT SET just before I entered Deep Sleep. I added this line of code: HWREG(USB0_BASE + USB_O_DRIM) = 0x00000001; before entering Deep Sleep and now the device does not enter deep sleep when I put the computer in suspend mode, but the device does go to deep sleep (and remain there) when the computer wakes up.

Hello Issac,

The steps must be done after the Suspend interrupt has been received from the Host. In the form of a psuedo code it would ne

if(bSuspend)

{

Clear USBDRISC

Set USBDRIM

SysCtlDeepSleep()

}

Regards

Amit

Okay, thanks Amit.

Currently I have a task waiting an an event. In the USB SUSPEND interrupt I trigger the event, then leave the interrupt handler.

The task will then run the above psuedo-code next time it gets a time-slice to put the device to sleep.

Hello Issac,

Yes that is correct. The USBDRISC and USBDRIM must be the last set of USB operations before the SysCtlDeepSleep is called.

Analogous to is an high level interrupt being set with the pad already high when setting up the pad will cause the pad to go low.

Regards

Amit

Great! Thanks Amit. It seems to be working correctly, judging by the current consumption. Unfortunately after resume I am unable to communicate with my device. I am using libusbk on Windows. I don't get any errors on Connect or WritePipe, but I get one on ReadPipe.

I'm trying to device a way to debug this and figure out what state my CPU is in.

Hello Issac,

If it is possible then try using the Sleep Mode, so that the PLL is not unlocked. This may help to see if the issue is in deep sleep with clock mode switching.,

Regards

Amit

The problem persisted when I replaced DeepSleep with Sleep.

Next I removed the Clear USBDRISC and Set USBDRIM operations, and the sleep mode worked correctly.

Do I need to manipulate these registers again after I come out of deep sleep?

Hello Issac,

Yes, you would need to disable USBDRIM and clear USBDRISC after deep sleep state. This is meant only for detecting events and not to be used as a function interrupts

Regards

Amit

Thank you, Amit. I think that was the problem - it seems to work well now. I will test and let you know if I have any other difficulties. ~Isaac

Hello Issac,

That's good news and hope that was the last of the issues....

Regards

Amit

Hi Amit,

This post may be resolved but as i am not getting any response on a post that i recently created, regarding deep sleep issues with USB and PWM, i am posting my queries on this thread in a hope to get any answer .

I am using deep sleep and it is working fine with GPIO interrupt. But i am unable to get it to work with USB. Detailed below are the configurations that i am doing in my TI RTOS based project(TM4C129XNCZAD)

1- Run time clock, with PLL and 25 MHz MOSC, is 60 MHz.
2- Deep sleep clock source is MOSC.
3- USB is enabled in deep sleep and clock gating is also enabled.
4- A HAL timer module is configured for 10 seconds interrupt to wake the MCU from deep sleep.
5- GPIO port to be used with button is also enabled in deep sleep.

I have configured my application to only go into deep sleep when USB suspend event has been received. The problem is when i put my instrument to deep sleep(for 10 seconds), it either wakes up on button push or timer interrupt. Connecting the USB cable to PC does not causes it to wake up from deep sleep. Please let me know what am i missing which is causing the USB to not wake the MCU from deep sleep.

Thanks,
Muhammad Shuaib