RTOS/TM4C129XNCZAD: Deep sleep causing issues with PWM and USB

Hello Muhammad

For the USB to function the PLL must operate to provide 60MHz clock. In deep sleep mode PLL is disabled and hence the USB does not work as expected and the PC gives an error for malfunctioning USB device.

Hi Muhammad,
Can you please check if the system clock is active during deep sleep? It seems like the system clock is lost during deepsleep mode as there is no more LED. Can you experiment with SysCtlPeripheralClockGating(false) and will it make a difference? This will force the peripherals to be clocked the same as in run mode.

Hi Amit,
Thanks for the explanation.

Hi Amit,

Thanks for taking time to comment on this post.

If the USB is not going to work in deep sleep, then what is the purpose of SysCtlPeripheralDeepSleepEnable? Or is this function not intended to be used for USB?
Also, if this is the case as you have stated, will the USB cable be detected only when MCU is not in deep sleep?

Thanks

Hello Muhammad,

The Deep Sleep capability exists for every peripheral. However peripheral clock must be correct for the peripheral to work correctly. Cable detection may still work but with timings not meeting the result can be indeterminant.

Hi Charles,

Thanks for the update.

I will try this and share my results.

Muhammad Shuaib

Amit,

With 10 seconds deep sleep, the problem is not just the cable not being detected. Once the cable detection fails, when MCU was in deep sleep, and PC has displayed error message that "USB device has malfunctioned", it won't work again even after waking up from deep sleep. The only way to get the cable detection to work is to connect it only when MCU is not in deep sleep.
So, the way i am seeing USB device being preserved in deep sleep is that it will work after waking up from deep sleep and there will not be any extra configuration required to restore the USB to its working state. However, there is some time(haven't figured it out yet how much) required for the cable to be detected and during that time the MCU must not be put into deep sleep. The deep sleep must only be initiated when cable has been removed i.e USB suspend event has been received as last event.

Please share your expert opinion on if i am still missing any details before reaching any decision regarding if USB cable detection will work or not during deep.

Thanks,
Muhammad Shuaib

Hi Amit,

I was looking at another post related to the same problem and tried the solution mentioned in the post i.e. using DRISC and DRIM registers. I am still unable to wake the MCU from deep sleep on USB connection. Also, I viewed USB registers in IAR when i was not putting MCU to deep sleep and found out that the DRISC resister is showing "W" instead of a valid value. I am unable to modify this register. Do you have any idea about what can be the case here? The link to post i was referring to is given below.

Thanks,

Muhammad Shuaib

Hi MS,

To add with Amit's assessment of PLL being disabled in hibernation mode; I recall posting an issue some time ago about RTOS & PLL, a patch was required for it to function correctly. Perhaps they may have patched that in later versions of RTOS.

Muhammad Shuaib said:

The problem that i am facing is that after instrument goes into deep sleep, it only wakes up on timer interrupt i.e. after 10 seconds.

Do you not find it odd the MCU fails to magically wake from hibernation mode without toggling WAKE pin at any point of an external interface with MCU, e.g. the USB cable port? That is prior to the 10 second delay interrupt  

Your post also mentions the PWM peripheral yet no comment was posted. 

Muhammad Shuaib said:

As soon as MCU wakes up from deep sleep, the LEDs are turned ON again.

Would you not desire or even expect the GPIO peripheral and LEDS to turn off in deep sleep in order to conserve battery energy during hibernation mode? Does it not seem counter intuitive to have hibernation mode keep LEDS burning during an hibernation event?

Hi BP101,

Thank you for taking the time to add to this post.

We are using TI RTOS 2.16.1.14 which is the latest version available.

I do believe that only the hibernation module is active in hibernation mode and do agree with you. But, i am not having any issues with hibernation mode. Instead, as I mentioned earlier, i am having problems with deep sleep. I do believe we are the same page here that deep sleep and hibernation are NOT the same and are two different power modes. You are right. I do need my peripherals to be turned off and conserve energy in hibernation mode and am able to get things to work this way. But when it comes to deep sleep, i do need some peripherals to remain enabled in deep sleep and that works fine with everything except USB and PWM. The belief, that PWM can work with deep sleep, comes from EK-TM4C1294XL examples provided with TIVAWARE. There is an example named sleep modes in which an LED configured with PWM continues to work even in deep sleep.

I have also tried using SysCtlPeripheralClockGating(false) but that does not seem to resolve the issue with PWM or USB. The LEDs go off the moment my instrument goes into deep sleep. Please share your opinion regarding what can i be missing here.

Thanks,

Muhammad Shuaib

Hi Charles,

I have tried using SysCtlPeripheralClockGating(false). I even tried the PIOSC(SYSCTL_DSLP_OSC_INT) as clock source for deep sleep. Still, as soon as the instrument goes into deep sleep, the LEDs go off. I do have LEDs GPIO port and PWM0 module enabled in deep sleep. Can you please comment about what may i be missing here?

Thanks,
Muhammad Shuaib

Muhammad Shuaib said:

. But when it comes to deep sleep, i do need some peripherals to remain enabled in deep sleep and that works fine with everything except USB and PWM

Amit stated the PLL power is turned off during deep sleep, does it not makes sense PWM, USB peripherals can not use the PLL as a clock source and also enter deep sleep?

Muhammad Shuaib said:

The belief, that PWM can work with deep sleep, comes from EK-TM4C1294XL examples provided with TIVAWARE

Yea and they used current hungry LED to prove hibernation mode (deep sleep) does not effect PWM modules power source.

Hi Muhammad,

You were right I was confusing hibernation with sleep mode are separate functions. So the HIB module controls the peripherals power source and deep sleep controls peripheral power consumption by turning off clocks.

Did you ever change the PWM module clock source to use PIOSC as Amit had suggested after you set PIOSC as clock source for deep sleep? Perhaps will not help USB (peripheral) wake on INT since it requires the PLL clock source also be changed to PIOSC and USB from PLL must be >=30Mhz. In that case MOSC will be disabled but the PIOSC can also clock the PLL at 120Mhz.

Datasheet:

For further power savings the PIOSC can be disabled through the PIOSCPD bit in the DSCLKCFG
register. When the Deep-Sleep exit event occurs, hardware brings the system clock back to the
source and frequency it had at the onset of Deep-Sleep mode before enabling the clocks that had
been stopped during the Deep-Sleep duration. If the PIOSC is used as the PLL reference clock
source, it may continue to provide the clock during Deep-Sleep. See page 281.
Note: If the MOSC is chosen as the Deep-Sleep clock source in the DSCLKCFG register, the
MOSC must also be configured as the Run and Sleep clock source in the RSCLKCFG
register prior to entering Deep Sleep. If the PIOSC, LFIOSC, or Hibernation RTC Module
Oscillator (HIBLFIOSC or 32-kHz crystal) is configured as the Run and Sleep clock source
in the RSCLKFCFG register, and the MOSC is configured as the Deep-Sleep clock source
in the DSCLKCFG register, then two outcomes are possible:

■ If the PIOSC is still powered in Deep Sleep (using the PIOSCPD bit in the DSCLKCFG
register) then the PIOSC is utilized as the clock source when entering Deep Sleep and
the device enters and exits the Deep-Sleep state normally. The MOSC is not used as
the clock source in Deep Sleep.
■ If the PIOSC has been configured to be powered down in Deep Sleep, then the device
can enter the Deep-Sleep state, but cannot exit properly. This situation can be avoided
by programming the MOSC as the Run and Sleep clock source in the RSCLKCFG
register prior to entering Deep Sleep.

To provide the lowest possible Deep-Sleep power consumption as well the ability to wake the
processor from a peripheral without reconfiguring the peripheral for a change in clock, some of the
communications modules have a Clock Control register at offset 0xFC8 in the module register space.
The CS field in the Clock Control register allows the user to select the PIOSC or ALTCLK as the
clock source for the module's baud clock. When the microcontroller enters Deep-Sleep mode, the
PIOSC or ALTCLK becomes the source for the module clock as well, which allows the transmit and
receive FIFOs to continue operation while the part is in Deep-Sleep. Figure 5-6 on page 242 shows
how the clocks are selected.