Hi Hostile,
I have a 271 with an vague history. It arrived with what appeared to be the battery failure memory loss - plenty of 6's on the display, changing with FM/USB mode selection. However, the battery tests OK. Further information from the previous owner indicates that the display had gone dark at one point and he had found a few bad solder joints and had touched them up. He did not change the battery, so why the memory was lost I'm not sure. Anyway, I decided the best place to start would be with the memory fix so I could then eliminate that as a problem.
With that plan in mind, I built the board in your photo and attempted to reprogram the board with RAM_03 uncommented (V0.2, using a UNO - I saw you comments related to the later version and gave it a swerve). Before I did that though, I dumped the existing data from the board just to see what was in it. I've attached that here as Old Dump.txt. As expected, it doesn't contain much that looks useful.
When I attempted the program function, it wrote, but the verify pass failed. The failure lines are attached as Verify Fail.txt. I then dumped what was now in memory and have attached that as New Dump.txt. For anyone following along, the file should look like Sketch RAM_03.txt, also attached. I tried this a few times, because, why not... ;-)
I don't know much about how this programming procedure works and I'm only able to get a simple understanding of the sketch code you wrote. My minimal coding experience was 40 years ago, with Pascal and PL1, so definitely not strong on this Arduino stuff.
Looking at the dump data, it appears that the process did something, but I only see combinations of 0, 1 and 9's. No F or 5 or 4's or any of the other digits that appear in RAM_03 (CORRECTION - see NOTE 2 below). Any idea what this should be telling me? Is this a wiring problem with my board? An issue with Arduino UNO being used rather than the more complex board you were working with? Or is there a problem with the chip that's supposed to store the data?
Any suggestions of where I should go next would be greatly appreciated!
Brock VA7AV
EDIT: I just noticed that the number of fails varies slightly with the program attempts. I've seen 373, 374 and 375. Verify always agrees though, if I run it multiple times. So perhaps a write issue of some sort? Timing with an UNO?
EDIT 2: I've tried multiple program attempts and have compared the dump results with the desired results. I'm seeing incorrect values still, but they appear to be specifically incorrect. That is, if I should see 0xFF I'm instead getting 0xDD. Note that my previous comment about never seeing some numbers is now contradicted - after several attempts some other values are showing up. It really seems like some values simply aren't being incremented high enough, as my values are either right, or too low. But again, I don't know how this stuff actually gets written. Could this be a UNO issue?
Updated 8/21/22
updated RAM14 array size
Updated 8/20/22
Now includes all of the memory dumps from Original_icom_ram_multi_format archive from this topic.
Expanded on Randman80 Arduino code. Thanks
Used on IC-745
Made it easier for myself to follow, others may disagree.
Select the RAM to be programed from the #defines in header
Changed the pins to re-definable constants at beginning of code.
- Change these to match how you jumper the Arduino to J1, J2
Changed the WR CS timing to help avoid clashes.
added dumping of memory and verification.
use the Arduino console with 115200bps.
commands are single letters with enter
p, programs, reads, verifies
d, prints memory to console
v, verifies last dumped memory
c, clone memory, requires hot-plugging ram module with Arduino on
There is a custom slot for the RAM defines. you can dump memory and copy paste it there, to do many clones without hotswapping