• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 1084 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TUSB4041I: Down port MCU when moving quickly in-and-out of DFU mode for firmware update doesn't get enumerated

Garrick88
Prodigy 140 points
Part Number: TUSB4041I

Hello,

We have a new board with a TUSB4041I that is working well so far.

It is connected to an STM32F microcontroller on the 2nd port, and communication to the device is solid, except after the device comes out of a USB bootloader mode and tries to boot our new application code quickly. In this case, it is not detected or enumerated.

Unfortunately, we don't have a way to programmatically reset the TUSB4041I with a GPIO line between switching the STM32F into different USB modes, and we want to make sure that if our STM32F is moving between various USB applications that will change its PID/VID and everything else, it will still always enumerate properly on the 2nd port.

So, is there any way via SMBUS to tell the USB hub to re-enumerate the ports, a specific port, reset the device, etc.? I don't see anything in the register map, but maybe I just keep missing it. How long should I wait after this before I continue loading my USB stack on my MCU?

Any other suggestions?

Thank you.

Tusb4041I.pdf

  • 0
    TI__Guru 60870 points
    Hi Garrick,

    Can you clarify your application? It sounds like the STM32F is connected downstream of the TUSB4041 and the STM32F is not consistently enumerated by the host, is that correct?

    Unfortunately, USB hubs are slave devices that are not capable of doing port resets or USB resets without host driver interaction. Does the STM32F not do a disconnect / reconnect when switching modes? Or does it happen too quickly? If you can't change the behavior of the downstream device, you can force a hard reset to the TUSB4041 or you can use SMBUS to cause the hub to be re-enumerated along with all of the downstream ports by the setting and clearing of the CFGActive bit.

    Regards,
    JMMN
  • 0 in reply to JMMN
    Prodigy 140 points
    Hi,

    Your first statement is correct. Will certainly give CFGActive bit a try after new code boots.

    There is another oddity on our design: if GRSTz is held low for more than a few seconds, the TUSB4041I gets locked into reset-- everything is off, including the oscillation of the crystal. The hub can be woken up only by power cycling the board or unplugging and plugging back in the upstream (host) USB connection (so, a toggle on HUB_VBUS).

    We have a pushbutton switched attached to reset circuit (no bounce). Any short hit of this button and the TUSB4041I resets perfectly well, but holding it down for longer locks the hub. Any solution to this? It might not have a real system impact, but it has caused some debugging confusion.

    I've updated my first post with our TUSB4041I schematic.

    Thanks.
  • 0 in reply to Garrick88
    TI__Guru 60870 points
    Hi Garrick,

    Is the TUSB4041 permanently connected to the host? I suspect that with the hub being held in reset, the host disables the port where the hub is connected and when the hub exits reset it doesn't see any signalling from the host and enters suspend mode. You can enable the status output for suspend to check that.

    On a side note, the TUSB4041 implements the DP pullup internally as well as the 15K pulldowns. I would recommend removing the external resistors, as they may be causing some of the issues you are seeing.

    Regards,
    JMMN
  • 0 in reply to JMMN
    TI__Guru 60870 points
    Hi Garrick,

    Do you have any additional questions?

    Regards,
    JMMN
  • 0 in reply to JMMN
    Prodigy 140 points

    All issues are resolved, but the device still goes into a permanent suspend mode if  a user holds the reset button too long, but everything else is resolved.

    We have more testing and experiments to do, but I'll mark as resolved. Thank you for your help.