41CL UPDATING PROBLEMS

[Podalirius]

Hi, I tried to update my 41CL V5 with the clupdate program.
I started it from my Xubuntu computer with:
java -jar clupdate-1.1.0.jar --update ~/tmp/rom_files_180927.zip /dev/ttyS0 4800.
On the 41CL I typed the command XEQ "CMOPEN"
The 41CL display COMM, and after TIME OUT.
Some technical data for those try to help me:
I connected 41CL to the PC via the original cable to a real serial port,
that on my system is /dev/ttyS0. I know the port is working because I use
it also to connect my hp 95LX + dockstation via Kermit.
The Xubuntu version is 18.04
My 41CL runs now rom_file_180706.zip
On the 41CL I installed the YUPS module, and with CAT 2
I can read UPDAT 3B.
I used very fresh recharged batteries.
Of course I made the rom_file_180927.zip present in the ~/tmp directory.
After this tray, ALL MMU configuration of the 41CL is LOST!!!
I reinstalled my MMU config and repested the tray many times without
difference: 41CL TIME OUT plus MMU config LOST.
I thank you so much for all, very appreciated, help!!!

[Sylvain Cote]

Are you sure about the rom_files_180927.zip file ?

I do not see a release file with that name, this is what was released by Monte in September:

Code:

rom_files_180928.zip 
rom_files_180925.zip 
rom_files_180924.zip 
rom_files_180922.zip 
rom_files_180912.zip

I would suggest to use the latest file here: rom_files_180928.zip

When you type:

Code:

java -jar clupdate-1.1.0.jar --update ~/tmp/rom_files_180928.zip /dev/ttyS0 4800

You should see the following:

Code:

HH:MM:SS --update   [fileName: ~/tmp/rom_files_180928.zip] [portName: /dev/ttyS0] [baudRate: 4800]
HH:MM:SS File       ~/tmp/rom_files_180928.zip loading ... done
HH:MM:SS Serial     /dev/ttyS0 opened at 4800 baud.
HH:MM:SS Waiting    for 41CL commands ...

Sylvain

PS: I am leaving Montreal (Canada) for Basel (Switzerland) later today, so I will be offline for at least a day.

[Podalirius]

Hi, I am sorry, it is only a taping mistake, I used rom_file_180928.zip.
I read all messages from clupdate as you write me.
The problem is when I tap on 41CL the first command for
update procedure: XEQ "CMOPEN".
It return "COMM" on display, and after a bit "TIME OUT".
The problem I think is in the moment on 41CL and PC have
to make a connection between them, because 41CL turns on
TIME OUT and PC remain in waiting for 41CL commands.
Thank you very much.

[burkhard]

(11-01-2018 07:57 AM)Podalirius Wrote:  On the 41CL I typed the command XEQ "CMOPEN"
The 41CL display COMM, and after TIME OUT.

It sounds like you run into trouble at the 41CL end itself with that timeout occurring, before you even started trying to talk to the PC host.

I tried repeating your steps. I plugged in YUPS and then issued XEQ "CMOPEN" exactly as you describe above. Indeed I had a similar problem on my v5 41CL. The TIMEOUT occured quickly (within a few seconds) and it disabled the MMU. The MMU wasn't cleared, though. It seemed that merely issuing command MMUEN brought it back—I did not need to recall the saved config from Alternate Memory or manually rebuild the MMU.

But anyhow...

I think your problem is that you are issuing CMOPEN without having first initializing the port with SERINI. I tried that first and no crash. So please try that.

One more thing, though: SERINI sets the baud rate to 1200 by default, so after SERINI, but before CMOPEN you also need a BAUD48 to set things to 4800.

So try:
XEQ SERINI
XEQ BAUD48
XED CMOPEN

[Sylvain Cote]

(11-01-2018 01:43 PM)burkhard Wrote:  One more thing, though: SERINI sets the baud rate to 1200 by default, so after SERINI, but before CMOPEN you also need a BAUD48 to set things to 4800.

The documentation and Monte told me multiple times that CMOPEN initialize the serial port and set the baud to 4800.
So SERINI and BAUD48 should theoretically be not needed, but if it solve your issue, then for sure go ahead and use it.
IMHO, you should contact Monte and tell him about it, so he could fix it.

About MMU deactivation ...

When you plug or unplug the serial connector, I often experience that the MMU is deactivated.
So as a habit, I always do the following: OFF, plug/unplug connector, ON, MMUEN

I also experienced, like you, sometime after a communication error, the MMU is deactivated, when that happens, I just do MMUEN.

Sylvain

PS: thanks Burkhard for stepping in and helping fellow 41CL users

[Podalirius]

Hi, before to try out the Mr. Burkhard opinion, I verified that all my MMU
configuration is correct, with UPDAT 3B present, then I started clupdate
and taped XEQ "SERINI", XEQ "BAUD48" and XEQ "CMOPEN".
Immediately it displayed NONEXISTENT and all MMU is again lost but
thanks to Mr. Sylvain I taped XEQ "MMUEN" and MMU is OK.
Thank you so much for all your help.
I send an email to Mr. Monte.

[Monte Dalrymple]

It sounds like something is wrong with the physical connection between the CL and
the computer. Something similar happened to me once, and I resolved it by
unplugging the serial cable from the CL and plugging it back in. I routinely give the
plug a little twist to wipe the contact area of the plug/jack combination. Make sure
that the plug is fully seated in the jack.

The MMU is disabled whenever the power-on-reset circuit on the CL board is
tripped. The plug/jack used for the serial port is not ideal, and during insertion or
removal it can cause a power supply glitch, which will trip the POR. This disables
the MMU but does not affect the MMU programming in RAM. So, like Sylvain, I
always execute an MMUEN after inserting or removing the serial plug.

The RS232 driver on the CL board will not power up unless it detects a valid level
on the receive data line. This is why CL-CL transfers require special handling, but
if the serial driver on the computer is set up the same way both ends will also just
sit there waiting for a valid level. You can force the CL serial port to turn on by
executing the SERON function that is available in YFNX.

The timeout delay for the CL is about 30 seconds. It sends the CMOPEN byte
and then waits this long before signalling TIMEOUT. If this message appears
much faster than that something funny is going on, but I don't know what.

I have had a serial cable fail before, although it was obvious when it did,
because the the plug broke during insertion. Yes, it tripped the POR and was
a pain to get the broken piece out of the calculator. But this was the cable
that I have been using since the very beginning and the plug is out on my desk
getting banged around all the time.

Have you ever done a serial transfer to/from the CL before? That is one thing
that I am not able to test before I ship, so there is a very remote possibility
of it not working.

But my money is on a bad connection between the plug and the jack on the CL.

[Ángel Martin]

(11-02-2018 03:04 AM)Monte Dalrymple Wrote:  I always execute an MMUEN after inserting or removing the serial plug.

Ditto here, in fact I have MMUEN assigned to a key and hit it when I connect/disconnect the serial cable (always with the calculator OFF!).

If the MMU was disabled the function (from the YFNZ ROM) enables it back. If the MMU was already enabled the same XROM code corresponds to MMU? in the YFNX module, thus it just says "YES".

Fortuitously convenient or a superb touch of the design, pick your choice ;-)