Hello I own an External Hard Drive Enclosure based on the PL-3507 chipset. (Brand SQP / Model BOIT-XPCOMBO) I need to flash it with a newer firmware because of some bugs with the Firewire interface but it is not possible. It seems this is due to a zero resistor which is sometimes put on those devices to prevent people from flashing it by themselves () In the post referenced above, the writer says which resistor to remove to enable flashing but on my device this resistor doesn't exist. It seems I don't have exactly the same device.

PL-2507 USB2.0 to IDE Bridge Controller. Firmware upgradeable through USB. Www.prolific.com.tw / E-mail: sales@prolific.com.tw Hsinchu Office. PL-3507 Combe:USB2.0 & IEEE 1394 Combo to IDE Bridge Controller. Sales@prolific.com.tw Hsinchu Office No.10-2, Lixing 1st Rd., Hsinchu Science Park. PL-2507 USB2.0 to IDE Bridge Controller. Firmware upgradeable through USB. Www.prolific.com.tw / E-mail: sales@prolific.com.tw Hsinchu Office. Free Download Prolific Technology PL-3507 Driver 1.7.0.0 (Other Drivers & Tools).

On myce, KTL helped me by answering my post on. He suggests two resistors which could be the ones to remove. Thanks to his suggestion I had a look at the specs of the chip ( PM39LV010-70VC here ). It seems that R5-something which is connected on PIN-30 and which corresponds to 'CE#' (chip enable) is the one to remove to allow access to the chipset. Moreover apparently it seems better not to touch to resistor R55 located above the otherone which is connected to pin-32 and corresponds to 'OE#' Is there anyone of you who knows which one I should remove whitout taking the risk to make the device unusable? I post the 2 pictures of the board of the device.

Thanks a lot. From what I gather form their respective data sheets, the PL3507 reads and stores (shadows) a copy of the EEPROM contents as it powers up. What isn't clear is how to put information in the EEPROM in the first instance.

The PL3507 data sheet suggests it can be done by writing to specific addresses through the USB interface which is a reasonable method and it would rely on that device's internal MCU providing the necessary command sequences to write to the memory. If it was to be write protected in hardware, the only way I can see to do it is to prevent WE# (pin 32) of the 39LV010 from going to low logic level. The CE# and OE# signals must still be under MCU control for the chip to be read so I doubt they have anything to do with it.

R55 is connected to WE# (pin 32) but it seems to have '0' marked on it which suggests it may be a link rather than a resistor so it's a good place to start looking. However, there is no mention of there being an internal pull-up source on that pin so simply isolating it by removing the link would likely cause chaos, as would tieing it directly to a logic high state. If there is a component to disable user flashing, it probably isn't R55 but another resistor or link somewhere between pin 32 and the PL3507 but it isn't possible to identify it from the photographs. Hardware data protection protects the devices from unintentional erase or program operation. Driver Behringer Bcd3000 Windows 7. It is performed in the following ways: (a) VCC sense: if VCC is below 1.8 V (typical), the write operation is inhibited. (b) Write inhibit: holding any of the signal OE# low, CE# high, or WE# high inhibits a write cycle. (c) Noise filter: pulses of less than 5 ns (typical) on the WE# or CE# input will not initiate a write operation.

The read operation (p5 of the datasheet) requires CE# to be low, OE# to be low and WE# to be high. Spiderman 3 Pc Full Ripped. To read data, three control functions must be satisfied: • CE# is the chip enable and should be pulled low (V IL). Driver Asrock N68c-s Ucc Windows 7 more.

• OE# is the output enable and should be pulled low (V IL). • WE# is the write enable and should remains high (V IH). So I imagined that on my board inhibition was made with '(b)' method and especially by keeeping CE# permanently low. And since CE# is on pin 30 that's why I imagined the zero resistor connected to that pin (R5) to be the 'culprit' Also, from what I read in the datasheet of PM39LV010, WE# is on pin 7 and not 32 as you suggest. Pin 32 seems to be OE# (according to the diagram '32 pin VSOP' at page 2) But since I'm not really qualified to understand these datasheets I'll trust you and won't try anything risky. You are right about the pin numbers, I was looking at the wrong package drawing! However, to read the EEPROM it is necessary to control the CE# and OE# pins so they have to be usable all the time.

The WE# pin only has to be used when writing data in to the EEPROM so that is the pin which would be used (if any) to write protect the device. If any component was added/removed to prevent the EEPROM contents being changed, such as in a 'flash update' it would almost certainly be on the WE# pin and not on the others. Unlike 'normal' memories, in order to write anything to that kind of device there is a special sequence of commands sent from the MCU to unlock the write operation and it has to be repeated for each byte so something has to be able to control the WE# pin to allow the commands to be written to it.