Re: [chirp_devel] How to brick an FT-60
On Mar 23, 2014, at 7:13 AM, Jens J. - kd4tjx@yahoo.com wrote:
Did you say that although the radio appears unresponsive, will it still "act" as if it will clone? If so, will it upload or download, or both?
Multiple attempts at both upload and download time out. Download after several seconds, upload immediately.
I have put it into clone mode enough times that I don't need a display to do it, it's almost muscle memory. The radio shows no indication of response, either in the display or to chirp.
Also, Will it visibly go into alignment mode? To enter the Alignment mode: • Press and hold in the MONI and LAMP switches turn- ing the radio on. Once the radio is on, release these two switches. • Press the keypad in the following sequence: [(MHz)] [0( )SET] [1(SQ TYP)] [7(P1)] [V/M(PRI)] • Press the [F/W] key to cause “A0 REF.xxx” to appear on the display for five seconds, this signifies that the trans- ceiver is now in the “Alignment Mode.”
Nope, no indication of anything in response to several repetitions of this sequence. The backlight remains on, display blank.
... I would be curious to examine your "bad" image vs a previous "good" image, vs even one you might have taken much, much earlier in your development process. Can you share them privately with me directly off-list?
I can provide the "bad" image and one dumped a couple of hours earlier. What I can't say for sure is that uploading the one from a little earlier wouldn't brick it also. The mapping process didn't do very much in the way of uploads, it was mostly twiddle settings, download and diff.
Earlier in the day Mar 22, when this happened, I had been going back on a verification pass, and there were some images before Set item 11 CW WRT that I had uploaded, button-tweaked, downloaded and diffed. It will take me a little time to reconstruct that; it's possible I can identify a file downloaded a little earlier than the BrickMaker.img on Feb 7 that I uploaded March 22 without bricking the radio. Let me work on that.
For now, here's the diff between the BrickMaker and the image created immediately previously on Feb 7, which was for Item 7, BELL, setting it to 'Cont'. Hope this works, I had to use a fixed width font and that required using RTF for this mail; I hope it's not mangled.
-0024 x0018: 12 02 00 00 00 01 00 07 ........ +0024 x0018: 12 02 00 00 00 01 00 0b ........ ^
-0048 x0030: 05 01 04 2e 04 2e 03 00 ........ +0048 x0030: 00 01 04 2e 04 2e 03 00 ........ ^
-0536 x0218: ff ff ff ff ff ff ff ff ........ +0536 x0218: 0a 0b 0c 0c 0b 0b ff ff ........ ^^ ^^ ^^ ^^ ^^ ^^
-28616 x6FC8: 4d 00 00 00 00 00 00 00 M....... +28616 x6FC8: 95 00 00 00 00 00 00 00 ........ ^^ ^
Byte 31 is the "Set Item Number" saved in nonvolatile flash, 7 vs 11. Byte 48 ls 3 bits is the 'Cont' value for BELL. The string starting at 536 is the CW WRT value I keyed in, "ABCCBB". 28616 is the checksum. Pretty innocuous looking eh? But I can't say with any confidence that uploading the other image wouldn't brick it as well.
I could supply images I have successfully uploaded, including immediately prior to bricking the second radio with the same image that bricked the first. But the diffs would be mind-numbing, they were 'operational' configs unrelated to this development work.
Let me see what I can come up with.
-dan
Now that a build is available incorporating the changes I submitted in April, so I don't feel like I'm trying to hit a moving target, my intention is to move forward with the FT-60 feature settings memory map project I started on several months ago.
I have some extensions to the developer's tools I've added to make that easier for me, and I expect probably at least some would be useful to others. I've been hacking them in to whatever source base I'm working with, and was about to again, but I think it's time to see if I can just get them into the main codebase once and for all.
Pretty much ready to go, and stable for several months. But I don't want to open a bug if this will be received negatively. In almost all cases, default behavior is unchanged, and where it's not, the differences are trivial and benign. Here's the feature list:
==================== Changed the title of the hex dump window from "Differences" to a string similar to the one printed to debug.log, showing the two file names and memory numbers. Cleaned up an unmatched trailing ')' in that print in the process of making this change.
Added a feature to display _only_ different lines in the hex dump, controlled by setting the first memory # to -2.
Added some help text to the "Diff Radios" dialog explaining the hex dumps available with mem # = -1 and -2.
Added user control of the font size for both the hex dump and the Browser (separately). Controlled by new chirp.config integer properties diff_fontsize and browser_fontsize in new [developer] section. Defaults are unchanged at 11 and 10, respectively.
Added hexdump_addrfmt string property to the [developer] section accepting values of hex, decimal, and both. The default remains decimal.
Added diff_charflag boolean property to the [developer] section. When True, an additional line is printed after each pair of -/+ diff lines, with a '^' in each character position, other than the first, where the lines are different, blank otherwise. Default is False.
Added hexdump_linesize integer property to the [developer] section accepting values of 8 and 16. The default remains 8.
Added an extra " " between every group of 4 bytes in the hex dump. ==================== The source changes aren't extensive, but they're spread over 4 files: common.py mainapp.py radiobrowser.py util.py
Shall I move forward with this?
-dan
I'm not sure I understand everything you're suggesting. If you have already implemented this, can send the changes in patch format so I can try them myself?
Most of the time, I like having full context in the memory diff. It's not like it's very long. I don't understand why a negative channel number was chosen to enable this feature. Wouldn't a checkbox be more appropriate?
Can you read the font size from the operating system default? I think this is the appropriate way to do it, but I don't know specifics. Ability to override this is reasonable, but maybe the problem is that you have your OS configured the way you like and Chirp isn't honoring it. That sounds more critical than implementing a font size override.
These sound like a number of small, atomic features. Each distinct feature should be its own patch and we can discuss it independently if needed. If one feature is dependent on another, just make sure the order of your patches is appropriate.
Tom KD7LXL
On Tue, Jun 3, 2014 at 8:21 PM, chirp.cordless@xoxy.net wrote:
Now that a build is available incorporating the changes I submitted in April, so I don't feel like I'm trying to hit a moving target, my intention is to move forward with the FT-60 feature settings memory map project I started on several months ago.
I have some extensions to the developer's tools I've added to make that easier for me, and I expect probably at least some would be useful to others. I've been hacking them in to whatever source base I'm working with, and was about to again, but I think it's time to see if I can just get them into the main codebase once and for all.
Pretty much ready to go, and stable for several months. But I don't want to open a bug if this will be received negatively. In almost all cases, default behavior is unchanged, and where it's not, the differences are trivial and benign. Here's the feature list:
==================== Changed the title of the hex dump window from "Differences" to a string similar to the one printed to debug.log, showing the two file names and memory numbers. Cleaned up an unmatched trailing ')' in that print in the process of making this change.
Added a feature to display _only_ different lines in the hex dump, controlled by setting the first memory # to -2.
Added some help text to the "Diff Radios" dialog explaining the hex dumps available with mem # = -1 and -2.
Added user control of the font size for both the hex dump and the Browser (separately). Controlled by new chirp.config integer properties diff_fontsize and browser_fontsize in new [developer] section. Defaults are unchanged at 11 and 10, respectively.
Added hexdump_addrfmt string property to the [developer] section accepting values of hex, decimal, and both. The default remains decimal.
Added diff_charflag boolean property to the [developer] section. When True, an additional line is printed after each pair of -/+ diff lines, with a '^' in each character position, other than the first, where the lines are different, blank otherwise. Default is False.
Added hexdump_linesize integer property to the [developer] section accepting values of 8 and 16. The default remains 8.
Added an extra " " between every group of 4 bytes in the hex dump.
The source changes aren't extensive, but they're spread over 4 files: common.py mainapp.py radiobrowser.py util.py
Shall I move forward with this?
-dan
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
These sound like a number of small, atomic features. Each distinct feature should be its own patch and we can discuss it independently if needed. If one feature is dependent on another, just make sure the order of your patches is appropriate.
Agreed :)
--Dan
participants (3)
-
chirp.cordless＠xoxy.net -
Dan Smith -
Tom Hayward