#tusb3410 boot device

[piratesexmachine420]

For future reference (my own and others), if your TI SilverLink USB cable stops working and starts showing up as "TUSB3410 Boot Device" or similar under device manager (AKA this issue on TI's help page), this is how you can fix it:

Download the TUSB3x10 EEPROM Burner. This is a Windows-only program, but to my knowledge will work on basically any windows machine from XP on -- so long as it's got USB ports. No clue if it'll work in a VM. (You might want to consult this user's manual.)

Download the SilverLink firmware. I got it from here, and compiled it from their de-compilation. It's just a standard 'make' to build. The output file you're looking for is called "ti_graph_link_silver.eep".

Rename "ti_graph_link_silver.eep" to "ti_graph_link_silver.bin".

Open the TUSB3x10 EEPROM Burner, click on the options dropdown and click "Show the 'Program Full Binary Image' button". (page 7 of the manual).

Select the entry under "Computer" labeled "TUSB3410 EEPROM Burner Instance (1.00)".

Set EEPROM size to "64Kb".

Set "File Path" to point to "ti_graph_link_silver.bin". (The renamed .eep, not the original .bin)

I don't know if the VID, PID, Manufacturer string, Product string and Serial # need to be set manually or not with a 'Full Binary Image' burn. Just to be safe, I set VID to 0451, PID to e001, Manufacturer to "Texas Instruments", Product to "TI-GRAPH LINK USB", and checked "Not Serialized"*.

Click the "Program Full Binary Image" button (yellow triangle with the exclamation point), and proceed with the write.

Unplug and re-plug your cable, and it should show up as a SilverLink again!

Additional notes:

The reason that this happens is because the SilverLink cable (revision b, at least) is based on the TUSB3410 microcontroller. That microcontroller's boot process involves checking for an I2C EEPROM containing program code. If it finds that EEPROM and its contents are properly formatted, it'll copy that code into internal RAM and start executing it. If it can't find the EEPROM, or its contents aren't properly formatted, it'll fall back to looking for boot code over USB. Thus: "TUSB3410 Boot Device". Your cable has, in essence, forgotten who it is and and is begging for you to give it a purpose.

The default page-write buffer size (32 bytes) and I2C bus speed (400 KHz) in the burner app are already correct, so no need to change them.

*I don't remember exactly what the Manufacturer string, Product string, or serial number fields were set to pre-corruption. Likewise, no idea about the advanced descriptor options. If someone wants to send the output of lsusb -v -s [whatever their silverlink's bus/id numbers are], I'd really appreciate it!

You might be able to skip the header rigamarole by taking the ti_graph_link_silver.bin file directly ("directly coming from the compiler") -- but I again I don't know exactly what information is in the .eep file and what isn't. Are the PID and VID encoded somewhere in there? I peeked with a hex editor but have no clue. If someone has hardware lying around they're willing to experiment with/potentially brick, I'd love to hear your results!

If you mess up and accidentally forget to do a "Full Binary Image" write, or otherwise brick the firmware, you can force the TUSB3410 to fall back to USB boot mode by opening the plastic shell around the PCB (one Torx screw under the sticker, then just normal plastic tabs) and shorting the right-bottom (Vss) and right-top (SDA), or right-bottom (Vss) and center right-top (SCL) pins of the EEPROM (the chip labeled "24LC64") as you plug it into the USB port. You may need multiple attempts. This works because it temporarily convinces the TUSB3410 that the EEPROM is missing/corrupt, and thus it decides to fall back into USB boot mode -- until you reset it. It might be better to do this with a ~1k resistor instead of a jumper wire, but IDK I'm not an electrical engineer. All I know is that shorting Vss and SDA worked for me. Again, would love feedback.

No clue what causes the corruption in the first place, or how long this fix will last. It might be because the EEPROM's write protect pin is set to "write enable"? It could also just be degrading hardware, for all I know, so no idea how long the fix will last. All I do know is that everything seems nominal right now (immediately after performing this procedure).