USB-IDE Bridge Fail - old Freecom External : HW encryption?

[fzabkar]

Your id of the dual power switch appears correct too. Is this a suitable datasheet:

http://www.micro-bridge.com/data/syncpower/SPP4925.pdf

The SPP4925 appears to be functionally identical to the APM4925K.

[ConnorHdd]

To what you attribute the title "5v switch mode regulator", well, all I can say is, here's a bigger picture.

[ConnorHdd]

And to that which you suspect to be eeprom, again I offer a bigger picture, somewhat marred by some white crud.

[ConnorHdd]

I've had chance to test the potentials of the LDO:

Seems okay, no?

[ConnorHdd]

Since the OP has already tried an external power source, then this would suggest that the onboard 5V supply may not be a problem, unless the bridge firmware is testing for its presence, or requires it for some other purpose. That said, perhaps the linear regulator runs of the +5V regulator rather than USB power, so you may be right after all. A simple test with a multimeter should confirm this one way or the other.

I get you are refering to the two sources of power on the board here: that provided by the USB and that provided by the dc in (via external psu). However, I'm not quite clear where I should be testing. Any help would be much appreciated. Thanks.

[fzabkar]

AT24C256N, Atmel, 256Kbit (32K x , serial EEPROM:
http://www.atmel.com/Images/doc0670.pdf

MC34063EB, STMicroelectronics, DC-DC converter controller, marking 063EB:
http://www.st.com/web/en/resource/techn ... 001232.pdf

[fzabkar]

The LDO looks good. If you now CAREFULLY measure the pins of the 4925 dual MOSFET switch, you should find +12V and +5V on the Source pins. The +5V supply will be generated by the MC34063EB, not by the USB port. Please don't slip with your probes, as catastrophic damage will probably result.

[ConnorHdd]

The LDO looks good. If you now CAREFULLY measure the pins of the 4925 dual MOSFET switch, you should find +12V and +5V on the Source pins. The +5V supply will be generated by the MC34063EB, not by the USB port. Please don't slip with your probes, as catastrophic damage will probably result.

Right. Thanks for that. You've really put me at ease

[fzabkar]

The MOSFETs are controlled by the PL-2507 bridge via the Gate pins. The Source pins are connected to +12V and +5V. If you short gate-to-source, then you will impress the corresponding supply voltage directly onto the bridge, thereby destroying it.

[ConnorHdd]

AT24C256N, Atmel, 256Kbit (32K x , serial EEPROM:
http://www.atmel.com/Images/doc0670.pdf

MC34063EB, STMicroelectronics, DC-DC converter controller, marking 063EB:
http://www.st.com/web/en/resource/techn ... 001232.pdf

Good stuff. I have SMD marking code guides but it would seem only experience will help. Googling only ever produces garbage. How do you do it?

[fzabkar]

The AT24C256N was obvious. In the second case it helped to recognise the logo, and in retrospect the chip is a very common one which you can find in mobile phone chargers such as those powered from a car cigarette lighter.

[ConnorHdd]

The MOSFETs are controlled by the PL-2507 bridge via the Gate pins. The Source pins are connected to +12V and +5V. If you short gate-to-source, then you will impress the corresponding supply voltage directly onto the bridge, thereby destroying it.

Gotcha. It's getting kinda late here, so I think I may just leave this 'til the morning when I'm fresher if you don't mind.

In the meantime, just to take the stress out of the operation (and thus steady the old hand), could I trouble you to confirm the pin voltages on the below pic? Cheers, and thanks for all your help. I really appreciate it.

[fzabkar]

Pins 5 & 6 are wired together, so they should be at the same potential. Likewise with pins 7 & 8.

If I'm correct in my assumption that the dual MOSFET is switching 12V/5V power to the drive, then one would expect to find 12V on one pair of Drain pins, and 5V on the other pair. You can easily and safely confirm that this should be the case by measuring the resistance (with the power switched off) between the red (+5V) wire in the Molex connector and each of the drain pairs. This will tell you which drain pins are switching the +5V supply to the drive. Similarly, you could determine the +12V drain pins by metering their resistance to the yellow (+12V) wire.

Rather than metering the dangerous "busy" areas around the MOSFET, you could determine if +5V exists by measuring the voltage at the coil adjacent to the MC34063 IC. Of course you will need to do this with the power applied.

[fzabkar]

One other thing that might help us understand what is happening would be to determine which chip, if any, is driving the LED.

It might also be that the bridge doesn't power up the drive unless it can detect a USB host, in which case it would be an idea to test for continuity at each of the USB pins.

One more question. When you measured +5V at the LDO, was this with the USB cable plugged in and powered from the host? If not, then the +5V regulator must have been supplying the power to the LDO rather than the USB port, in which case you needn't bother testing the Source pins of the MOSFET. Otherwise, remove the USB cable and power the board on its own. If you still measure +5V, then the switchmode regulator will be working.

[ConnorHdd]

Pins 5 & 6 are wired together, so they should be at the same potential. Likewise with pins 7 & 8.

.

Oh for heaven's sake : as if that is not bloody obvious! I was (mis) reading the datasheet rather than bothering to look at the PCB. I'm making a total fool of myself. I'm trying to do too many things at the same time - not good with my lack of experience. It's unfair to you and others kindly helping me, and quite soul destroying for me. My tax return has to be in by midnight GMT on the 31st Jan, so I'm not giving this the attention it deserves. Please bear with me. I don't expect to make much progress here for a day and a half. I hope that's okay.

I will just say that:

- the drive does not power up unless the USB cable is "hot";
- the LDO was tested without the USB plugged in.

Thanks for your help. I hope the small hiatus won't dull your interest in my problem or your generosity. I'll keep monitoring this thread even if I don't have chance to do tests.

[fzabkar]

- the drive does not power up unless the USB cable is "hot";
- the LDO was tested without the USB plugged in.

It appears that the onboard power supplies are OK. Therefore the problem must be in the bridge IC or its firmware, or in the USB port.

You can determine if the bridge is working by invalidating the EEPROM and forcing the bridge to identify itself to the USB host using its default Prolific Vendor ID and Product ID rather than Freecom's. Before we try this, please verify the USB continuity by installing a USB cable and confirming that there is zero resistance between each of the pins at the host end and the corresponding pins at the device end on the PCB itself, and preferably at the DM and DP pins (47 & 48, Data+ and Data-) on the bridge IC.

http://pinouts.ru/Slots/USB_pinout.shtml

Here is a quote from a Prolific application note:

http://pdf.datasheetarchive.com/indexer ... 043359.pdf

- No external memory:This case is not recommended. The chip will use the default configuration in the internal ROM and run the firmware in the internal ROM. Firmware upgrade is not possible. The chip will send default Vendor ID, Product ID, chip operation settings, and other default configuration. Product serial number will not be sent.

- I2C Serial EEPROM:This case uses I2C serial EEPROM to store chip configuration data or configuration data with new firmware. If the I2C serial EEPROM size (like AT24C256) is large enough, a new version firmware can be stored therefore new firmware upgrade is possible. If new version firmware is stored in the EEPROM, new firmware will be loaded while system startup.

[ConnorHdd]

... the problem must be in the bridge IC or its firmware, or in the USB port.

You can determine if the bridge is working by invalidating the EEPROM and forcing the bridge to identify itself to the USB host using its default Prolific Vendor ID and Product ID rather than Freecom's.

I've just received this from an early communication with Freecom:

The Personal Media Suite should read the PID and VID of the PCB and check if the PID and VID are from Freecom. If there is no Freecom PCB, or no PCB at all, the software will not be able to determine if the hard drive was Freecom, therefore it will state that no Freecom device will be detected. The hard drive should be connected to a PCB manufactured from Freecom otherwise it will not work. It might not work for recent Freecom PCBs, so retrieving data would be extremely difficult, I am afraid. You might try to look for a very old Freecom hard drive, manufactured on 2005, running Personal Media Suite, on some online shops like Amazon or eBay

Is there not a danger that, by invalidating the EEPROM, the PCB will not be capable of identifying itself as Freecom, and thus I will not be able to use the Personal Media Suite to interrogate the HD through the PCB, let alone expect decryption?

[fzabkar]

I am not suggesting that you permanently invalidate the EEPROM.

At the moment you are getting no response from the bridge IC. It could be that the bridge is dead, or it could be that there is a firmware problem on the bridge board, or a dead crystal, etc. By making the bridge IC believe that there is no external EEPROM, you will force it to rely on its internal ROM based firmware. If the bridge IC is alive, then it will enumerate as a Prolific device. You will be able to see this with a tool such as USBDeview.

http://www.nirsoft.net/utils/usb_devices_view.html

Once you have completed this test, then you can restore the board to its original state. In fact some people short the relevant pins with tweezers, in which case there would be nothing to undo.

[ConnorHdd]

Back again after a grueling tax return. Thanks for your patience.

I am not suggesting that you permanently invalidate the EEPROM.

At the moment you are getting no response from the bridge IC. It could be that the bridge is dead, or it could be that there is a firmware problem on the bridge board, or a dead crystal, etc. By making the bridge IC believe that there is no external EEPROM, you will force it to rely on its internal ROM based firmware. If the bridge IC is alive, then it will enumerate as a Prolific device. You will be able to see this with a tool such as USBDeview..

Ah right! You want me to short it. Bring the Data Out, or in this case, SDA, to GND, no? Sounds like a plan either way.

[ConnorHdd]

PS: I've had the chance to test USB continuity from the host plug end to the device receptacle end: seems fine.

I guess that means we proceed with the eeprom shorting. Can I just confirm the pins with you here (seeing as I made such a jumble of things earlier) please?

Here's how I think things stand:

I'm planning on using tweezers. I am right in thinking NC, A0 and A1 are all connected to GND, yes? It will make the task easier knowing this.

Thanks for your help.