[chirp_devel] How to brick an FT-60

[jon]

On Sat, 2014-03-22 at 20:32 -0700, chirp.cordless at xoxy.net wrote:
> I think not. The radio state gets saved in flash every power off, at least.
> Kind of dwarfs a few hundred clone writes. And the radio was fairly new
> as these things go. And modern flash is usually good for 10K - 100K writes.
Ok, but the 24c256 is not a modern flash! it's an ancient device. 

I personally have managed to wear a few out just with write cycles.  It
is also possible to clock them with crap by touching the pins while they
are running, unlike "modern flash" they are not written in blocks at the
device level and need no unlock to perform a write.

> But it's plausible for the first radio's failure. Part of a spectrum of stuff
> related to what I said might be abuse, which also includes a lot of
> serial cable in & out, knob twiddling, ... 
> 
> But the new one died the day it was purchased, after two OK clone writes.
> On the third, with the same image that killed the first one, it died
> with the same symptoms. I'm not buying flash write wearout.
> 
> The bits did it.
Ok, I will take your word for it. I just guessed from the schematic in
the ft-60r service manual and personal experience with other radios, I
don't own one.

Unless the radio has some other place its storing its data, real flash
in the microcontroller for example, then my cure still probably works.
Its likely (I only suspect though) that the firmware when presented with
a blank or random eeprom contents should re-initialise it.

It would be possible to garble the contents of the eeprom by shorting
one of the LCD mux lines to the SPI clock line, this might change enough
data in eeprom to unblock the firmware from whatever endless loop its
crashed into - but like I said personally I would unsolder it and put a
new chip down !

You may not agree with my justification but its still the logical cure?

Thanks,
Jon