[41CL] updating OS modules

[Monte Dalrymple]

(03-26-2021 12:26 AM)cdmackay Wrote:  thank you Sylvain.

That didn't work: step 6 resulted (as before) in 0 outdated files. I think that is because FLCHK?(CPONLY) compares the in-flash old FLDB with the new CFLDB downloaded from clupdate. But my in-flash FLDB isn't old: it was updated earlier today when I updated the non-OS pages. So the checksums in my in-flash FLDB match the CFLDB from clupdate, even for the OS pages. But the actual OS pages' content doesn't match my in-flash FLDB.

Here's what I did instead, which appears to have worked:

# switch OFF/ON, to clear CPONLY

XEQ ON
XEQ CMOPEN
ALPHA 000>007 ALPHA # only OS pages
XEQ FLCHK? # CPONLY not set, so a real CRC check

# clupdate shows four outdated OS pages

XEQ AUTOVFY
ALPHA 000>007 ALPHA # only OS pages
XEQ FLUPD

# clupdate sends the four pages

XEQ CMCLOSE


and I now get the correct YCRC checksums for pages 0, 2, 6 & 7.


thanks very much, Sylvain.

Yes, this is what you need to do to correct the problem. (Except the AUTOVFY is not necessary, because it is always done automatically for the OS sector.) This is the potential problem that can happen when using the CPONLY option: The FLDB says everything is up-to-date, when if fact it is not. This can also happen if the update aborts after updating the FLDB because of low battery, leaving some higher pages stale. If this ever happens the CFLDB will still correctly reflect the state of the Flash so the update can be run again after executing OSUPDT. But it has to be done immediately to make sure that the CFLDB doesn't get corrupted. After an update you can always to a CDBEXP to make sure that the CFLDB shows that all pages got updated. The update function clears out the "stale" flags in the CFLDB as it updates sectors so that it is current at the end of the update function.