CHIRP

Some additional information from some additional testing: I haven't completely narrowed it down yet, because I've gotten some results that aren't as reliably repeatable:

1 - Copying the memory and writing it to the radio without editing it with chirp will reproduce the problem.
2 - Editing the problematic memory with CHiRP (even just changing the label) will "fix" the problem.
3 - This may have to do with the previous contents of the memory, as there were times where I copied the bad memory to a new location and the new location did not show the same problem.

Also an FYI for working with a FT-857 that gets stuck in a crash/restart loop: While the radio is resetting itself, it is still possible to put it into clone mode by holding down the normal keys [<] + [>]. That way the memory contents can be downloaded and examined. (Also memories / settings could possibly be retained at least for viewing through chirp.)

Clarification on the image I posted - There are 4 active memories, 1,2,3, and 5.

Memory locations 2 and 3 will cause the problem, Memory location 5 is OK -- it was edited to change the label so it fixed the problem.

I will post a new memory image with a memory entry made on the radio for comparison.

Ok, I believe I've found the answer and it's a (latent) bug in the radio. A memory label of 4 characters or less will cause the radio to crash when accessing that memory. This is on a FT-857D, manufactured in 2012. The default label the radio creates is 6 characters long CH-NNN, so there is probably never a case where it is possible to create a label on the radio with 0xFF's starting at a position less than the 7th character.

Most likely a work around should be added to Chirp to space pad labels to a minimum of 5 or 6 characters.

Ok, I've tested the latest (3rd) patch. It successfully pads the 8 character label to spaces
thus avoiding the problem with the 0xff padding that causes the radio to crash.

Note: If no label is entered, it will also fill the contents with 8 spaces
overwriting what ever was there which I think should be fine. I did check the
radio still displays the frequency if there is no tag. (I believe it
overwrote before, though it wrote 0xff so it looked like uninitialized memory.)