SerialPort on BalenaOS not working

skuenstler · June 10, 2022, 12:24am

Trying to get a USB-[FTDI]-device connected to my Asus Tinker S R2.0 board on Balena-Cloud (i.e. running balenaOS).

The problem is:

if I run my code on the original Tinker image (i.e. Debian I think this is) → then everything works
if I run the exact same code on a balenaOS image (Tinker S) → then the USB-[FTDI]-device cannot be read ! Instead there are a couple of strange letters (E01 E008 etc dropping in at the startup - but no actually expected serial data coming in). The port is recognised but no data comes in.

Here is the excerpt of the Docker.template file:

RUN sudo apt-get update -y
RUN sudo apt-get install -y python3
#the following two lines are needed for node-package SerialPort and usb-detection to work properly
RUN sudo apt-get install -y build-essential
RUN sudo apt-get install -y libudev-dev
ENV UDEV=1

As mentioned already, also with the balenaOS version, the serialport is recognised and the port can be opened. However, no incoming data from the serialport can be read.

The port is: tty.usbmodem6250301 as I find the device inside /dev

Any idea what I have to do in order for the balenaOS also to work with the USB-device on the SerialPort ??

anujdeshpande · June 10, 2022, 11:51am

Hi

Are you hot plugging the device by any chance?

anujdeshpande · June 10, 2022, 11:52am

Also, did your debian install have any drivers that you put there for the said ftdi chip?

skuenstler · June 10, 2022, 12:03pm

no and no. (i.e. no hot plugging and no special drivers installed with debian)

skuenstler · June 10, 2022, 12:05pm

The working image is:

Tinker Board S R2.0 Debian 10 V3.0.11

Board: Tinker Board S R2.0
Link: Tinker Board. (very bottom of page)

The balenaOS version that is NOT working:

BalenaOS 2.38.3+rev1 (Development)

and actually to be clear: Eventually I would like to use hot plugging ! But for now, I can live with having the dongle plugged into one of the Tinker USB-plugs at power-on…)

skuenstler · June 11, 2022, 12:41am

The USB[FTDI] device that is not read correctly with balenaOS turns out to be on /dev/ttyACM0

Either it is a FTDI-driver issue - but how are they different from balenaOS-image to Tinker-Debian-image ??

Or it is a permission issue of this /dev/ttyACM0 serialport. Or something completely else…

I don’t think it is an issue with the node-packages serialport and usb-detection - since they run fine for the Tinker-Debian-image without issue.

Only the balenaOS messes-up the USB[FTD] reading.

Any idea what I can do ?

skuenstler · June 11, 2022, 11:37am

I also tried (without success unfortunately) adding a docker-compose.yaml file that defines the /dev/ttyACM0 device explicitely:

Still, it does not work - any more ideas ???

version: "2.1"
services:
    hello:
        build: .
        restart: always
        privileged: true
        network_mode: host
        devices:
             - "/dev/ttyACM0:/dev/ttyACM0"
        cap_add:
            - SYS_RAWIO

This is what gets spit out after the serialport Port Creation (see below).

On Tinker-Debian, none of this nonsense-log is happening. Instead the serialport can read the port correctly.

Here is the log on the balenaOS: (it should not happen) :

[Logs]    [6/11/2022, 13:35:43] [hello] [SUCCESS]: /dev/ttyACM0: PORT OPENED
[Logs]    [6/11/2022, 13:35:43] [hello] 0
[Logs]    [6/11/2022, 13:35:47] [hello] 0OK
[Logs]    [6/11/2022, 13:35:47] [hello] 
[Logs]    [6/11/2022, 13:35:47] [hello] 0OK
[Logs]    [6/11/2022, 13:35:47] [hello] OK
[Logs]    [6/11/2022, 13:35:47] [hello] 
[Logs]    [6/11/2022, 13:35:47] [hello] 0OK
[Logs]    [6/11/2022, 13:35:47] [hello] OK
[Logs]    [6/11/2022, 13:35:47] [hello] E
[Logs]    [6/11/2022, 13:35:48] [hello] 0OK
[Logs]    [6/11/2022, 13:35:48] [hello] OK
[Logs]    [6/11/2022, 13:35:48] [hello] E1
[Logs]    [6/11/2022, 13:35:48] [hello] 0OK
[Logs]    [6/11/2022, 13:35:48] [hello] OK
[Logs]    [6/11/2022, 13:35:48] [hello] E1 
[Logs]    [6/11/2022, 13:35:48] [hello] 0OK
[Logs]    [6/11/2022, 13:35:48] [hello] OK
[Logs]    [6/11/2022, 13:35:48] [hello] E1 E
[Logs]    [6/11/2022, 13:35:48] [hello] 0OK
[Logs]    [6/11/2022, 13:35:48] [hello] OK
[Logs]    [6/11/2022, 13:35:48] [hello] E1 E0
[Logs]    [6/11/2022, 13:35:51] [hello] 0OK
[Logs]    [6/11/2022, 13:35:51] [hello] OK
[Logs]    [6/11/2022, 13:35:51] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:51] [hello] 
[Logs]    [6/11/2022, 13:35:51] [hello] 0OK
[Logs]    [6/11/2022, 13:35:51] [hello] OK
[Logs]    [6/11/2022, 13:35:51] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:51] [hello] OK
[Logs]    [6/11/2022, 13:35:51] [hello] 0OK
[Logs]    [6/11/2022, 13:35:51] [hello] 
[Logs]    [6/11/2022, 13:35:51] [hello] OK
[Logs]    [6/11/2022, 13:35:51] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:51] [hello] OK
[Logs]    [6/11/2022, 13:35:51] [hello] E
[Logs]    [6/11/2022, 13:35:52] [hello] 0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1
[Logs]    [6/11/2022, 13:35:52] [hello] 0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 
[Logs]    [6/11/2022, 13:35:52] [hello] 0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 E
[Logs]    [6/11/2022, 13:35:52] [hello] 0OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 E0OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] OK
[Logs]    [6/11/2022, 13:35:52] [hello] E1 E0

skuenstler · June 11, 2022, 3:07pm

I also tried to change the udevRules in the config.json.

Unfortunately, still without success

I am more than desperate to get this USB[FTDI] reading issue up-n-running !

Does anyone have more ideas ???

Here is the udev-rules that I added to the config.json:

"os": {
		"udevRules": {
			"56": "ENV{ID_FS_LABEL_ENC}==\"resin-root*\", IMPORT{program}=\"resin_update_state_probe $devnode\", SYMLINK+=\"disk/by-state/$env{BALENA_UPDATE_STATE}\"",
			"64": "ACTION!=\"add|change\", GOTO=\"modeswitch_rules_end\"\nKERNEL==\"ttyACM*\", ATTRS{idVendor}==\"abcd\", ATTRS{idProduct}==\"1234\", TAG+=\"systemd\", ENV{SYSTEMD_WANTS}=\"u-blox-switch@'%E{DEVNAME}'.service\"\nLBEL=\"modeswitch_rules_end\"\n"
		}
	}

nmaas87 · June 11, 2022, 5:39pm

I would use dmesg, lsmod (in balenaOS, not in a container, I would try to get it working first before going further…) and see if the FTDI really mounts as ttyACM0 and not something else.
Then I would use stty to set the USB FTDI to some correct speed and maybe try to bridge the serial side of the FTDI chip and play around with echo and try to send some data and see if this works.
It would also be useful to know which USB FTDI you are using, possible that there are driver issues within Yocto for that specific FTDI chip (you can acquire the vendor and hw ids via lsusb on any linux machine).

Best of luck

skuenstler · June 11, 2022, 8:36pm

Thank you nmaas87,

90% of what you suggest I have done. Since I can plug/unplug the USB[FTDI] to my Tinker-Debian with no issues, I am absolutely sure that it works. Also if I connect it to an App called Serial, it all works too !

And if I plug it to my Tinker-balenaOS then the serialport and usb-detection Node-packages do bring me the information that the USB[FTDI] connected to /dev/ttyACM0 just the same way it does when plugged to Tinker-Debian.

[Logs] [6/11/2022, 13:35:43] [hello] [SUCCESS]: /dev/ttyACM0: PORT OPENED

Now since I work with a serialport parser, I get all the information logged that comes from the USB[FTDI]. The log shows anything coming from the USB-port that is read to the serialport-buffer. For a test-device with a simple RS232-to-USB[FTDI] converter, I have everything working nicely (i.e. I can write anything to the serialport-buffer). And even the Tinker-balenaOS then works !!

But for the USB[FTDI] dongle at question, there are these messy E0 and E and OK numbers that are pushed.

I think you are right with the assumption that the FTDI-chip (or timing settings) are not compatible with Yocto.

The question is: What is different in Tinker-balenaOS compared to Tinker-Debian ???

skuenstler · June 13, 2022, 12:26pm

The solution was to change the board (and together with it, to change the balenaOS-version)

Before:
balenaOS 2.38.3 (rev 1)
for Tinker Asus S
→ the USB[FTDI] dongle at question is not working

After:
balenaOS 2.98.33
for Generic_x86_64
→ everything working fine - the USB[FTDI] dongle at question is working just great !!!

It is not clear to me whether it was the different driver or wether the Yocto-kernel also shows differences within these two balenaOS-versions.

Anyway, I will not use the Tinker S with balenaOS 2.38.3 anymore for this USB dongle but rather the new combination of HW and OS.

nmaas87 · June 13, 2022, 3:05pm

The newer balenaOS will probably use a newer Yocto version, so that will change a lot. Having another architecture also helps, but I think there might have been some problems with the older Yocto. Nice that you got it working, all the best!

skuenstler · June 13, 2022, 5:36pm

Thank you for confirming Yocto-versions.

The balena-officially recommended version for the Asus Tinker S board is balenaOS 2.38.3 (rev 1) . I never tried to install a newer version since recommended.

As you said, the best bet is probably to go with the new Yocto-version preferably and choose a HW-board that fulfils the recommended balenaOS-version.

Thank you for your thoughts and contributions.