HP41CL Serial Com Port Failure

[Neve]

Greetings everyone,

A few weeks ago I updated my HP41CL’s with the latest rom 220722.zip.
Today I wanted to check something. I plugged in one of the CL’s to the serial cable, as I normally do to update it with Sylvain’s Java program on my Mac. When prompted with «Waiting for 41CL commands», I EXQ CMOPEN on the 41. Except that now it doesn’t link, and I get a timing error.
I tried another CL, and I get the same thing…. No connection to the Mac.
My serial to USB is good and recognized by the à Mac as /dev/ttyusbserial, as it always has…

I don’t understand what’s wrong. Was a bug inadvertently introduced with the latest rom mentioned above?

Thank you for any help anyone can provide.

[Sylvain Cote]

Hello Neve,
With the HHC conference coming soon, meaning I need to finish my presentation ASAP, I am fully booked.
I will send you a PM as soon as I have enough free time to investigate/solve the issue. Sorry about that.
Regards,
Sylvain

PS: in the mean time, if you could post the something similar to the following that would help, thanks.

From System Information application

Code:

Hardware Overview:

  Model Name:    MacBook Pro
  Model Identifier:    MacBookPro15,3
  ...

System Software Overview:

  System Version:    macOS 12.5.1 (21G83)
  Kernel Version:    Darwin 21.6.0
  ...

USB → FT232R USB UART:  (information on your USB-to-Serial dongle)

  Product ID:    0x6001
  Vendor ID:    0x0403  (Future Technology Devices International Limited)
  Version:    6.00
  Serial Number:    AQ01D0DE
  Speed:    Up to 12 Mb/s
  Manufacturer:    FTDI
  Location ID:    0x04113000 / 10
  Current Available (mA):    500
  Current Required (mA):    90
  Extra Operating Current (mA):    0

Java Version (from command line)

Code:

java -version

openjdk version "17.0.3" 2022-04-19
OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7)
OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, sharing)

[mfleming]

The tail end of the log file might also provide a clue.

[Neve]

Thank you Sylvain,

Here’s what I got, and it has been working just fine since 2017.

JAVA VERSION

java --version
java 9.0.1
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

It has always worked until now.

Système Information

Hardware Overview:

Model Name: iMac
Model Identifier: iMac14,2
Processor Name: Quad-Core Intel Core i5
Processor Speed: 3,2 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 32 GB

System Software Overview:

System Version: macOS 10.15.7 (19H2026)
Kernel Version: Darwin 19.6.0

USB-Serial Controller D:

Product ID: 0x2303
Vendor ID: 0x067b (Prolific Technology, Inc.)
Version: 4.00
Speed: Up to 12 Mb/s
Manufacturer: Prolific Technology Inc.
Location ID: 0x14330000 / 19
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0

[Neve]

(08-29-2022 11:30 AM)mfleming Wrote:  The tail end of the log file might also provide a clue.

Hi,

Which log file?

[mfleming]

Sorry for the incomplete answer, but I was sitting around waiting for the Artemis I launch - sadly, didn't happen. I had a similar problem some years back and Sylvain provided an XML file that enables debug logging. Download and unzip the attached file and put it in the same directory as the clupdate jar file. After running the program you should see a clupdate.log file in your directory.

Hope it helps,
~Mark

[Neve]

Thanks Mark,

I actually have a log file (clupdate.log) in that folder, that was generated yesterday, but it’s empty. Is this supposed to generate a different log file?

[mfleming]

I believe it actually enables debug output. Give it a try!

[Neve]

(08-30-2022 11:25 AM)mfleming Wrote:  I believe it actually enables debug output. Give it a try!

Thank you Mark, will do, and report back when I do.

[Sylvain Cote]

Neve,
In the file Mark gave you, you will find the log4j2.xml file.
Put that file in the same folder as the clupdate java archive file (.jar).
This specific file is configured to generate a lot of logs. (trace level)
You can change that by modifying the xml file.
Debug level, what it does and available monitoring packages are all described in the xml file.
Sylvain

[Neve]

(08-30-2022 02:24 PM)Sylvain Cote Wrote:  Neve,
In the file Mark gave you, you will find the log4j2.xml file.
Put that file in the same folder as the clupdate java archive file (.jar).
This specific file is configured to generate a lot of logs. (trace level)
You can change that by modifying the xml file.
Debug level, what it does and available monitoring packages are all described in the xml file.
Sylvain

Sylvain,

I did it. I have the log file, but it’s kind of big at 116Mb…
What do you need?

Stephen.

[Neve]

Greetings,

Here are the last lines of the very long log.

[Sylvain Cote]

Hello Stephen,
Again, sorry for not being very responsive.
Yeah, lots of packages are in trace mode so the log is expected to be big.

From what I see, the clupdate program is able to open up and configure the serial port

Code:

clupdate.serial.SerialPortJSerialCommImpl.ctor:parameter(s) [portName: /dev/tty.usbserial] [baudRate: 4800]
clupdate.serial.SerialPortJSerialCommImpl.open:enter
clupdate.serial.SerialPortJSerialCommImpl.open:returns true (opened)
clupdate.serial.SerialPortJSerialCommImpl.open:leave

but is not receiving anything from it (looping on this)

Code:

clupdate.serial.SerialPortJSerialCommImpl.readByte:enter
clupdate.serial.SerialPortJSerialCommImpl.readByte:returns [read: 0 byte]
clupdate.serial.SerialPortJSerialCommImpl.readByte:leave

Then at some point you pressed Control-C to exit the program.

Code:

clupdate.tools.ExitRequestHandler.run abort requested, waiting for resources to be released.

It is looking like nothing is coming out of the 41CL or the serial driver is having some issue or we have defective cables.
I will need to do some investigation on my side, but as I said before, this will have to be postponed.

Sylvain

edit: typos

[Neve]

Hi Sylvain,

I understand you’re busy, don’t worry. And yes, I finally hit the CTRL C keys.

I would understand if one CL had a defective serial port…. But both at the same time? This is highly unlikely, although not impossible.
It could be the serial cable…. I’ll try to use it with something else and see how it goes.

The only thing I see on the CL side is « COMM », and then « TIME ERR ». At that point I just hit CTRL C.

[mfleming]

(08-27-2022 11:04 PM)Neve Wrote:  I don’t understand what’s wrong. Was a bug inadvertently introduced with the latest rom mentioned above?

As a sanity check, I tried updating a 41CL that had already been updated to the latest 220722 and it connected and responded as expected.

Quote:12:01:23 Report Outdated ROM images [BoardGeneration: second]
12:01:23 Report 0 outdated pages, out of 512 pages, spread over 0 Flash blocks, estimated update time: 00h 00m 00s
12:01:45 Received CLOSE_CHANNEL_REQUEST(0x57)
12:01:45 Sent CLOSE_CHANNEL_RESPONSE(0x58)
12:01:49 Serial COM12 closed.

It seems the rom update itself isn't the source of the problem. If two 41CL's behave the same, I'd think the problem lies with the serial cable. The clupdate program would have errored out if it tried to open a nonexistent serial port. The only other possibility - a mismatched baud rate?

~Mark

[Neve]

(08-31-2022 04:14 PM)mfleming Wrote:  It seems the rom update itself isn't the source of the problem. If two 41CL's behave the same, I'd think the problem lies with the serial cable. The clupdate program would have errored out if it tried to open a nonexistent serial port. The only other possibility - a mismatched baud rate?

~Mark

Mark,

Yes, the 2 CL’s behave exactly the same. I have 2 serial cables that go from the CL to the UART serial to USB cable. I’ve tried the 2 cables and had the exact same results. The only culprit could be the UART serial to USB cable, or as Sylvain suggested, maybe the driver. That would be weird as it’s been working for ages, up until a month ago when I did the last update. Baud rate has always been the same since day one: 4800.

I have another application on Linux that needs that UART cable to receive screen dumps from a Tektronix 1GHz Digital Signal Analyser. I’ll try that later on. If that works, that would mean that the whole signal chain (cable wise) is good. That would also mean that the MacOS driver “might” have an issue. Linux uses a different one, so it won’t be affected….

[Neve]

I’ve just checked, and the serial to USB cable works great on Linux when running the Tektronix Signal Analyser. So it’s definitely not any of the 3 cables.
I don’t think it’s the driver either, because, come to think of it, I believe my Linux system is using the MacOs Driver through VMWare…

Could it be that the last time I used VMWare, it didn’t properly release the driver?…
Hmmmm…

[Neve]

Hello everyone,

I tried again updating all my CL’s, this time with the new 220923 rom file, and I still can’t do it the way I used to. I’m getting the exact same result as mentioned above.
This is starting to scare me…

Anyone else has had that problem before?

Regards.

[Sylvain Cote]

(10-05-2022 07:19 PM)Neve Wrote:  Hello everyone,

I tried again updating all my CL’s, this time with the new 220923 rom file, and I still can’t do it the way I used to. I’m getting the exact same result as mentioned above.
This is starting to scare me…

Anyone else has had that problem before?

Regards.

Yes, I have a similar issue, the update works but when I try to manually transfer a single ROM it fails. (both are running the same part of code)
It seems related to the Apple FTDI serial driver on macOS Monterey, I need to investigate further.
On the same machine, the update and single ROM file transfer works inside Windows running under Parallels VM using the same adapter, go figure.
It is on my todo list, sorry about that.
Sylvain

[rprosperi]

(10-05-2022 07:37 PM)Sylvain Cote Wrote:  It seems related to the Apple FTDI serial driver on macOS Monterey, I need to investigate further.
On the same machine, the update and single ROM file transfer works inside Windows running under Parallels VM using the same adapter, go figure.

I will (mostly) avoid making a crass anti-macOS comment here, just for overall pleasantness and decorum.