Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 846 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TUSB8041: USB Hub disconnect when USB 2.0 keyboard fails

Jens Brynildsen
Intellectual 350 points
Part Number: TUSB8041

Hi,

I have created a USB hub design based on TUSB8041A that works well. The HUB shows up on the USB bus and when I connect USB High-speed devices to it, they show up and work as expected at 5Gbit/s. So far, all good.

In the design, I also need a "keyboard" that trigger certain keystrokes when hardware buttons are pressed. This is implemented in the form of a STM32F103C8T6 with USB HID firmware running at USB Full-speed. I have tested the "keyboard" part of this design separately in the form of a BluePill board on a breadboard (see picture) and in a minimized form with the STM32F103C8T6 soldered onto a breakout board with just a crystal/caps + a single 1.5k pullup on the D+ line (see picture). Both these designs work perfectly. On any computer (Windows, Ubuntu, OSX) they just show up as a keyboard and work. Still all good.

The problem is that when I move the STM32F103C8T6 design onto the same board as the USB Hub, it no longer works. Not only that, when the STM32F103C8T6-keyboard fails, it will often pull down the TUSB8041A HUB as well. A Unix log example of what happens can be found here: https://zerobin.no/?d14cd1e3e778e8e8#B8SyCLgnBcssc163t42Lq48GeBcvJP3EoHCMtx4bPF7Z 

If I cut the traces between the HUB and the STM32F103C8T6, the HUB works normally. If I then solder in GND, DP and DM of either the Bluepill Breadboard test or the STM32F103C8T6 Breakout board, it will work flawlessly. No errors whatsoever. Always comes up and works.

So - my question is then - what will cause a more ideally implemented version of the same device (STM32 on same PCB with differentially matched traces) to fail, whereas the very non-ideal design (with terrible quality wires of differing lengths with poor breadboard connections, soldered onto the USB HUB board) works flawlessly? Are there timing requirements for the TUSB8041A  that will break if a USB device is implemented on the same PCB? Could the connection be "too good"? Can it be a timing issue? (the STM32F103C8T6 device will be starting a few milliseconds before the TUSB8041A, since only the hub has timing requirements)

Regarding communications: Testing with a scope reveals that the STM device will only occasionally respond to the reset sent from the HUB. The HUB sends a reset, and then the STM responds only occasionally. I would say this is the fault of the STM if it wasn't for the tests showing that the same device will work great if it's not on the actual PBC (but rather in a breadboard). Here is a video showing the signals on DP/DM https://www.youtube.com/watch?v=ZxSBaxUTLRI

I've tried finding the solution for many days and nights now and I have exhausted my idea pool. I desperately need help from someone with more experience.

(Enclosed schematic + pictures of breadboard setups and PCB with STM)

Schematic0.2.pdf

  • 0
    TI__Guru 60870 points

    Hi Jens,

    Part of the issue may be that R22 (1,5K pullup for the keyboard) is pulled directly to the same 3.3V rail powering the hub.  A USB hub or host uses the DP line going high to detect a connect event on its downstream ports (see section 7.1.7.3 of the USB 2.0 spec for a in-depth explanation).  The DP pullup should only be pulled high when it senses VBUS applied - for an embedded application you can you the pwrctl outputs of the hub to determine when VBUS would be applied.

    I think from that point the hub and the keyboard get out of sync, the keyboard likely thinks it is suspended and is expecting resume where the hub may detect some kind of connection and attempt to reset the port.  Can you try externally powering the DP pullup and seeing if it helps resolve the issue?

    Regards,

    JMMN

  • 0 in reply to JMMN
    Intellectual 350 points

    Thanks for the swift reply !

    I too believe that this must be related to timing, but I seem unable to solve it. Today I tried driving the high side of the DP pullup resistor directly from my programmer and connected the grounds on the board. This yielded no difference. I also tried connecting it to the STM32, setting it high after 500ms with no change.

    I noticed that resetting the STM32 seemed to help when working on my Mac. When I tried it on a PC, this approach failed. I tried setting up a RC-delay on the STM32 of 0.1 seconds, but that gave no change. I then tried using a 10uF rather than 1uF for the GRSTz of the TUSB8041, but that also didn't cause a change.

    Throughout all these tests, the HID device will show up some times, but not consistently on my Mac. On a PC, it will never work. Windows will setup the hub, but the HID fails in all cases. Both the breadboard-examples work flawlessly on any OS, so I'm sure the firmware is solid. It's basically just the default HID example using HAL, working as a mouse. The cursor will move if the device is working.

    I would love to know more about what exactly fails. I have access to Windows, Mac and Linux computers, but need better feedback on what is failing. Any pointers to software for USB debugging would be great.

  • 0 in reply to Jens Brynildsen
    Intellectual 350 points

    For others who find this thread searching for the answer to how to get a USB device running smoothly on the same board as a TUSB8041 (or other USB Hub), here's what caused my problem and the solution to it.

    The suggestion from JMMN above is half of the solution: make sure the pullup on the DP to your USB device is not pulled directly to the power rail. This will cause the Hub to start talking to it right away and it takes a few MS to initialize the USB stack on these tiny devices. This caused the hub to start communicating while the USB stack was initializing. I solved this by letting the Microcontroller first initialize the USB firmware and then pulling the 1.5k resistor on DP high using the Microcontroller itself. 

    The other half was giving the Microcontroller a little more startup time so that the Hub was ready to receive the DP going high. I did this using a simple RC-delay, calculated using this tool https://www.digikey.no/en/resources/conversion-calculators/conversion-calculator-time-constant at Digikey.

    Hope this helps someone!