41CL backup CDB via serial?

[cdmackay]

hi all,

I may have to do some hardware work on my 41CL, which is obviously going to entail loss of RAM.

Is it possible to save my correlated CDB image via serial, to avoid the 3-hour CRC checking of pages by FLCHK? at my next update? i.e. with all valid bits intact so that I can still use CPONLY?

I noticed that I have a CFLDB.ROM file in the directory when I ran clupdate; is that in fact an already backed-up copy of my CDB from FLCHK? If so, how would I restore it after a RAM loss? Or does that not preserve the per-page valid bit?

thanks very much indeed.

[Monte Dalrymple]

(04-07-2019 05:24 PM)cdmackay Wrote:  hi all,

I may have to do some hardware work on my 41CL, which is obviously going to entail loss of RAM.

Is it possible to save my correlated CDB image via serial, to avoid the 3-hour CRC checking of pages by FLCHK? at my next update? i.e. with all valid bits intact so that I can still use CPONLY?

I noticed that I have a CFLDB.ROM file in the directory when I ran clupdate; is that in fact an already backed-up copy of my CDB from FLCHK? If so, how would I restore it after a RAM loss? Or does that not preserve the per-page valid bit?

thanks very much indeed.

The CFLDB image that appears in the directory where clupdate resides is the one transferred to the clupdate program during FLCHK? It contains the information on which pages need updating. This is the source of the report that clupdate generates showing the number of pages requiring an update. During the FLUPD process, the CFLDB that resides on the 41CL is updated as each sector is written, so that at the end of the update if you inspected it you would find that all of the updated pages were now marked as unverified.

Normally the CFLDB does not need to be retained after an update completes. The only real use for the information it contains is during the update process. So it is nice to have if the update is aborted for some reason, but that is all.

Once an update completes properly, the FLDB in Flash memory corresponds to the contents of the Flash and the next update does not need to bother with calculating the CRC on every page. This is why I added the CPONLY option. If you start messing with the contents of Flash, then all bets are off and you should probably run the FLCHK? in the normal mode.

Hope this helps.
Monte

[cdmackay]

Thanks very much Monte; for some reason I thought that the CPONLY mechanism in particular relied upon the correlated DB in RAM, and thus if I lost RAM I wouldn't be able to use CPONLY next time.

Sounds like you're saying I will be able to use CPONLY, as long as my flash remains intact, i.e. the FLDB is correct, regardless of whether RAM has lost power in the meantime?

That's even better, if so

thanks very much.

[Monte Dalrymple]

(04-08-2019 10:19 AM)cdmackay Wrote:  Thanks very much Monte; for some reason I thought that the CPONLY mechanism in particular relied upon the correlated DB in RAM, and thus if I lost RAM I wouldn't be able to use CPONLY next time.

Sounds like you're saying I will be able to use CPONLY, as long as my flash remains intact, i.e. the FLDB is correct, regardless of whether RAM has lost power in the meantime?

That's even better, if so

thanks very much.

Yes, in the CPONLY mode the check is between the contents of the FLDB in FLash and the FLDB that is uploaded from the clupdate program. The results of these comparisons creates the CFLDB (by modifying the uploaded FLDB) which is then returned to the clupdate program.

[cdmackay]

marvellous! thanks again Monte.