Hi,

In another thread, this issue came to light. Thought it was worth mentioning. I found I have 2 of these cables, both with the chipset. I havent tested yet..

If you use these cables, especially eBay ones, read the following to see if you are affected by a possible hardware flaw:


http://bigacid.wordpress.com/2008/12/08/jm20337-read-data-corruption-solution/
http://blog.gsantamarina.com/2009/11/data-corruption-problems-with-numerous.html

might be worth investigating...

The following thread at Seagate's forum discusses an insidious write corruption problem.

Silent write failures with 500G SATA in JM20337 USB enclosure:
http://forums.seagate.com/t5/Desktop-HD ... light/true

The OP writes that "all sector write operations seem to silently fail in DOS (using the Panasonic ASPI/USB driver + Adaptec ASPIDISK) and in Windows 98SE (using the JMicron drivers). However, in Vista, it works fine."

The cause appears to be noise between the USB and SATA signal traces.

"It turns out the problem is a PCB layout problem with my new USB enclosure (Forcom / Channel+ model 35HDUPS). The USB and SATA signal traces are too close together and the USB is corrupting the SATA. It only affects UHCI mode because 'USB1.1 signals swing from 0 to 3.3V while USB2.0 signals swing from -0.4 to 0.4V'".

I also had a write corruption problem which I could reproduce in Win98SE but not in Win XP. However in my case it occurred under USB 2.0. I never did resolve it.

Here is a reference circuit for the JM20337 (R4 is the problem resistor):
http://www.mts-sv.co.jp/tf002/TF002.pdf

It appears that R4 is used to configure one of the GPIO pins (GPIO2). In this case GPIO2 enables/disables SATA hot-plugging.

Here is a Linux bug report on the read corruption issue. Apparently Linux has a workaround.

[PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152D:2338 - Linux
http://linux.derkeiler.com/pdf/Mailing- ... g08755.pdf

_________________
A backup a day keeps DR away.

A bad day would be to "back up" a hard disk before writing new firmware, only to find silent write corruption had occurred when restoring. Not good as these are quite a common device and looks like the circuit is in a variety of devices unchanged.