41CL Update stops with * in display

[PeterP]

Hi, I have been updating my 41CLs using Sylvain's wonderful clupdate, Bob's excellent simple manual, and Monte's powerful update module.

However the latest one is stopping the FLCHk? (with * in Alpha) with a low tone and a * in the display, but Alpha off.

I've tried to restart from scratch (MMUDIS, MMUCLR, etc) but it still stops. I also tried to run FLUPD with * in Alpha with the same result (low tone, * in the display).

I was checking the update manual, but could not find that type of halting condition.

Will be very grateful for any pointers!

[Sylvain Cote]

Hello Peter,
The high level function FLCHK? that is calling low level functions: CDBIMP first, then FDBCHK? multiple times and CDBEXP at the end.
I need more information, can you post what is displayed on the terminal (PC side), that should gives me where it got stuck.
Sylvain

[Monte Dalrymple]

The symptoms indicate that the YUPS image may be corrupted. Is the keyboard responsive after it stops? If yes, that means that the "*" is being displayed as an error message. The problem is that "*" doesn't appear anywhere in the YUPS error messages, but _is_ in the ALPHA register, so the code must be somehow jumping to the error output without actually writing an error string. What version of YUPS are you using? Have you checked the YCRC of the YUPS image to see if it is corrupted? Have you tried specifying an explicit range for the FLCHK? function? Something like "000>3FF"? If you have an older version of YUPS I would first download the latest version to RAM and then plug in that version instead of the one in Flash and use it. That will shorten the FLCHK? time by using the CPONLY option.

[PeterP]

Ok, here is further data:

1) I re-uploaded YUPS and did a YCRC check, which checked out.

2) I then tried the same thing (* FLCHK?) and got the same problem - low tone, * in the display. It stops with the console showing the first 'KEEP_ALIVE (0x59)

3) If I try to do a limited range search (05F>062 FLCHK?), I get a similar problem - low tone, 05F>062 in the display, console showing the first 'KEEP_ALIVE (0x59)

4) The full console print out is as follows:

Code:


java -jar clupdate-1.1.0.jar --update rom_files_201102.zip /dev/tty.usbserial-FTDHG4FJ7 4800

16:52:00 --update   [fileName: rom_files_201102.zip] [portName: /dev/tty.usbserial-FTDHG4FJ7] [baudRate: 4800]
16:52:00 File       rom_files_201102.zip loading ... done
16:52:01 Serial     /dev/tty.usbserial-FTDHG4FJ7 opened at 4800 baud.
16:52:01 Waiting    for 41CL commands ...
16:52:13 Received   OPEN_CHANNEL_REQUEST(0x41)
16:52:13 Sent       OPEN_CHANNEL_RESPONSE(0x42)
16:52:31 Received   FLDB_8MB_IMPORT_REQUEST(0x47) [Page: 0x0DE] [BoardGeneration: third] [EstimatedFullScan: 02h 51m 18s]
16:52:31 File       [FileName: FLDB.ROM] [YCRC:0x11022020] [Rev: 2020-11-02]
16:52:31 Sending    8192 = 8192 bytes sent
16:52:48 Received   KEEP_ALIVE(0x59)

I am fairly certain this is PEBCAK, I just haven't figured out what exactly and would love your help!

[Sylvain Cote]

Peter,

From the PC side everything looks ok ...

• the communication with the 41CL is working
• channel has been opened → CMOPEN / OPEN_CHANNEL_REQUEST(0x41)
• FLCHK? is importing the correlation database → CDBIMP / FLDB_8MB_IMPORT_REQUEST(0x47)
• FLCHK? is doing its first rom check → FDBCHK? / KEEP_ALIVE(0x59)
  

So right now, the problem seem to be occurring in the 41CL.

What is your YUPS version ? (latest version is UPDAT 4D)

Code:

CAT 2

Basic fallback setup is:

Code:

MMUDIS
MMUCLR
"YFNX"
PLUG1L
"YUPS"
PLUG1U
MMUEN

PS: if you have loaded YUPS in RAM then you need to ajust the above setup to use the RAM version.

Just to be sure, the normal update procedure on the 41CL is:

Code:

CMOPEN                 // open communication channel
CPONLY                 // new in UPDAT 4x, bypass the byte-by-byte Flash scanning, lots faster
"*" or "start>end"     // Flash range to check
FLCHK?                 // import CDB file, do the flash scanning, export CDB file
FLUPD                  // update outdated ROMs
CMCLOSE                // close communication channel
CDBDEL                 // erase CDB page

Right now, you're process stops at the FDBCHK? execution (called by FLCHK?).

What is your CDB version ? (after FLCHK? is failing)

Code:

CDBVER?

Sylvain

[Monte Dalrymple]

FLCHK? is aborting because it has detected a Low Battery condition. It then reports how much of the check is remaining. Sorry, I forgot about this feature. The Low Battery check inside the function does not set the annunciator, relying on the OS to do that after the function exits. The batteries have probably recovered by then. The serial transfer is what strained them. If the batteries are okay, then it's the battery connection.

[PeterP]

Ah!! That now makes perfect sense.

The BAT annunciator is lit up, but I am ignoring it given that I am using Diego’s USB plug to power the calc!

Okay, maybe the usb port is getting strained or the cable is dirty. Let me try to isolate , but that now makes perfect sense. Always one more feature that Monte packs into his code :-)

Thank you for everyone’s help, I will investigate and report back. Thank you so much for everyone’s help so far!!

[Monte Dalrymple]

USB can only supply 5V, so you're already at a disadvantage. If you want, I can tell you exactly which location in YUPS to modify to eliminate the lowbat test. Just copy YUPS to RAM, modify, and run the RAM version to live dangerously. The source code is on the CL website, so anybody can figure it out. The LLD? instruction only appears once, in a subroutine that is common to all the functions that check for lowbat.

[twoweims]

I have run into this as well. My solution was to try running the update on USB power alone with the batteries completely removed. I have two CLs and I have done three updates on each of them like this with no failures.

[PeterP]

Thanks to everyone's help my CL is up to date again. I kept the batteries in plus the USB in the hope it would help not fully draining the batteries and the update went without a hitch.

Everything happy in CL land again :-)

Thank you! (Until the next time)

[cdmackay]

OT…

(12-19-2020 07:07 PM)Sylvain Cote Wrote:  Just to be sure, the normal update procedure on the 41CL is:

Code:

CMOPEN                 // open communication channel
CPONLY                 // new in UPDAT 4x, bypass the byte-by-byte Flash scanning, lots faster
"*" or "start>end"     // Flash range to check
FLCHK?                 // import CDB file, do the flash scanning, export CDB file
FLUPD                  // update outdated ROMs
CMCLOSE                // close communication channel
CDBDEL                 // erase CDB page

My notes have AUTOVFY before the FLUPD; is that a good idea?


hmm, I don't have CDBDEL in my notes; need to look into that, thanks Sylvain.

[Monte Dalrymple]

AUTOVFY isn't really necessary, because the serial comm is usually quite reliable. I made it mandatory for the OS sector because I am paranoid about bricking the calculator. Once the feature was available there, I decided to make it available everywhere as an option. The CDBDEL is also not mandatory, but I prefer to delete information like that so that there is no question about stale data the next time the code runs. The FLUPD function automatically deletes the code that it writes to RAM and executes while doing the Flash writes, but doesn't touch the CFLDB in case it aborts early.

[Sylvain Cote]

(12-21-2020 09:00 PM)cdmackay Wrote:  hmm, I don't have CDBDEL in my notes; need to look into that, thanks Sylvain.

As Monte said, CDBDEL is optional.

This is my normal ultra-cautious procedure:

Code:

CMOPEN                 //           open communication channel
CPONLY                 // optional: speedup scanning by several order of magnitude
"*" or "start>end"     //           Flash range to check
FLCHK?                 //           import CDB file, scan flash for outdated ROMs, export updated CDB page, the PC should say → Summary: YYY outdated of XXX ROM images
FLUPD                  //           update outdated ROMs
CDBEXP                 // optional: export updated CDB page, the PC should say → Summary: 0 outdated of XXX ROM images
CMCLOSE                //           close communication channel
CDBDEL                 // optional: erase CDB page

[cdmackay]

thanks both, that's very clear.