[chirp_devel] How to brick an FT-60

[jon]

On Tue, 2014-04-08 at 16:56 -0700, chirp.cordless at xoxy.net wrote:
> So, some news:
> 
> My newer radio was returned from Yaesu, working. No charge.
> Same s/n, so they did repair it, not replace it.
> >From the manifest, they replaced the 24C256 eeprom and
> charged 0.5 hours labor.
> 
> So first, compliments to Jon jon at jonshouse.co.uk
> I'm still not believing eeprom wearout, but
> > You may not agree with my justification but its still the logical cure?
> appears spot on.
> 
> I followed up with an email asking several questions to try to
> get a little more info, but most of them were ignored. All I
> learned was that they don't see many eeprom problems, and
> the opinion that it was a defective IC (i.e., infant mortality).
> Which, given the scenario, I don't believe.
> 
> Maybe they don't actually track labor for warranty repairs and
> that's just nominal, but 1/2 hour to open up the radio, remove
> and replace the IC, and close it up seems like it would be more
> performance art than tech work. Adding any kind of eeprom
> formatting beyond what the radio reset itself does seems unlikely.
> But I didn't get an answer to that as well as a number of other
> questions I asked.
> 
> ==========
> > On Mar 25, 2014, at 7:48 PM, Dan Smith - dsmith at danplanet.com wrote:
> >> If I were you, I'd modify the driver to check the checksum after
> >> download, and then do a bunch of downloads of a good radio with the
> >> original cable and see if they occasionally don't match.
> > 
> > Excellent idea, and I will do that. ...
> > 
> > I might also implement an optional check for a couple of bits in the image
> > being set. ...
> 
> Without knowing what cause
> d two eeproms to fail, I've reversed my

I also said
"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 !"

IE I was saying its just as possible the rogue values crash the
firmware, but as you cant reprogram the EEPROM without the firmware so
you still have remove the EEPROM or clock new values into it to fix the
problem.  It is possible to clock SPI into the IC without removing it,
but that is even more tricky than just replacing it.


> opinion again on the old cable. I don't know how, but maybe there's
> an electrical problem that might manifest itself on read. I'm curious,
> but not enough to risk another radio. The new cable is doing downloads
> and I think I'll just move forward with that. If someone wants to borrow
> the old cable to try on _their_ FT-60, I'm open to that...
> 
> I did implement the download parity check, and I think that will
> be the first bug I request to integrate. I need to spend a little more
> time on the chirp developer instructions, which I'd been putting off
> while I was having fun in the code itself. Soon...
> 
> I also implemented a check on upload for the "bits of death",
> but I can't find a way to make it work as I intended with the
> existing upload sequence. By the time I can get control in ft60.py,
> the "Cloning ..." window is already open, and opening another
> dialog with that up doesn't work gracefully. I didn't want to
> mess with the core upload code that affects all radios by adding
> another callback method to the parent class. As I said, OOP is
> not my comfort zone.
> 
> So I hardcoded it, controlled by a boolean set to False, so
> that tested code can be enabled easily by changing that to
> True in the ft60.py code. Shall I put that back along with the
> parity check? Or other thoughts on this piece?
> 
> =========
> Returning to Jon's advice on replacing the eeprom:
> I opened up my old bricked FT-60. From the board layout diagram
> in the service manual, I'm pretty certain I've found the eeprom, but
> on top of my limitations with soldering smt devices:
> 
> 1) It's down in a hole between the headphone jack, the display,
> and a crystal.
Yes. It is marked Q1034 on the mask drawing, its an 8 pin device.

> 
> 2) It's marked "456M 41B3 06". Doesn't correspond to any IC
> nomenclature google knows about. Nor the Yaesu part number,
> which per the service manual is G1093837. So I'm not even
> 100% sure I've identified the right IC, although I think I have
Hmmmmm ... anything is possible but I would expect it to be marked
"AT24C something"

> .
> 
> I don't think it's prudent to ship that back to Yaesu for (paid)
> repair, at least for now. I don't have a real need for a spare HT.
> I'll let it marinate for awhile
Shame, in surface mount terms this IC isnt small stuff. Anyone local to
you who could replace it? I would offer but shipping to and from the UK
would cost more than the repair is worth.

Jon