Re: [chirp_devel] How to brick an FT-60
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@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@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 caused two eeproms to fail, I've reversed my 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.
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.
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.
-dan
On Tue, 2014-04-08 at 16:56 -0700, chirp.cordless@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@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@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:
- 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.
- 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
Just some thoughts: without dumping the eeprom data (e.g., with a buspirate), and examining it, here is my wild speculation as to what it might be. I believe the "endless loop on bad data" is a possible scenario.
It's possible that in your bit twiddling, you set some value out of range from what the radio firmware normally expects, and if coupled with what could be some bug in bounds checking or the like, then the radio could end up in a bad state early in it's "boot up" phase. It's possible that what got changed was something that is referenced (and handled badly) early on in the boot process, before any reset procedures or clone programming could be reached.
In other words, you might have uncovered a bug in the radio, which under normal circumstances, might never be reached.
Dan, I'm not sure I agree with the cable interference theory. With most of the yaesus, isn't there a checksum byte at the end of the memory payload? I thought that I have tinkered with this and when the radio didnt like the image it "defaulted" the memory to a "Reset" state.
-Jens
________________________________ From: jon jon@jonshouse.co.uk To: chirp_devel@intrepid.danplanet.com Sent: Tuesday, April 8, 2014 8:21 PM Subject: Re: [chirp_devel] How to brick an FT-60
On Tue, 2014-04-08 at 16:56 -0700, chirp.cordless@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@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@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:
- 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.
- 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
_______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
(sorry for the delayed reply)
I'm not sure I agree with the cable interference theory. With most of the yaesus, isn't there a checksum byte at the end of the memory payload?
Yes, but we don't check it. So, if we *receive* a bad image, we will calculate the proper checksum of the bad image and then send it to the radio. The radio would check the checksum, see that it matches, and accept the image.
I thought that I have tinkered with this and when the radio didnt like the image it "defaulted" the memory to a "Reset" state.
If the checksum is wrong, this happens (although it doesn't wipe the memory, it just resets some things). I've never seen a yaesu do this because of actual bad contents with a matching checksum though.
--Dan
participants (4)
-
chirp.cordless＠xoxy.net -
Dan Smith -
Jens J. -
jon