41CL Update stops with * in display
|
12-18-2020, 10:50 PM
Post: #1
|
|||
|
|||
41CL Update stops with * in display
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! Cheers, PeterP |
|||
12-18-2020, 11:56 PM
(This post was last modified: 12-18-2020 11:58 PM by Sylvain Cote.)
Post: #2
|
|||
|
|||
RE: 41CL Update stops with * in display
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 |
|||
12-19-2020, 12:40 AM
Post: #3
|
|||
|
|||
RE: 41CL Update stops with * in display
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.
|
|||
12-19-2020, 03:56 PM
Post: #4
|
|||
|
|||
RE: 41CL Update stops with * in display
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:
I am fairly certain this is PEBCAK, I just haven't figured out what exactly and would love your help! Cheers, PeterP |
|||
12-19-2020, 07:07 PM
(This post was last modified: 12-19-2020 07:12 PM by Sylvain Cote.)
Post: #5
|
|||
|
|||
RE: 41CL Update stops with * in display
Peter,
From the PC side everything looks ok ...
What is your YUPS version ? (latest version is UPDAT 4D) Code: CAT 2 Basic fallback setup is: Code: MMUDIS Just to be sure, the normal update procedure on the 41CL is: Code: CMOPEN // open communication channel 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 |
|||
12-19-2020, 07:46 PM
Post: #6
|
|||
|
|||
RE: 41CL Update stops with * in display
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.
|
|||
12-19-2020, 08:15 PM
Post: #7
|
|||
|
|||
RE: 41CL Update stops with * in display
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!! Cheers, PeterP |
|||
12-19-2020, 09:27 PM
Post: #8
|
|||
|
|||
RE: 41CL Update stops with * in display
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.
|
|||
12-20-2020, 03:02 AM
Post: #9
|
|||
|
|||
RE: 41CL Update stops with * in display
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.
My Collection: 55, 67T, 25PLP, 34C, 15C, 16C, 41CV, 41CX, 41-CL, DM41X, DM42, 42S, 48G, 71B, 75C, 95LX, HP-150, Portable+, HP-86, Integral PC. |
|||
12-20-2020, 02:59 PM
Post: #10
|
|||
|
|||
RE: 41CL Update stops with * in display
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) Cheers, PeterP |
|||
12-21-2020, 09:00 PM
Post: #11
|
|||
|
|||
RE: 41CL Update stops with * in display
OT…
(12-19-2020 07:07 PM)Sylvain Cote Wrote: Just to be sure, the normal update procedure on the 41CL is: 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. Cambridge, UK 41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot/C47 Casio, Rockwell 18R |
|||
12-21-2020, 09:50 PM
Post: #12
|
|||
|
|||
RE: 41CL Update stops with * in display
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.
|
|||
12-22-2020, 12:28 AM
Post: #13
|
|||
|
|||
RE: 41CL Update stops with * in display
(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 |
|||
12-22-2020, 07:39 PM
Post: #14
|
|||
|
|||
RE: 41CL Update stops with * in display
thanks both, that's very clear.
Cambridge, UK 41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot/C47 Casio, Rockwell 18R |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: