<html><body><div style="color:#000; background-color:#fff; font-family:lucida console, sans-serif;font-size:10pt"><div><span>Just some thoughts:</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>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.</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span>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.</span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;">In other words, you might have uncovered a bug in the radio, which under normal circumstances, might never be reached.</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size:
13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;">Dan, </div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;">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?</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;">I thought that I have tinkered with this and when the radio didnt like the image it "defaulted" the memory to a "Reset" state. </div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color:
transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;">-Jens</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'lucida console', sans-serif; background-color: transparent; font-style: normal;"><br></div> <div style="font-family: 'lucida console', sans-serif; font-size: 10pt;"> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font size="2" face="Arial"> <b><span style="font-weight:bold;">From:</span></b> jon <jon@jonshouse.co.uk><br> <b><span style="font-weight: bold;">To:</span></b> chirp_devel@intrepid.danplanet.com <br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, April 8, 2014 8:21 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [chirp_devel] How to
brick an FT-60<br> </font> </div> <div class="y_msg_container"><br>On Tue, 2014-04-08 at 16:56 -0700, <a ymailto="mailto:chirp.cordless@xoxy.net" href="mailto:chirp.cordless@xoxy.net">chirp.cordless@xoxy.net</a> wrote:<br>> So, some news:<br>> <br>> My newer radio was returned from Yaesu, working. No charge.<br>> Same s/n, so they did repair it, not replace it.<br>> >From the manifest, they replaced the 24C256 eeprom and<br>> charged 0.5 hours labor.<br>> <br>> So first, compliments to Jon <a ymailto="mailto:jon@jonshouse.co.uk" href="mailto:jon@jonshouse.co.uk">jon@jonshouse.co.uk</a><br>> I'm still not believing eeprom wearout, but<br>> > You may not agree with my justification but its still the logical cure?<br>> appears spot on.<br>> <br>> I followed up with an email asking several questions to try to<br>> get a little more info, but most of them were ignored. All I<br>> learned was that they don't
see many eeprom problems, and<br>> the opinion that it was a defective IC (i.e., infant mortality).<br>> Which, given the scenario, I don't believe.<br>> <br>> Maybe they don't actually track labor for warranty repairs and<br>> that's just nominal, but 1/2 hour to open up the radio, remove<br>> and replace the IC, and close it up seems like it would be more<br>> performance art than tech work. Adding any kind of eeprom<br>> formatting beyond what the radio reset itself does seems unlikely.<br>> But I didn't get an answer to that as well as a number of other<br>> questions I asked.<br>> <br>> ==========<br>> > On Mar 25, 2014, at 7:48 PM, Dan Smith - <a ymailto="mailto:dsmith@danplanet.com" href="mailto:dsmith@danplanet.com">dsmith@danplanet.com</a> wrote:<br>> >> If I were you, I'd modify the driver to check the checksum after<br>> >> download, and then do a bunch of downloads of a good radio
with the<br>> >> original cable and see if they occasionally don't match.<br>> > <br>> > Excellent idea, and I will do that. ...<br>> > <br>> > I might also implement an optional check for a couple of bits in the image<br>> > being set. ...<br>> <br>> Without knowing what cause<br>> d two eeproms to fail, I've reversed my<br><br>I also said<br>"this might change enough data in eeprom to unblock the firmware from<br>whatever endless loop its crashed into - but like I said personally I<br>would unsolder it and put a new chip down !"<br><br>IE I was saying its just as possible the rogue values crash the<br>firmware, but as you cant reprogram the EEPROM without the firmware so<br>you still have remove the EEPROM or clock new values into it to fix the<br>problem. It is possible to clock SPI into the IC without removing it,<br>but that is even more tricky than just replacing it.<br><br><br>> opinion
again on the old cable. I don't know how, but maybe there's<br>> an electrical problem that might manifest itself on read. I'm curious,<br>> but not enough to risk another radio. The new cable is doing downloads<br>> and I think I'll just move forward with that. If someone wants to borrow<br>> the old cable to try on _their_ FT-60, I'm open to that...<br>> <br>> I did implement the download parity check, and I think that will<br>> be the first bug I request to integrate. I need to spend a little more<br>> time on the chirp developer instructions, which I'd been putting off<br>> while I was having fun in the code itself. Soon...<br>> <br>> I also implemented a check on upload for the "bits of death",<br>> but I can't find a way to make it work as I intended with the<br>> existing upload sequence. By the time I can get control in ft60.py,<br>> the "Cloning ..." window is already open, and opening another<br>>
dialog with that up doesn't work gracefully. I didn't want to<br>> mess with the core upload code that affects all radios by adding<br>> another callback method to the parent class. As I said, OOP is<br>> not my comfort zone.<br>> <br>> So I hardcoded it, controlled by a boolean set to False, so<br>> that tested code can be enabled easily by changing that to<br>> True in the ft60.py code. Shall I put that back along with the<br>> parity check? Or other thoughts on this piece?<br>> <br>> =========<br>> Returning to Jon's advice on replacing the eeprom:<br>> I opened up my old bricked FT-60. From the board layout diagram<br>> in the service manual, I'm pretty certain I've found the eeprom, but<br>> on top of my limitations with soldering smt devices:<br>> <br>> 1) It's down in a hole between the headphone jack, the display,<br>> and a crystal.<br>Yes. It is marked Q1034 on the mask drawing, its an 8 pin
device.<br><br>> <br>> 2) It's marked "456M 41B3 06". Doesn't correspond to any IC<br>> nomenclature google knows about. Nor the Yaesu part number,<br>> which per the service manual is G1093837. So I'm not even<br>> 100% sure I've identified the right IC, although I think I have<br>Hmmmmm ... anything is possible but I would expect it to be marked<br>"AT24C something"<br><br>> .<br>> <br>> I don't think it's prudent to ship that back to Yaesu for (paid)<br>> repair, at least for now. I don't have a real need for a spare HT.<br>> I'll let it marinate for awhile<br>Shame, in surface mount terms this IC isnt small stuff. Anyone local to<br>you who could replace it? I would offer but shipping to and from the UK<br>would cost more than the repair is worth.<br><br>Jon<br><br><br><br>_______________________________________________<br>chirp_devel mailing list<br><a ymailto="mailto:chirp_devel@intrepid.danplanet.com"
href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a><br><a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br><br><br></div> </div> </div> </div></body></html>