[41CL] updating OS modules

[cdmackay]

i ran into an oddity this evening, updating my 41CL to the 03/03/2021 images.

These contain updates for some of the OS modules, which I don't think I've had before.

I hadn't run OSUPDT on the 41CL, so OS module updates were not enabled.

That meant that clupdate only updated 12 of my 16 outdated images, and finished with:

17:11:21 Report Outdated ROM images [BoardGeneration: third]
17:11:21 Report NUT0-O.ROM [Page:0x000 ID:OS41 Rev: YCRC:0x7BA02836]
17:11:21 Report NUT2-M.ROM [Page:0x002 ID:OS41 Rev: YCRC:0x0C2B5718]
17:11:21 Report TIME-3B.ROM [Page:0x006 ID:TMOD Rev: YCRC:0x661E8616]
17:11:21 Report YFNZ-4G.ROM [Page:0x007 ID:YFNZ Rev: YCRC:0xACE0E4DE]
17:11:21 Report 4 outdated pages, out of 1024 pages, spread over 1 Flash blocks, estimated update time: 00h 03m 59s

Having done that, I later thought I would run clupdate again, and this time run OSUPDT before FLUPD on the 41CL, to update those four OS modules.

However, when I run clupdate, it now reports:

19:52:21 Report 0 outdated pages, out of 1024 pages, spread over 0 Flash blocks, estimated update time: 00h 00m 00s

I've re-rerun FLCHK?(CPONLY), and also tried CDBDEL, but neither made a difference.


It's not a big deal, of course, but I'm wondering if I did something wrong?

[Sylvain Cote]

It seems that first Flash 64KB sector has been updated.

Let's check this, load the YFNX module in a free page. (41CL Extreme Functions set)

Then enter in alpha "000" then execute YCRC
If it is updated you should see "7BA02836" on the screen, if not, you will see the old CRC.

"000" YCRC shows "WORKING" then show "7BA02836" if up to date.

Do the same for the other as well ..

"002" YCRC shows "WORKING" then show "0C2B5718" if up to date.
"006" YCRC shows "WORKING" then show "661E8616" if up to date.
"007" YCRC shows "WORKING" then show "ACE0E4DE" if up to date.

Let me know what you get.

Sylvain

edit: typos.

[cdmackay]

thanks Sylvain.

from my 41CL I get:

000 dbe7a58c
002 5b1c1c70
006 59097a6d
007 3650ef10

and if I clupdate --list rom_files_201208.zip — my previous update — I get the same values.

I think that shows that my 41CL did not have its OS pages updated; that makes sense, since I did not execute OSUPDT to enable that.


I wonder: I am using CPONLY to speed up the FLCHK?. I believe that compares checksums from the in-flash FLDB, with the in-RAM CFLDB, is that right?

If so, hasn't my in-flash FLDB been updated, today, when I did the non-OS-page upgrade? Since the FLDB is at 0x0de, and so does not require OSUPDT to be enabled for it to be updated.

So FLCHK?/CPONLY sees the new value for those OS pages, in the in-flash FLDB, and thinks that my 41CL already has them?


If so, do I need to first mark those pages invalid manually, in the CFLDB with PGINV, and then run OSUPDT & FLUPD again?

edit: or I could run FLCHK? again, but without CPONLY set and only for pages 0-7?

[Sylvain Cote]

Perfect, we now know where we are.

Preconditions before doing the procedure:

• Fresh batteries (very important, we are updating the OS sector)
• Serial cable connected on both ends
• clupdate running in update mode on the computer side
• YUPS ROM mapped
• YFNX ROM mapped
• MMU active
  

Now the procedure ...

1. Execute OSPROT to protect the OS space (just in case)
2. Execute CDBDEL to delete the CFLDB ROM image located at RAM page 0x806.
3. Execute CPONLY to enable the compare-only mode
4. Execute CMOPEN to open up the serial port
5. Enter "*" in alpha (without the quotes)
6. Execute FLCHK? to download the FLDB ROM image, scan the entire Flash space and upload the CFLDB ROM image to the computer
   at this point you should see only 4 outdated files in your report, if that is the case then continue with the following ...
7. Execute OSUPDT to unprotect the OS space
8. Execute FLUPD to download and update the OS space ROM images
9. Execute OSPROT to protect the OS space
10. Execute CDBEXP to upload the CFLDB ROM image to the computer and display the updated report
    at this point you should see 0 outdated files in your report, if that is the case then continue with the following ...
11. Enter "000" in alpha (without the quotes) and execute YCRC you should get "7BA02836"
12. Enter "002" in alpha (without the quotes) and execute YCRC you should get "0C2B5718"
13. Enter "006" in alpha (without the quotes) and execute YCRC you should get "661E8616"
14. Enter "007" in alpha (without the quotes) and execute YCRC you should get "ACE0E4DE"
15. Execute CMCLOSE to close down the serial port
    

Sylvain

[cdmackay]

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
XEQ OSUPDT
ALPHA 000>007 ALPHA # only OS pages
XEQ FLUPD

# clupdate sends the four pages

XEQ CMCLOSE
XEQ OSPROT


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


thanks very much, Sylvain.

[Sylvain Cote]

Excellent, great analysis and superb problem solving, I could not have done this better.



edit: found a better image.

[cdmackay]

thank you again Sylvain

[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.

[cdmackay]

thanks Monte, that makes sense.

My mistake was to repeat my entire normal process, including the FLCHK? which of course downloaded a new FLDB from clupdate, overwriting the CFLDB that was, at that time, correct.

Presumably if I'd instead immediately done OSUPDT/FLUPD, without another FLCHK?, it would have worked.

Anyway, it was a good exercise, as now I have a better understanding of what's going on

thanks again both.

[rocket.scientist]

So my basic approach to updating my Hp41CLs has been to use the guidance in the excellent HHC-2017-clupdate presentation. Before I undertake this OS update, how should I modify this process to most safely proceed? I prefer selectively updating the OS modules.

I anticipate it will need only the insertion of OSPROT/OSUPDT commands in the appropriate spots. And that assumption is why I am asking first. :-)

Thanks!

-Pat (KG5YPQ)

[cdmackay]

hi Pat,

If you want to update the OS pages separately, then you could either:


• do as I did above; i.e. update as normal, which won't update the four OS pages, since OSUPDT wasn't executed.

Then, perform the extra steps I note in Post: #5, above, under "Here's what I did instead…"

This would be required if you intend to leave a gap between the non-OS, and OS, page updates.

Or, if you intend to do them one immediately after the other:


• update as normal, which won't update the four OS pages, since OSUPDT wasn't executed. clupdate will tell you that there are still four outdated pages.

Then, without exiting clupdate on the PC, or doing anything else on the 41CL:

XEQ ON
XEQ OSUPDT
XEQ FLUPD

This method should work, as long as you haven't updated the in-RAM CFLDB using FLCHK? If you have restarted clupdate, you may need to first CMOPEN, then CDBEXP, to send the in-RAM CFLDB to the restarted clupdate (at least, in order for clupdate to be able to tell you there are outdates pages; it may not be required for the FLUPD).

You can add OSPROT, to disable OS updates again, but this is done automatically on turning OFF/ON, so I didn't put it in above.


In either case, ensure you have fresh batteries before updating OS pages.

--
Calum
(M0XCM)

[rocket.scientist]

Thanks for the excellent guidance. I updated both of my CLs without significant incident. One CL was recently purchased and already had the latest OS. The other was last updated in November and was a bit more fiddly. It was less of a "thing" than I expected it would be, and I learned a bit more about these marvelous devices.

-Pat (KG5YPQ)