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.

MSP430F5529 detecting USB dedicated charging port.

Other Parts Discussed in Thread: MSP430F5529

Hi,

We are currently using the USB HID stack v1.19. 

Is support for detecting a dedicated charging port on the USB port going to added to the USB stack? Ie. detecting if D+ and D- are shorted together. 

If not, is there an advised method of detecting this with a MSP430F5529?

Is there another release of the USB stack planned for the near future?

Regards,

Brett

 

 

  • Hi Brett,

    I use a 5528 and experienced that Vbus is detected and recognized by the USB stack. This happens also on an USB power supply without D+/D- connected. You will get ST_USB_CONNECTED_NO_ENUM as well as a Vbus_On Event. Enumeration will not happen :-) . I use this to start charging.

    If you need a special detection then I would disable the USB stack after some time without enumeration. If you disabled the USB stack you can use the data ports for whatever purpose you like (see MSP430 USB HID API Guide, chapter 3.4).

    Regards
    Guenther

  • Hi,

    That is what I hoped would happen - USB connects connection state goes to ST_USB_CONNECTED_NO_ENUM, then I would start the charger. However with our board the connection state goes to ST_NOENUM_SUSPENDED.

    Any ideas why? I do have the 1Meg pull-down on D+, and the USB BSL switch on the board.

    Regards,

    Brett 

     

  • Hi Brett and Guenther

    Just after device connection, the device doesn't need to enter Suspend.
    "Connect Timing ECN" from USB.org tells on this spec change.

    USB2.0 Connect Timing ECN (included in USB2.0 spec zip)

    Post-connect current timing
    The Battery Charging spec allows devices to draw 100mA for 1 second after the connect event, regardless of what is happening on the bus.

    The USB 2.0 spec currently requires devices to drop down to suspend current within 10ms of no bus activity, during both the attach debounce time (TATTDB) and during the reset time (TDRST). In practice, no devices do this. During USB compliance testing, suspend current is not tested until several seconds after the connect event.

    The USB 2.0 spec would be modified such that a device is not required to drop down to the suspend current during the 1 second immediately following the connect event.


    On the v1.19 stack, USB_handleVbusOnEvent() enables Suspend interrupt by calling USB_reset()
    Temporarily, the code is fixed as follows.

    usb_eventHandling.c

    BYTE USB_handleVbusOnEvent()
    {
        //TO DO: You can place your code here

        //We switch on USB and connect to the BUS
        if (USB_enable() == kUSB_succeed)
        {
            USB_reset();

            USBIE = RSTRIE;          // enable just bus reset interrupt  <-------- add this line

            USB_connect();  // generate rising edge on DP -> the host enumerates our device as full speed device
        }
        return FALSE;   //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)
    }

    But for better fix, common initializations should be separated from USB_reset()
    USB_reset() mixes up all sort of initialization, too much.
    Some initialization should go to power-up one, others should move to Set_Configuration handler.

    Tsuneo

  • Hi,

    Thanks for the help.

    With that modification the unit no longer goes into ST_NOENUM_SUSPENDED when a dedicated charging port is connected. It now remains in ST_ENUM_IN_PROGRESS.

    Is there a recommended method for detecting the D+ D- short in a dedicated charging port with the MSP430f5529? Or is my suggested approach sufficient? I thought perhaps if the unit remained in ST_ENUM_IN_PROGRESS for too long, then using the USB port pins as IO, enable/disable PUR and detect the change of state D-. 

    Regards,

    Brett

     

     

**Attention** This is a public forum