29 Sep
2023
29 Sep
'23
2:16 p.m.
Before heading to some short vacation first of all: Thanks to all contributers!
I built an adapter for reading the NVRAMs in my programmers (CE2 pulled to VCC using a
resistor, pin 1 isolated) - this adapter us usable for both the DS1643 and the DS1553. The
TopMax2 software has got a bug - it reads 1643 only as 4k device so I read all NVRAMs
selecting the DS1225 using my Galep-III (software Galep32) and my TopMax2.
Results: (1) The contents of the 1643s (unmodified from UltraBooks) showed varying content
with lot of 55 and AA as in Santo's dump above. Writing to NVRAM is of course not
persistent.
(2) The contents of my modified 1553 (from UltraBookIIi with the external battery
attached) are stable (so the battery works) but the content is ramdom. The oscillator is
stopped hence no update of the clock. After starting that in the UltraBookIIi the clock
still is stopped, so the device is in its factory-fresh mode and the firmware does not
start clock. I can write the data section and any modification is persistent (again: the
external battery works).
After my vacation I will zero the RAM, start the clock, set reasonable values for the
watchdog and hostid and give it a new try. The problems to be solved before: The TopMax2
just died and the Galep-III can not write the configuration section - it writes all bytes
in one run and than does a verify, but to write the upper 16 bytes first the write bit
needs to be set, than data should be written and it gets latched only in clearing the
write bit again. That process simply is not present in the Galep32 software because the
device gets powered down before verify :-(
Stay tuned...