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.

TUSB2046B: Detecting every device but no keyboards

Part Number: TUSB2046B
Other Parts Discussed in Thread: SEGGER

Hi,

I'm developing a board for the Raspberry CM4. Here is the relevant part of the schematic:

 

My confusing problem: The linux distribution on my CM4 is detecting nearly every device I tested like memory sticks, Segger JTAG adapters, RF mouse adapters and so on. But it does not detect any keyboard. Here is a log I made by "sudo tail -f /var/log/syslog" when plugging in a keyboard:

Sep 12 15:53:08 ac3000 kernel: [ 1113.439475] usb 1-1.4: new low-speed USB device number 54 using dwc2
Sep 12 15:53:08 ac3000 kernel: [ 1113.979470] usb 1-1.4: new low-speed USB device number 55 using dwc2
Sep 12 15:53:09 ac3000 kernel: [ 1114.420540] usb 1-1-port4: attempt power cycle
Sep 12 15:53:09 ac3000 kernel: [ 1115.079529] usb 1-1.4: new low-speed USB device number 56 using dwc2
Sep 12 15:53:10 ac3000 kernel: [ 1115.619511] usb 1-1.4: new low-speed USB device number 57 using dwc2

And this is the log when I plug in a memory stick:

Sep 12 15:54:21 ac3000 kernel: [ 1186.750085] usb 1-1.1: new full-speed USB device number 58 using dwc2
Sep 12 15:54:21 ac3000 kernel: [ 1186.882193] usb 1-1.1: not running at top speed; connect to a high speed hub
Sep 12 15:54:21 ac3000 kernel: [ 1186.888293] usb 1-1.1: New USB device found, idVendor=1221, idProduct=3234, bcdDevice= 0.00
Sep 12 15:54:21 ac3000 kernel: [ 1186.888313] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 12 15:54:21 ac3000 kernel: [ 1186.888332] usb 1-1.1: Product: Flash Disk
Sep 12 15:54:21 ac3000 kernel: [ 1186.888349] usb 1-1.1: Manufacturer: USB2.0
Sep 12 15:54:21 ac3000 kernel: [ 1186.888366] usb 1-1.1: SerialNumber: 1000000000001DCD
Sep 12 15:54:21 ac3000 kernel: [ 1186.889648] usb-storage 1-1.1:1.0: USB Mass Storage device detected
Sep 12 15:54:21 ac3000 kernel: [ 1186.890572] scsi host0: usb-storage 1-1.1:1.0
Sep 12 15:54:21 ac3000 mtp-probe: checking bus 1, device 58: "/sys/devices/platform/soc/fe980000.usb/usb1/1-1/1-1.1"
Sep 12 15:54:21 ac3000 mtp-probe: bus: 1, device: 58 was not an MTP device
Sep 12 15:54:21 ac3000 mtp-probe: checking bus 1, device 58: "/sys/devices/platform/soc/fe980000.usb/usb1/1-1/1-1.1"
Sep 12 15:54:21 ac3000 mtp-probe: bus: 1, device: 58 was not an MTP device
Sep 12 15:54:21 ac3000 kernel: [ 1186.990115] usb 1-1.4: new low-speed USB device number 59 using dwc2
Sep 12 15:54:22 ac3000 kernel: [ 1187.540120] usb 1-1.4: new low-speed USB device number 60 using dwc2
Sep 12 15:54:22 ac3000 kernel: [ 1187.924222] scsi 0:0:0:0: Direct-Access USB2.0 Flash Disk 2.10 PQ: 0 ANSI: 2
Sep 12 15:54:22 ac3000 kernel: [ 1187.925036] sd 0:0:0:0: Attached scsi generic sg0 type 0
Sep 12 15:54:22 ac3000 kernel: [ 1187.929200] sd 0:0:0:0: [sda] 1026816 512-byte logical blocks: (526 MB/501 MiB)
Sep 12 15:54:22 ac3000 kernel: [ 1187.932202] sd 0:0:0:0: [sda] Write Protect is off
Sep 12 15:54:22 ac3000 kernel: [ 1187.932225] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
Sep 12 15:54:22 ac3000 kernel: [ 1187.935211] sd 0:0:0:0: [sda] No Caching mode page found
Sep 12 15:54:22 ac3000 kernel: [ 1187.935233] sd 0:0:0:0: [sda] Assuming drive cache: write through
Sep 12 15:54:22 ac3000 kernel: [ 1187.981183] usb 1-1-port4: attempt power cycle
Sep 12 15:54:22 ac3000 kernel: [ 1187.993181] sda:
Sep 12 15:54:22 ac3000 kernel: [ 1188.007196] sd 0:0:0:0: [sda] Attached SCSI removable disk
Sep 12 15:54:23 ac3000 kernel: [ 1188.640106] usb 1-1.4: new low-speed USB device number 61 using dwc2
Sep 12 15:54:24 ac3000 kernel: [ 1189.180122] usb 1-1.4: new low-speed USB device number 62 using dwc2

When probing the D+ and D- signals with an oscilloscope during plugging in the keyboard I see some signals on D+ but just a flat zero line ion D-. 

As I'm no USB expert, does anybody have a hint where to look deeper? 

Thanks a lot!

Regards,
Oliver

  • Full-speed devices have a pull-up on D+; low-speed devices, on D-.

    Does the D- line have the proper voltage? Is your pull-down really 15 kΩ?

  • D- is flat 0V. The pull-downs are not exactly 15k, I put 20k||51k = 14.36k. I ordered 15k to make sure that this is not the problem, they will arrive tomorrow. 

  • Here are some analyser plots starting at plugin time, may this helps. First the non working keyboard:

    And this is how it looks like with a working memory stick:

    Channel 0: D-
    Channel 1: D+

  • Sorry all, I swapped the signals D + and D-. I just rechecked the signals, the correct statement must be:

    When probing the D+ and D- signals with an oscilloscope during plugging in the keyboard I see some signals on D- but just a flat zero line ion D+

  • 14.36 kΩ should not make a difference. Important is only that it is much weaker than the device's 1.5 kΩ pullup. (This means that in the idle state, D+ is low and D- is high for a connected low-speed device.)

    The host will drive the K state (D- low, D+ high) for 20 ms to wake up the device, or for 0.6 µs at the start of a low-speed packet.

    It looks as if there is a problem with driving D+ high. Is the pull-down too strong, or is there some solder bridge? Might there be a problem with the cable?

  • Is the pull-down too strong, or is there some solder bridge?

    I double checked the pcb and the resistor values more than once and I exchanged the TUSB2046, too. And should a solder bridge not be an issue with all devices?

    Might there be a problem with the cable?

    I tried four different keyboards, all the same. 

    While writing this lines I realize, that the problem might not relate just to keyboards but low speed devices in general. I analysed every device that works and all looks the same, D+ is rising first -> high speed. 

    Then I looked for other devices and I found an old mouse which seems to be low speed, too (D- rises first). And voila, it's not working either.

    I'm still not sure if it is really an exclusively hardware related issue, but on the other hand the same CM4 works on another board where no hub is used (direct connection to the usb pins of the CM4). The same applies to the official Raspberry CM4 IO Board, that uses a USB2514 from Microchip. Nevertheless, I am still at a loss... 

  • Can you provide a capture from when D- first goes high?

    The timing from the host seems off, the D- pullup should be high for 100 ms before reset is signaled.

  • Can you provide a capture from when D- first goes high?

    It's the second image of my previous post:

    Or did you mean something else?

  • Is that the first instance of DM going high after connect?  What should happen is that the DM goes high, and stays high for ~100 ms and then a USB reset is sent from the host.  So this timing doesn't match USB spec and may be causing interop issues with the keyboards.  

    Can you try powering up the system with a low speed device connected?

  • It looks the same. Here are some more captures with different resolutions:

    The device ends up in the idle state and the system shows:

    sudo lsusb -v

    ...
    Hub Port Status:
    Port 1: 0000.0100 power
    Port 2: 0000.0301 lowspeed power connect
    Port 3: 0000.0100 power
    Port 4: 0000.0100 power
    ...

    In the meantime I found this https://www.raspberrypi.org/forums/viewtopic.php?t=246248#p1625128 and this https://e2e.ti.com/support/interface-group/interface/f/interface-forum/595619/tusb2046b-single-or-multi-transaction-translator.

    Do you think this could be the reason?

  • Well, no USB full speed hub has a transaction translator, single or multi, those are only in high speed hubs.  It looks like something in the raspberry pi drivers are not supporting low speed device behind full speed hubs.

    You mentioned that you were able to get this to work with the USB2514 device, any chance you could get a scope shot of what the DP/DM lines look like there?

  • Here we are:

    The first difference seems to be the reset like signal at 300ms. 

  • It looks like something in the raspberry pi drivers are not supporting low speed device behind full speed hubs

    But USB2514 is a full speed device, too. From its datasheet regarding an input that detects V_BUS: "Detect Upstream VBUS Power: detects the state of the upstream VBUS power. The hub monitors VBUS_DET to determine when to assert the internal D+ pull-up resistor: (signaling a connect event)." So, D+ pull-up -> full speed, right?

  • It does appear that the USB2514 is a full speed hub.  For some reason, the host isn't sending the expected resets to the ports of the TUSB2046 like it is for the USB2514, which is causing the low speed device issues.  Without being able to see the UBS traffic between the host and the hub it is difficult to tell what is happening.