Project

General

Profile

Actions

Bug #8283

closed

FT-8800 Bricked after programming by CHIRP (latest version)

Added by Chris Parker over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
09/29/2020
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
Yaesu FT-8800R
Platform:
Linux
Debug Log:
I read the instructions above:

Description

I had been using CHIRP with my FT-8800, and like others had noticed that the right-side memory banks weren't being programmed properly. I decided to help fix this problem, so I dug into the code and discovered in ft7800.py that both the left and right side radios use the same address for _bankstart, and that this probably is the source of the problem. I tried opening up one of the img files produced by CHIRP to see if I could read them and found that they were just hex files, so I started playing around with CHIRP to create different img files to see where CHIRP saved the data.

It is important to note at this point that I am just running CHIRP and reading image files on my PC, not doing anything with the radio! I have up until now had good success programming an image file of repeaters into my FT-8800 using the normal upload process.

However, to see what actually was happening with the right side banks, I started adding right-side memories to various banks using the radio front panel, and then used CHIRP to read the image off of the radio to see where the radio was storing them. So far so good.

For one of my last tests before trying to change the _bankstart address for the right side radio, I programmed "all" 500 left-side memories (I say "all" because CHIRP only supports the first 500, while the radio actually has 512 regular memories per side). This is the only place where I can think that I have done anything different from before: previously I had only used a few hundred memories, but this time I used all 500. After programming it into the radio I immediately read it back out of the radio.

After having read the file out of the radio, I hit the power button to put the radio back into normal mode. Instead of restarting normally, the radio played the normal 3-tone start-up chime and then nothing. Blank screen. None of the buttons work any more, and I cannot power off the radio. I disconnected the power, but as soon as I re-applied power, the radio did the 3-tone start-up chime and the same blank screen (I did not have to press power to "turn it on", it did this as soon as power was applied).

So, now I have an apparently dead radio and what seems to have killed it was an upload followed by a download by CHIRP. I let the radio sit overnight and it's still dead as of this morning. I have found a couple people reporting similar issues, at least one of them via CHIRP:
https://forums.qrz.com/index.php?threads/yaesu-ft-8800-reset.374973/
https://forums.qrz.com/index.php?threads/yaesu-ft-8800-not-turn-on-or-off.505892/

I cannot stress enough that I DID NOT make any changes to the code of CHIRP throughout this process!

FWIW, the correct _bankstart for the right side radio in ft7800.py should be 0x4e48, but I never got to the point where I was able to try it :(


Related issues

Related to Bug #1965: Yaesu FT-8800R Right Side Memory Banks Not ProgrammingFeedback10/14/2014

Actions
Actions #1

Updated by Bernhard Hailer over 3 years ago

  • Status changed from New to Feedback
  • Model affected changed from FT-8800R to Yaesu FT-8800R

Hello Chris, that's pretty scary. I researched this a bit and found that Chirp isn't alone: RT Systems software (which is distributed by Yaesu for this radio!) seems to also cause this sometimes as well, which means there could be a bug in the firmware of the FT-8800.

https://forums.qrz.com/index.php?threads/yaesu-ft-8800-locked-up-no-display-after-programming-w-adms-software.374924/

There are a few suggested remedies, and I hope it helps.

1) If you're lucky, you could succeed with a factory reset as suggested in the manual. This requires that the display actually goes on after you turned the radio off - which already may be a problem as you described. Power it up with the left V/M key pressed down. If there's a menu, select what you would like to do. Then press Set to execute.
2) (from above link) If all else fails, remove the holdup battery and let it sit for 15 minutes. Reinstall battery, apply power and try a reset.

Let us know what you find.

Actions #2

Updated by Chris Parker over 3 years ago

Thanks, Bernhard. I found that post (and another from a different ham reporting the same issue). I agree that ut isn't limited to CHIRP. Sadly none of the posts have any resolution posted. I looked in the service manual for an internal battery and couldn't find any but I'll have another look tonight. The fact that user accessible memory can result in a bricked radio is HORRIBLE design on Yaesu's part. Even with the "proper' software serial errors can happen easily (loose connection, electrical noise, etc), and the fact that the radio isn't robust to this is insane.

Actions #3

Updated by Bernhard Hailer over 3 years ago

You might want to negotiate with the vendor, if there's no success with the battery (I believe batteries are quite uncommon in more modern rigs, so that route might not work indeed). At the very least they might have input about how to reset that thing.

Actions #4

Updated by Bernhard Hailer over 3 years ago

  • Status changed from Feedback to Closed

Serious issue, but not caused by Chirp.

Actions

Also available in: Atom PDF