Bug #937
closedFT-857 saved memory causes radio to go into a reset loop
0%
Description
Attached is an image for a Yaesu FT-857D (US version) created with chirp that causes the radio to crash and go into a reset loop when a specific memory is used.
The frequency is 449.325, Tone mode TSQL, 136.5.
The memory entry was originally copied over from a Wouxun, but re-entering the same data into a fresh cell causes the same problem on the radio.
To reproduce.
- download the image.
- Got to memory mode
- Dial up to M-003 or M-005
Chirp version: tip, pulled with hg today.
NOTE: I tried to use as pristine of an image as I could for isolating this. The radio was reset using all three of the available reset types (Home, Func, V/M). Then the image was read, copying over just the one problematic memory.
(However, after reset, I could still see remenants of the old memories in the image file. The memories had be marked as inactive but not cleared by the radio.)
Files
Related issues
Updated by Filippi Marco almost 11 years ago
- Status changed from New to In Progress
- Assignee set to Filippi Marco
- Priority changed from Normal to High
Updated by Robert Terzi almost 11 years ago
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.
Updated by Robert Terzi almost 11 years ago
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.)
Updated by Robert Terzi almost 11 years ago
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.
Updated by Robert Terzi almost 11 years ago
- File bug-937a-2.img bug-937a-2.img added
Attached is a new memory image, bug-937a-2.img
It appears to show the problem is outside of the per channel memory data tracked by CHiRP when doing a show/diff raw memory.
The channels in the image are:
1 - Default created by resetting radio. (7.000 Mhz USB)
2 - Memory created from the front panel of the radio with similar settings (didn't touch step size or power) (449.325 Mhz, TSQL, 136.5 PL)
10 - Bad memory originally copied from a Wouxun that causes the problem.
5 - Same memory as No. 10, but edited with chirp to change the label from "test" to "testOK" which "fixed" the memory.
Chirp's diff raw memory function shows only the label being different by two bytes between the good Channel 5 and the bad channel 10.
Updated by Robert Terzi almost 11 years ago
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.
Updated by Filippi Marco almost 11 years ago
- Status changed from In Progress to Feedback
A patch have been sent to developers list, now waiting for Robert feedback
Updated by Robert Terzi almost 11 years ago
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.)
Updated by Filippi Marco almost 11 years ago
- Status changed from Feedback to Closed
The patch from Bug #857 introduce this one, if it'll be backported this one have to be backported also.