I found a small latent problem in the Yaesu FT-857D firmware which could cause the radio to crash and go into a reboot loop when a 4 character or less label was created using the free CHiRP radio programming software. I isolated the problem, the Yaesu FT-8[59]7 driver in CHiRP now works around the problem starting with daily builds around June 27th, 2013.
This blog post just archives the info in case someone else stumbles across the problem either by using an outdated version of CHiRP or writing their own software for manipulating the Yaesu FT-8[59]7 memory. This probably applies to the FT-897(d) as well.
The problem has to do with how the 8 character memory label is padded. The older versions of CHiRP were padding unused characters with 0xFF. An unused memory label defaults to eight bytes of 0xFF on the radio. When a label is created for a memory (channel) on the radio, it is set to 'CH-NNN '. There is no way that I found, from the radio to create a memory label that wasn't space padded. Padding with 0xFF for labels that are 5 characters or more doesn't seem to cause any issues. The corrected version of CHiRP now space pads the label out to 8 characters. I believe G4HFQ's FTbasicMMO, only space pads as well.
Marco Filippi, IZ3GME the primary author of the FT-8[59]7 driver made the change within hours of me reporting the problem. The very next CHiRP build had the fixed version of the driver. The current release of CHiRP, 0.3.1 from April 2013, has the old driver. Until a version later than 0.3.1 is released, you need to download a daily release.
I believe I'm justified in calling this a small bug in the Yaesu firmware, because when the radio accesses the memory with the 0xFF padded label, it goes into a continual reboot cycle with lots of clicking of relays and a beep each time it restarts. From the radio itself, the only way to resolve this is to force a reset which will clear some of the settings and/or memory entries depending upon which reset is used. My opinion is the radio's firmware should be a little more forgiving than this.
Note: if your Yaesu FT-857/897 ever does get stuck in a crash/reboot loop, you can still get into clone mode, and save a copy of the whole set of radio settings and memories before you reset it.
Another thing I learned about the FT-857/FT-897 firmware during all of this is that it is nearly impossible to get a pristine memory image from the radio. The radio has three different types of resets which will clear all memories, some settings, and a "full microprocessor reset" which is supposed to return the radio to all factory settings. However, the way this is implemented, the eeprom isn't really reset to a known default, just select bits are cleared marking all of the memory entries unused. Most of the previous memory channel settings, including the label are still there, which makes things confusing if you were looking for clear, reproduceable state.
(Note: There probably is a way to completely clean the EEPROM to a known, reproduceable state, but you don't want to use it. For some reason, Yaesu's firmware writers included a CAT command which would completely reset the radio including the specific calibration settings that are written into EEPROM for each radio. Unforatunely, it's not that improbable to accidentally trigger this when using the CAT interface a lot, possibly with a baud rate setting mismatch. Every FT-8[59]7 owner should use the service menu to record all of the calibration settings in case they are ever lost. This has been documented on the FT-857 and FT-897 Yahoo group's. There is also a few pieces of software, including a PERL script from 0xdecafbad.com for reading out the calibration settings over the CAT interface using the undocumented CAT peek command.
Hopefully I'll get around to posting and documenting more of the things I've learned about the FT-857d. All of the information is out there, but not necessarily organized to make it easy to find.
References
