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.

USB stack servicing w/ deepsleep = timer inconsistancy

I'm having a problem with a Tiva C TM4C123 part that goes into deep sleep mode.  It is running the USB stack and when there isn't much going on it goes into deep sleep.  When it is busy it is running a timer and sampling and ADC.  The problem I'm having is that it seems that there is something going on behind the scenes with USB that I"m not understanding.

When the device goes into deepsleep it shuts down the PLL and runs of the 16Mhz external oscillator.  Therefore when the device goes to sleep I change the timer configuration from the one based on the 80Mhz PLL to the 16Mhz oscillator.  When the timer wakes it up the system starts the PLL up again so I change the timer count to be based on the 80Mhz PLL.  The issue is that there is something going on with the USB stack that wakes up the chip periodically and I can't figure out what it is.  When I add this timer management to the callback RX/TX functions for USB it doesn't help much.  If I don't connect the USB and trigger the device the timing is spot on.  Is there a lower level interrupt routine in the USB stack that I can put my timer_reconfigure function in?  I think the issue here is that the CPU is waking up to do some USB stuff at 80Mhz, but my timer is still set for the 16Mhz oscillator.  I just can't figure out where to put my timer reconfigure function regarding USB.

Basically, when the device is plugged in via USB and the timer is set to wake up at 10Hz and toggle an LED it toggles it too fast.  I'm setting my timer based on the 16Mhz oscillator when I go into sleep mode and when the timer wakes it up I reconfigure it for the PLL (80Mhz) when it's done I then change it back to be based on a 16Mhz clock etc.....  When USB is plugged in the toggle rate is a little fast ~15Hz rather than the expected 10.  When the device powers up off of a battery and I trigger it, it works perfect.  If I plug in the USB cable then remove it my speed is too high.  The only way the device works correctly is if the USB is never plugged in and the ARM comes out of powerup/reset NEVER seeing any USB connectivity.

Any Ideas?

Thanks,

Rob

  • There seems some misunderstanding on the operation of USB device.

    While a USB device connects to a host, the USB peripheral on the device should not stop working, so that it is able to accept transactions from host at any time, unless host orders bus Suspend. It is the essential concept of USB, which is host-centric. To make it realistic, host supplies VBUS (5V) power source of 100mA, at least.

    Therefore, your firmware should not drop USB clock until bus Suspend occurs.

    Maybe, your board is supplied just by the battery, and you want to reduce consumption of the battery. In this case, you have to consider to get supply from USB VBUS, while your board connects to host (dual power).

    If you would be allowed to design your board from scratch, these options were common for your purpose.
    a) Separate USB-UART (or USB-FIFO) chip, which is supplied from USB VBUS.
    b) USB MCUs with separate USB power domain on the chip, like MSP430

    I believe we may still have another options other than re-design.
    But to give good suggestion to your situation, I have to konw better on your design.

    1) What is the USB class?
    And what is the PC OS?

    Just adding a registry flag, you may easily drop HID and WinUSB devices into Suspend on Windows, while no communication occurs for a while.

    2) Is it possible to add a couple of components (diodes, etc) to make your board dual-powered?

    3) Does the VBUS pin of the TM4C123 connect to the VBUS pin of the USB connector?

    By the VBUS connection, your board detects plug-in to host. The USB peripheral and its clock is enabled just while USB plug-in, to reduce consumption of battery.

    Tsuneo

  • The issue is that there is something going on with the USB stack that wakes up the chip periodically


    Ah, I didn't answer to your question.
    While a device connects to host, host supplies SOF (Start Of Frame) signaling at every 1ms on full-speed bus, unless the bus is Suspended. The stack should respond to this SOF signal by USB interrupt.

    Tsuneo