Bug #2505

FT-2900 split tones entered via CHIRP UI can cause lock-ups

Added by Richard Cochran almost 5 years ago.

Status:New Start date:04/06/2015
Priority:Normal Due date:04/06/2015
Assignee:Richard Cochran % Done:

100%

Category:-
Target version:- Estimated time:4.00 hours
Chirp Version:0.4.0 Platform:Windows
Model affected:FT-2900/FT-1900

Description

If you enter a memory into a previously unoccupied memory via the CHIRP UI, and then upload that memory to the radio, then try to use the radio's UI to change the SQLTYPE, it can sometimes lock up the radio, necessitating a hard reset.

The problem appears to be due to a failure to initialize the split flags on the ctone, rtone, dcstone, and rx_dsctone. When these are left uninitialized, they default to 1 (set) for a previously unused memory. The radio normally leaves these flags unset (0), unless a tone->tone or DSC->DCS split is being entered. Fix is to explicitly initialize them always.

This was reported via email from and to me,

Associated revisions

Revision 2544:135494ac7732
Added by Richard Cochran almost 5 years ago

[ft2900] fix lockup issue (#2505)
This fixes an issue where memories entered via the Chirp UI and uploaded
to the radio could sometimes cause lockups if the memory was later edited
in the radio to change its SQLTYPE. The cause was uninitized flags
that could erroneously flag a tone or DCS code as being part of a split
tone. Fix is to initialize the flags to zero -- there was already code
to set them to 1 when needed.

Also available in: Atom PDF