Post subject: Seagate Slim USB drives with INIC-3609 bridge

I have around 50 Seagate Slim USB 3.0 drives. The ones with Initio INIC-3609 bridges for SATA-USB are all unreliable with occasional 'silent' corruption (no pop-up in Windows, just an Event Log entry), Delayed Write Failed pop-ups, and momentary disconnects. The drives with other bridges all work fine.
The problem is not cables, soldering, voltage/PSU, or anything else like that. I test the drives (read+write+verify all sectors), put them into service, and they start to malfunction within a few days of use (several threads updating log files every 30-60s). Same behaviour on three different PCs. The drives work flawlessly after the Initio bridge is replaced with an ASMedia or JMicron bridge.
Seagate claims there are no firmware updates. I'm interested in trying the INIC-3609 v5.08 firmware from usbdev.ru to see if these drives can be fixed without having to do a bridge swap. The FW update tool is included with an official update for a FANTEC enclosure here:
https://www.fantec.de/support-downloads/downloadsuche/
Enter the model 'ER-U3', select 'ER-U3 Docking Station', and press the search button.
The two tools 'Config.exe' and 'MTPwin2.exe' both scan for a compatible device, but find nothing. 'iCommon.dll' seems to be hardcoded with PIDs 3910, 3940, and 3980 along with 'INIC-3609' for the device name. I tried changing the three instances of 'INIC-3609' to 'BUP Slim SL' (for a silver Backup Plus Slim) and all of the PIDs to AB24 (VID:PID is 0BC2:AB24 for Backup Plus Slims), but the scans still fail.
If anybody knows how to get the Initio FW update software to work that would be great.
Thanks!

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

If you invalidate the EEPROM (by shorting an appropriate pin to ground?), does the bridge revert to its generic factory code? It should identify itself as an INIC-3609 rather than a Seagate device.

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

Thank you very much for the suggestion. While I've read that doing that is possible I haven't tried it yet. The goal is to be able to 'fix' drives with INIC-3609 bridges without having to pry apart the enclosures (which don't always snap together cleanly after disassembly, and I could just swap the bridge boards once they're open anyway).
I made a couple more changes in a hex editor (replacing a suspected location of the VID with the Seagate value and reverting the string to 'INIC-3609' in case the bridge always returns its real name to commands from the flashing software) but no combination has worked yet.
I'm also exploring the possibility that the problem is UASP-related. A number of early controllers and bridges, especially with early firmware, are known to have unreliable UASP support. While I haven't seen it specifically mentioned, the INIC-3609 may be one of those chips.
The three USB 3.0 controller cards all have Renesas uPD720201 chips. Each card is from a different controller card manufacturer. The three computers used for testing are all using the Renesas 3.23.0 driver, although they all have different Windows versions (7 64-bit, 2003 64-bit, and XP 32-bit). Renesas claimed in press releases in 2011 and 2013 that their driver supports UASP in XP, Vista, and 7 via driver code from Media Logic. INIC-3609 also supports UASP, so I am assuming UASP is active. I would like to try disabling UASP (revert to BOT mode) on either the bridge or the driver. I've contacted Initio, but they haven't updated their site in a couple of years and may be defunct. I'm waiting to hear back from Renesas as well.
I'm aware that in Widows 8/8.1/10 using the generic built-in driver and replacing uaspstor.sys with usbstor.sys is an effective means of disabling UASP on the Renesas controller, but since the PCs using the Seagate USB drives can't currently be upgraded to 8/8.1/10 it doesn't matter if that solution would work. Also, Microsoft may break the ability of that solution to work at any time in a future security or feature update, so it can't be considered a long-term solution.
Any additional help or suggestions would be welcome!

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

FYI, the following document contains a reference circuit for the INIC-3607 (page 10). It appears to be pin compatible with the INIC-3609 (according to the evaluation board on page 13).
http://www.semisolution.com/fsbClient/__ezbdownload.jsp?bm_seq=14168&ba_seq=15&order=3&fname=USB3+0_initio.pdf
The bridge IC contains 32K ROM, so I would think that this generic code would take precedence over the external vendor specific code/data if the EEPROM were absent. You could short the EEPROM's /HOLD pin to ground while you power up the bridge, then release the short. Just make sure that the /HOLD pin is not hardwired to Vcc.

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

This is the device ID section of the Fantec firmware payload file (YuanJi_3609_3940_fw_v313.bin):

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

I also found this in the Fantec payload file:

That's the VID/PID for a Seagate product, maybe an Expansion model (0x231B is an Expansion).

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

That's an interesting find, thank you very much for sharing it. I hadn't examined the payloads at all yet since the compatible device scanning process doesn't require a payload. Those VID/PID addresses may be useful later if I can get device detection to work.
I've heard back from Renesas. Unfortunately they're not going to help with anything driver or firmware-related citing a lack of support resources.

Post subject: Re: Seagate Slim USB drives with INIC-3609 bridge

Minor update. I received a response from Initio a few weeks ago and they asked for additional information on this problem. I provided details to them, but haven't heard from them again.
Also, I did extended (two weeks) testing of a drive that has problems via the INIC-3609 in USB 3.0 mode, but it's perfectly stable in USB 2.0 mode. Whether it's UASP, USB 3.0 in general, or something else that's causing the problem is still unclear.
I'll write to Initio again soon if I don't hear back from them.