Prolific PL-3507 : Which resistor to remove to flash with newer firmware ?

[banzeo]

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 (http://club.myce.com/f61/prologic-pl3507-firmware-flash-problem-112972/#post957178)

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.

On myce, KTL helped me by answering my post on http://club.myce.com/f61/prologic-pl-3507-resistor-remove-flash-newer-firmware-342281/ . 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 http://pdf.datasheetcatalog.com/datasheet_pdf/pmc-sierra-inc/PM39LV010-70JC_to_PM39LV512-70VCE.pdf ).
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.

 

[betwixt]

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.

Brian.

 

[banzeo]

Concerning the hardware data protection there is this paragrah in the datasheet :

Hardware data protection protects the devices from unintentional erase or program operation. 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.

To read data, three control functions must be satisfied:
• CE# is the chip enable and should be pulled low (V_IL).
• 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<something>) 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.
Thanks

 

[betwixt]

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. It is quite possible that the component is on one of the PL3507 pins and it reads the pin to decide whether or not to permit the write operation software to run rather than electrically block the write enable signal.

Brian.