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.

TUSB4020BI: Cannot enable custom serial number?

Part Number: TUSB4020BI
Other Parts Discussed in Thread: TUSB8042

Tool/software:

I'm configuring the EEPROM for the TUSB4020 (full p/n TUSB4020BIPHP).  We have two USB MCUs downstream with a USB-C connector upstream, and when I plug it into my PC, I get two COM ports as expected.  I can inspect the "Bus reported device description" of each COM port and verify my custom product string.  One of the MCUs is also wired to the TUSB4020 EEPROM I2C port so I can rewrite the EEPROM if desired.

I can enable custom strings in bit 7 of register 5 (Device Control), though TBH I can't find where in Windows to inspect whether I've changed the strings successfully, as opposed to the virtual COM ports.  However, if I set bit 6 of register 5 to enable a custom serial number, the TUSB4020 fails to enumerate correctly; Windows throws an error.

Here's my EEPROM dump that works (custom strings but no custom serial number):

00000000: 55 51 04 25 80 90 00 03 03 00 22 00 00 00 00 00 | UQ.%......".....
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000020: 09 04 08 0C 0C 00 00 00 00 00 00 00 00 00 00 00 | ................
00000030: 31 32 33 34 35 36 37 38 00 00 00 00 00 00 00 00 | 12345678........
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000050: 4D 61 6E 75 66 61 63 74 75 72 65 72 00 00 00 00 | Manufacturer....
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000090: 50 72 6F 64 75 63 74 20 4E 61 6D 65 00 00 00 00 | Product Name....
000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000F0: 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF | ................

And here's the dump with custom serial number enabled, which doesn't enumerate correctly:

00000000: 55 51 04 25 80 D0 00 03 03 00 22 00 00 00 00 00 | UQ.%......".....
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000020: 09 04 08 0C 0C 00 00 00 00 00 00 00 00 00 00 00 | ................
00000030: 31 32 33 34 35 36 37 38 00 00 00 00 00 00 00 00 | 12345678........
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000050: 4D 61 6E 75 66 61 63 74 75 72 65 72 00 00 00 00 | Manufacturer....
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000090: 50 72 6F 64 75 63 74 20 4E 61 6D 65 00 00 00 00 | Product Name....
000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000F0: 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF | ................

The only byte (really, the only bit) that's different is bit 6 of register 0x05.  Is there something special you're supposed to do to enable a custom serial number?

Dana M.

  • HI Dana:

      Let me look at  in detail thsi weekend. it should not cause enumeration issue.

    Best

    Brian

  • One of the MCUs is also wired to the TUSB4020 EEPROM I2C port so I can rewrite the EEPROM if desired.

    Hub EEPROM I2C is master, you can not use MCU to write EEPROM, so I think you did not write  EEPROM correctly.

    What is status or SMBUS pin?

    Best

    brian

  • I realize I may be speaking inaccurately... The TUSB4020 is probably enumerating correctly; however; Windows is flagging the USB hub as inoperable when the "customSernum" bit is set, and it's unclear why.

    The SMBUS pin is pulled high with 4.7K, so the TUSB4020 is configured to boot from EEPROM.  My MCU waits a minimum of two seconds after system boot to ensure that the TUSB4020 has had ample time to read its EEPROM at startup.  I have logic captures of reading/writing the EEPROM from the MCU, as well as a capture of the TUSB4020 reading the full EEPROM at startup.  So I assure you, I am programming the EEPROM correctly.

    I set up my logic analyzer to capture the EEPROM traffic when the TUSB4020 boots up.  I made a capture when the TUSB4020 works, and when the TUSB4020 fails (in WIndows).  The difference is exactly one bit (the custom serial number bit):

    Logic capture when booting TUSB4020 with Custom Serial bit set

    Comparison of EEPROM contents when working vs. not working

    Here are the errors I get when the custom serial number bit is set:

    USB device not recognized

    Device not working properly  Windows driver status

    Again, it's not critical to my application that I set a custom serial number; however, it does seem strange that setting this bit causes Windows to reject the device.

    Dana M.

  • After you changed EERPOM, can you remove I2C bus from MCU to EEPROM?

    Best

    brian

  • Not without cutting traces.  When the MCU is not accessing the EEPROM, its I2C pins are in hi-Z and do not affect the operation of the bus.

    I sense you are concerned that my using an MCU as an in-system EEPROM programmer is somehow affecting the operation of the TUSB4020.  I am convinced it is not.  So to dispel that notion, here is what I just did:

    1. Programmed the MCU with a "working" TUSB4020 EEPROM configuration.
    2. Used the MCU to apply a "working" configuration (exactly as above) to the TUSB4020 EEPROM.
    3. Used the MCU programmer to erase the MCU.  I heard USB disconnect chimes, and one of the virtual COM ports is now gone.
    4. Held the system in reset for a few seconds, until I heard the USB disconnect chimes.
    5. Released reset and heard the TUSB4020 enumerate with no errors.  The second virtual COM port is still present (the other MCU connected to the USB hub).
    6. Reprogrammed the MCU with a "broken" EEPROM configuration.
    7. Used the MCU to apply a "broken" configuration to the TUSB4020 EEPROM.
    8. Used the MCU programmer to erase the MCU (again).
    9. Held the system in reset for a few seconds, until I heard the USB disconnect chimes.
    10. Released reset, there was a slight pause, and heard the TUSB4020 enumerate with the error popping up.  No virtual COM ports are present.

    In both of these test scenarios, the MCU I used to program the EEPROM is wholly inactivated prior to rebooting the TUSB4020.  My logic analyzer verifies that the TUSB4020 reads the entirety of the EEPROM successfully (sadly, your forum will not let me attached the .sal Saleae Logic capture).

    I understand that you are trying to eliminate any stray factors here.  But this is not my first rodeo, and everything I am seeing shows me that 1) I am writing what I think I'm writing to the EEPROM, and 2) the TUSB4020 is having no problem reading the entire content of the EEPROM.  I have narrowed it down to the fact that when the EEPROM byte at offset 5 is 0x90, the USB hub comes up successfully in Windows 10, and when the byte is 0xD0, Windows 10 shows a driver failure.

    Again, this is not a showstopper for me; our application will work fine even if I can't set a custom serial number.  But it is strange to see what should be a standard chip feature malfunction when used.

    I would recommend you use the EEPROM data (attached below) and load it into a TUSB4020 on your end, then plug it into a Windows 10/11 PC and see what happens.  If you can't reproduce it... oh well.  If you can... well, then you've got something to look into.

    0x55 0x51 0x04 0x25 0x80 0x90 0x00 0x03 
    0x03 0x00 0x22 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x09 0x04 0x04 0x0C 0x0C 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x31 0x30 0x30 0x30 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x4D 0x61 0x6E 0x75 0x66 0x61 0x63 0x74 
    0x75 0x72 0x65 0x72 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x50 0x72 0x6F 0x64 0x75 0x63 0x74 0x20 
    0x4E 0x61 0x6D 0x65 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00
      
    0x55 0x51 0x04 0x25 0x80 0xD0 0x00 0x03 
    0x03 0x00 0x22 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x09 0x04 0x04 0x0C 0x0C 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x31 0x30 0x30 0x30 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x4D 0x61 0x6E 0x75 0x66 0x61 0x63 0x74 
    0x75 0x72 0x65 0x72 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x50 0x72 0x6F 0x64 0x75 0x63 0x74 0x20 
    0x4E 0x61 0x6D 0x65 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
    0x00 0x00 0x00

    Dana M.

  • Ok, I will try on EVM  sometime this week.

    Best

    Brian

  • FWIW, I was able to connect our device to an embedded Linux host, and it successfully enumerates without the custom serial number.  Now that I have a different host system to try, I will experiment with different EEPROM settings and see how they affect the Linux host.  I suspect the non-sensical Chinese is appearing because the host expects Unicode, and I put in ASCII.  I was separately configuring a TUSB8042 today, and I could see in the default I2C registers that the serial number appears as Unicode.  I'll experiment with different strings and lengths as well.

    [  680.704544] usb 1-1: new high-speed USB device number 3 using ci_hdrc
    [  680.907028] usb 1-1: New USB device found, idVendor=0451, idProduct=8027, bcdDevice= 1.10
    [  680.915502] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    [  680.922807] usb 1-1: Product: 湉楦楮楴䤠摮捩瑡牯䠠扵
    [  680.928958] usb 1-1: Manufacturer: 慃瑮敲汬䜭楡据
    [  680.934451] usb 1-1: SerialNumber: CD0100615141

    Dana M.

  • It's interesting finding, I can't read these Chinese traditional character.

    Best

    Brian

  • Right, I plugged that into Google Translate, and it couldn't make sense of it.  I did some more reading, and USB strings are required to be encoded in UTF-16LE.  So for instance, the string "ABCD" would be encoded as 41 00 42 00 43 00 44 00.  I mistakenly put my strings in as straight ASCII, or 41 42 43 44.  That's why they appear as random non-sensical Chinese characters.

    So, I did some further investigation... and it appears that Windows 10 was violently objecting to the serial number string (in UTF-16LE) 0x3231 0x3433 0x3635 0x3837.  For whatever reason, that particular string was giving Windows fits, enough that it refused to fully enumerate the hub.  But if I take care to convert my ASCII strings to UTF-16LE, then Windows properly recognizes both the custom strings and the custom serial number.  Note that offset 0x05 is now value 0xD0, indicating that custom strings and custom serial number are enabled:

    00000000: 55 51 04 25  80 D0 00 03  03 00 22 00  00 00 00 00 | UQ.%......".....
    00000010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    00000020: 09 04 14 18  18 00 00 00  00 00 00 00  00 00 00 00 | ................
    00000030: 31 00 32 00  33 00 34 00  35 00 36 00  37 00 38 00 | 1.2.3.4.5.6.7.8.
    00000040: 39 00 30 00  00 00 00 00  00 00 00 00  00 00 00 00 | 9.0.............
    00000050: 4D 00 61 00  6E 00 75 00  66 00 61 00  63 00 74 00 | M.a.n.u.f.a.c.t.
    00000060: 75 00 72 00  65 00 72 00  00 00 00 00  00 00 00 00 | u.r.e.r.........
    00000070: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    00000080: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    00000090: 50 00 72 00  6F 00 64 00  75 00 63 00  74 00 20 00 | P.r.o.d.u.c.t. .
    000000A0: 4E 00 61 00  6D 00 65 00  00 00 00 00  00 00 00 00 | N.a.m.e.........
    000000B0: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    000000C0: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    000000D0: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    000000E0: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
    000000F0: 00 00 00 FF  FF FF FF FF  FF FF FF FF  FF FF FF FF | ................

    Sorry to send you on a bit of a goose chase, but at least we now know it was a Windows issue and not a TUSB4020 issue.  For anyone reading this... just make sure your ID strings are always in UTF-16LE.  I do see that the datasheet mentions this; it was just frustrating that Windows decided to throw an error instead of presenting a nonsensical string.  Thank you for the assistance.

    Dana M.