[chirp_devel] How to brick an FT-60

[chirp.cordless at xoxy.net]

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

As long as the failure mode isn't argued to be write wearout, I can
go along with this as a reasonable explanation. Either physical
damage of the flash or it's interface components, or corruption of
its contents.

There are so few data points, and they are so expensive to acquire.
In considering the evidence and my understanding, I actually think
that the most likely problem is the cable malfunctioning in some
unidentified way, followed by the image contents, followed by chirp.
followed by both radios being faulty. (electrically, not design).

I have ordered another cable and won't use the current one again,
pending some conclusion that the problem isn't the cable.
Which would likely, unfortunately, cost ruining another radio.
For $23 I will either get insurance against bricking a third radio,
or a valuable data point that it's not likely a faulty cable.

The new radio has gone back to Yaesu. Chirp wasn't mentioned.
Depending on what, if anything, is learned from their evaluation /
cost to fix / etc., I will consider your suggestion to replace the 24C256,
possibly on the older radio. It's certainly plausible, both as to the problem
and as a remedy. If it's really unrecoverable otherwise, it might be worth
the effort.

From the picture in the service manual, it looks like one of the 8-pin soic
(the parts list suggests 10-pin?) smt small-pitch packages. Too much
for my old eyes and design engineer's crappy soldering skills, so I'd have
to have someone else do it. A man needs to know his limitations.

BTW, I googled the 24C256 and the first hit was the data sheet from Atmel.
Now I don't know where Yaesu is getting their parts, but for what it's worth,
Atmel is spec'ing one million write cycles and 40 year data retention.

Thanks and regards,

-dan

On Mar 23, 2014, at 12:42 AM, jon - jon at jonshouse.co.uk wrote:
> 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