Serial connection between host and Kasli

steine01

During the discussion of Issue 1759, the serial connection between the host PC and Kasli came up. Since I am not yet familiar with this communication pathway, I have some questions.

I have connected the USB port of the Kasli with the host PC on which I also run the dashboard and artiq_master. I see that it is the correct connection, because the Quad RS232-HS USB connectors in the device manager disappear when I unplug the Kasli USB-Port. I also can flash the firmware onto Kasli from this PC.

When I use hterm or python -m serial.tools.miniterm though, no available ports are listed in either of them. With Wireshark and USBPcap I do see the serial connection and can listen to it, but no messages are exchanged other than the configuration (or so it seems):

No. Time Source Destination Protocol Length Info
1 0.000000 host 1.6.0 USB 36 GET DESCRIPTOR Request DEVICE
2 0.000000 1.6.0 host USB 46 GET DESCRIPTOR Response DEVICE
3 0.000000 host 1.6.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
4 0.000000 1.6.0 host USB 129 GET DESCRIPTOR Response CONFIGURATION
5 0.000000 host 1.6.0 USB 36 SET CONFIGURATION Request
6 0.000000 1.6.0 host USB 28 SET CONFIGURATION Response

Is there something configured incorrectly on my end? How can I send commands/listen to the serial connection directly? I updated ARTIQ and the firmware about a week ago, but do not know if it was different beforehand, since I never had t use the serial port apart from flashing the firmware.

lriesebos

Not sure if you are just looking for UART logging, but we wrote a small utility that infinitely logs UART output. We basically run it on the background to capture logs in case we need it.

https://gitlab.com/duke-artiq/dax-comtools/-/blob/master/dax_comtools/tools/core_logger.py

sb10q

It's just a regular serial port, 115200bps 8-N-1. On Linux you can simply do, without installing anything:

stty 115200 < /dev/ttyUSB2
cat /dev/ttyUSB2

Unplug and replug the USB cable to reset the FTDI USB UART in case there is any suspicion that other programs may have selected some options you do not want. Also make sure programs like ModemManager are not interfering.

On Windows, driver issues are common and I don't have a good terminal program to recommend either. Maybe you can find some answers from FTDI.

steine01

@sb10q Thank you for the advice, sadly I have to use Windows currently. After further discussion on issue 1759, it came up, that the Zadiq modification of the serial ports for flashing has to be reverted.

After I did this, I could see the respective serial port with python -m serial.tools.miniterm. But after connecting, I get the following error message:


(artiq-6-2) C:\Users\ybion443>python -m serial.tools.miniterm

--- Available ports:
---  1: COM3                 'Quad RS232-HS (Interface 2) (COM3)'
--- Enter port index or full name: 1
could not open port 'COM3': Cannot configure port, something went wrong. Original message: PermissionError(13, 'A device attached to the system is not functioning.', None, 31)

This error was already reported in issue 1487. This issue is now resolved, so apparently there is a solution to the problem. I followed the steps in issue 1487, so I replaced all but interface 0 with the CDC drivers and power-cycled the Kasli. I still get the same error. I also read through the rest of the issue, but from what I understand, this is about getting artiq_flash to work with just the driver of interface 0 replaced, correct?

There is a mention at the end, that "this looks like a Windows bug", but I am not sure how to proceed from here. For the specific problem in the issue, I think I can get by with a separate machine, that logs the serial output, but in the long run it would be better to have it all run on the same host.

Edit: Other terminal programs also cannot connect with the port, but on another machine, not affected by Zadiq, it seems to work well.

sb10q

This kind of issue is why I recommend Linux or another free OS - in addition to plenty of other problems such as the spyware/adware built into recent versions of Windows and many Microsoft applications. I find it a bit shocking that physics labs have so many problems with installing an OS (even if you don't want to do it yourself, professional support costs a fraction of the typical laser equipment commonly in use), but that's how things are. M-Labs are now selling Intel NUCs preinstalled with Linux and ARTIQ, for what it's worth.

What is in the serial console then? Any hint about the original problem?

steine01

The serial console currently is continously read out on a seperate PC thanks to the help from @jordens, but the crash issue has not reappeared yet. Since it seems to happen at random over a long time, I will have to wait for now. I will update the issue and here once it occured again.