Teensy 4.1 no serial port when connected to Raspberry Pi 4

[EasyGoing1]

Hello,

I've been playing around with a sketch using my mac, and everything has been working just fine. However, I needed to move the Teensy to another room to connect it to some hardware and figured I would just use a Pi to upload sketch changes to the Teensy 4.1.

So I installed the 32 bit version of Raspberry Pi OS, did a sudo apt-get update / upgrade, then I installed Arduino IDE 1.8.19 from their website and made sure it worked. Then I followed the directions on this site to install the Teensy support using the 32 bit ARM version and as far as the software goes, everything seems to be working fine. The IDE runs and when I check a sketch, the Teensy uploader fires off and is running.

My problem is that I cannot see any serial ports under /dev for the Teensy and none show up in the IDE (except for /dev/ttyAMA0 - but that port is there even when the Teensy is not plugged in).

The USB cable is a proper 4 conductor cable that I was using on my Mac to program the Teensy, I just moved it over to the Pi when I moved the hardware.

The power supply for the Pi is an aftermarket (but very popular and supported) power supply designed for the Pi 4.

Under Tools, USB Type is just 'Serial' and there is an active sketch running on the Teensy.

Any ideas why the USB port might not be showing up on the Pi?

Edit: executing lsusb only shows this when the Pi is connected:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[PaulStoffregen]

Maybe you kernel lacks the cdc_acm driver?

Try watching the syslog messages as you plug and unplug the USB cable. On Ubuntu you would run "tail -f /var/log/syslog" in a terminal. The kernel should give info about what's happening. If the problem isn't obvious, copy all the syslog stuff here so we can see what you see on the screen.

[EasyGoing1]

OK, I'll do that ... I was thinking maybe just installing Ubuntu might be a better option anyway.

Is there a way to compile and upload sketches just using the terminal? It would be more convenient to just use SSH while working remotely like this.

[EasyGoing1]

OK, I ran the tail command as you wrote it and nothing happens at all when I plug and unplug the Teensy... no updates on the screen and no added text to the syslog

Here are the last few lines from the syslog ... I executed the command, then I went over there and unplugged then plugged in the Teensy - saw the lights light up after plugging it in etc. but as you can see ... nothing...

Jun 16 15:48:39 raspberry4 dbus-daemon[403]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.47' (uid=1000 pid=1111 comm="pipanel ")
Jun 16 15:48:39 raspberry4 systemd[1]: Starting Hostname Service...
Jun 16 15:48:39 raspberry4 dbus-daemon[403]: [system] Successfully activated service 'org.freedesktop.hostname1'
Jun 16 15:48:39 raspberry4 systemd[1]: Started Hostname Service.
Jun 16 15:48:41 raspberry4 dbus-daemon[652]: [session uid=1000 pid=652] Activating service name='ca.desrt.dconf' requested by ':1.22' (uid=1000 pid=1111 comm="pipanel ")
Jun 16 15:48:41 raspberry4 dbus-daemon[652]: [session uid=1000 pid=652] Successfully activated service 'ca.desrt.dconf'
Jun 16 15:48:44 raspberry4 PackageKit: refresh-cache transaction /13_dddcebea from uid 1000 finished with success after 7742ms
Jun 16 15:48:49 raspberry4 PackageKit: get-updates transaction /14_caeaaaab from uid 1000 finished with success after 4715ms
Jun 16 15:49:09 raspberry4 systemd[1]: systemd-hostnamed.service: Succeeded.
Jun 16 15:58:55 raspberry4 systemd[1]: Started Session 4 of user michael.

[KurtE]

First thing I would do if I were you would be to try different USB cable... Maybe power only cable?

It has been awhile since I tried out T4 with 32 bit raspi OS... I have been testing RPI4 with Ubuntu 22.04 64 bits and programming Teensy and that works.

Maybe I will try to program the other T4 I have with latest Raspian.

[PaulStoffregen]

and nothing happens at all when I plug and unplug the Teensy...

Sounds like a charge-only USB cable with only 2 wires for power, no data wires at all.

[EasyGoing1]

First thing I would do if I were you would be to try different USB cable... Maybe power only cable?

It has been awhile since I tried out T4 with 32 bit raspi OS... I have been testing RPI4 with Ubuntu 22.04 64 bits and programming Teensy and that works.

Maybe I will try to program the other T4 I have with latest Raspian.

It's definitely a 4 wire cable, because it is the same cable I was using to program the Teensy when using my Mac ... I merely transferred the cable with the Teensy into the other room.

BUT, I installed Ubuntu 22.04 Desktop - 64 bit version onto the Pi ... I'll know soon if it will work or not.

[PaulStoffregen]

Download Teensyduino software matching the Linux software distro. It doesn't matter if the ARM processor on RPi4 could run 64 bit software. It matters what software you are actually running. If you installed a 32 bit system, then you need the 32 bit version, even if the CPU has capability for 64 bits.

But no amount of software reinstall will solve a USB hardware problem. If the kernel isn't printing any syslog message, that's a sure sign the USB hardware isn't connected or working properly. Even just touching a 1.5K resistor from either USB data signal to 3.3V will cause the kernel to detect a hardware attach event. If you're getting no syslog messages at all when the hardware is plugged in, and the hardware does work when plugged into a normal PC, there's something wrong with the USB hardware connection.

Just a very quick test, while watching syslog, plug in a USB mouse or keyboard or flash drive or other known good USB device. The kernel always prints a syslog message about detecting a new USB device, and whether it is low/full/high/super speed.

[EasyGoing1]

Download Teensyduino software matching the Linux software distro. It doesn't matter if the ARM processor on RPi4 could run 64 bit software. It matters what software you are actually running. If you installed a 32 bit system, then you need the 32 bit version, even if the CPU has capability for 64 bits.

But no amount of software reinstall will solve a USB hardware problem. If the kernel isn't printing any syslog message, that's a sure sign the USB hardware isn't connected or working properly. Even just touching a 1.5K resistor from either USB data signal to 3.3V will cause the kernel to detect a hardware attach event. If you're getting no syslog messages at all when the hardware is plugged in, and the hardware does work when plugged into a normal PC, there's something wrong with the USB hardware connection.

Just a very quick test, while watching syslog, plug in a USB mouse or keyboard or flash drive or other known good USB device. The kernel always prints a syslog message about detecting a new USB device, and whether it is low/full/high/super speed.

Yeah, I went with the 64 bit Arduino IDE and the Linux Installer (AARCH64 / Jetson TX2) from your site (I didn't know that AARCH and ARM were essentially interchangeable terms).

I still don't know what the problem was, but I managed to fix it.

I ran tail again on the Pi (now running Ubuntu 22.03 64) and plugging it in and unplugging it did absolutely nothing, so wanting to make sure it wasn't something with the USB ports, I plugged another USB device and tail lit up like a Christmas tree ... so I took the cable and the Teensy back over to my Mac and plugged it in and same thing ... absolutely NOTHING ... SO, I held down the button for 15 seconds, and let it reset. Then I re-plugged it in to give a power cycle and it came up to where I was able to upload a sketch by hitting upload then hitting the button on the Teensy ... the sketch uploaded then the Teensy came back as a serial port again.

Took it back over to the Pi and it's registering fine now with the IDE seeing it as a (Teensy) in the port selection.

No idea what happened or how it happend, but I'm glad it's finally working.

My last question is: Is there a way to compile then upload sketches to the Teensy using JUST Terminal - no GUI?

Mike

[PaulStoffregen]

Is there a way to compile then upload sketches to the Teensy using JUST Terminal - no GUI?

Yes, there are several ways. Maybe better to start a new thread, rather than discussing this under "no serial port".

[KurtE]

Took it back over to the Pi and it's registering fine now with the IDE seeing it as a (Teensy) in the port selection.

No idea what happened or how it happend, but I'm glad it's finally working.

My last question is: Is there a way to compile then upload sketches to the Teensy using JUST Terminal - no GUI?

Glad it is working! I will probably still check to see if everything still works on the latest RPI release 32 bits... Programmed an SD card last night, will try later today.
As I mentioned my other RPI4 has ubuntu 64 bit on it.

As for doing it headless... As Paul mentioned, probably a different topic. But you might want to do a search as several including myself have done it in the past...

You could look at the thread: https://forum.pjrc.com/threads/53548...Teensy-Support
Although not sure if they have official builds yet for RPI?

In the past I often would simply build it on my PC, copy the hex file to the RPI. And then use teensy_loader_cli to program the RPI. At one point I hacked up a Teensy install to allow it to SCP the hex file to my RPI, to a specific location on the RPI. I also had a simple script on RPI, that looked for an updated file in a directory and would automatically do the teensy_loader_cli.

But again different topic.

[mklod]

Maybe you kernel lacks the cdc_acm driver?

Try watching the syslog messages as you plug and unplug the USB cable. On Ubuntu you would run "tail -f /var/log/syslog" in a terminal. The kernel should give info about what's happening. If the problem isn't obvious, copy all the syslog stuff here so we can see what you see on the screen.

I have this same problem: teensy 4.1 is not recognized when plugged into rpi4 by USB cable. On the other hand, I have never had this problem with teensy 3.6.

I am using the same exact USB cable for both teensy 3.6 and teensy 4.1. It is not a cable or USB hardware problem. Nor is it a dead MCU: the teensy 3.6 and 4.1 are both detected and programmable on win64.

I only want to connect to the pre programmed teensy 4.1 on rpi4 (raspbian); I do not want to use rpi as my programming/flash environment.

tail command shows ACM assigned for teensy 3.6 when plugged in, but NOT for teensy 4.1:

Dec  5 15:51:33 raspberrypi kernel: [ 6616.719371] usb 1-1.2: new full-speed USB device number 18 using dwc2
Dec  5 15:51:33 raspberrypi kernel: [ 6616.850545] usb 1-1.2: New USB device found, idVendor=16c0, idProduct=0483, bcdDevice= 2.77
Dec  5 15:51:33 raspberrypi kernel: [ 6616.850569] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec  5 15:51:33 raspberrypi kernel: [ 6616.850580] usb 1-1.2: Product: USB Serial
Dec  5 15:51:33 raspberrypi kernel: [ 6616.850587] usb 1-1.2: Manufacturer: Teensyduino
Dec  5 15:51:33 raspberrypi kernel: [ 6616.850595] usb 1-1.2: SerialNumber: 10256090
Dec  5 15:51:33 raspberrypi kernel: [ 6616.851570] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Dec  5 15:51:33 raspberrypi mtp-probe: checking bus 1, device 18: "/sys/devices/platform/soc/fe980000.usb/usb1/1-1/1-1.2"
Dec  5 15:51:33 raspberrypi mtp-probe: bus: 1, device: 18 was not an MTP device
Dec  5 15:51:33 raspberrypi mtp-probe: checking bus 1, device 18: "/sys/devices/platform/soc/fe980000.usb/usb1/1-1/1-1.2"
Dec  5 15:51:33 raspberrypi mtp-probe: bus: 1, device: 18 was not an MTP device
Dec  5 15:52:30 raspberrypi kernel: [ 6673.766761] usb 1-1.2: USB disconnect, device number 18
Dec  5 15:52:32 raspberrypi kernel: [ 6675.849424] usb 1-1.2: new high-speed USB device number 19 using dwc2
Dec  5 15:52:32 raspberrypi kernel: [ 6676.389365] usb 1-1.2: new high-speed USB device number 20 using dwc2
Dec  5 15:52:33 raspberrypi kernel: [ 6676.829518] usb 1-1-port2: attempt power cycle
Dec  5 15:52:34 raspberrypi kernel: [ 6677.489368] usb 1-1.2: new high-speed USB device number 21 using dwc2
Dec  5 15:52:34 raspberrypi kernel: [ 6678.029399] usb 1-1.2: new high-speed USB device number 22 using dwc2

[KurtE]

Are you using the most recent version of th teensy udev rules?

And o what is the code running on t4.1 configured for as usb type

[PaulStoffregen]

Can you try a different USB cable?

Some really low quality cables work fine for 12 Mbit speed but fail to communicate successfully at 480 Mbit speed.

[mklod]

I tried multiple USB cables. Again, they are definitely not the problem since the same USB cable and same teensy 4.1 works fine on win64. The problem only arises when plugging teensy into rpi. It is an rpi cm4 running raspbian buster. The appropriate overlay has been added to enable the USB hub and all four USB ports work fine with various peripherals (keyboard, mouse, flash drive, arduino, teensy 3.6).

Teensy 4.1 is set to USB serial, as expected. I double checked.

I applied the udev rule per https://www.pjrc.com/teensy/troubleshoot.html:

Linux: Long Delay Before USB Serial Detected
On some Linux systems, USB Serial is detected very slowly. The kernel detects the device quickly (usually seen with "tail -f /var/log/messages"), but the device files do not appear for a very long time.
Edit "/lib/udev/rules.d/77-nm-probe-modem-capabilities.rules", adding this line:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[7-9]?", GOTO="nm_modem_probe_end"

Notably, I had to create this 77 file as it did not previously exist.

I also applied the teensy udev rule per https://www.pjrc.com/teensy/00-teensy.rules.

I also tried

apt-get remove --purge modemmanager

but this package was not found.

[PaulStoffregen]

I don't know why it's not working.

But I'm pretty sure it's not udev rules or software like modemmanager, because the kernel log shows "new high-speed USB device" but not "New USB device found, idVendor=16c0, idProduct ...." That means R-Pi is seeing Teensy turn on its pullup resistor to signal it's connected, and the hardware-based device detection is hearing the high speed chirp during USB reset time to know it's 480 Mbit speed. My limited understanding of Linux USB is that ""New USB device found, idVendor= ...." is a result of reading the USB device descriptor, which is among the very first things the host controller driver does after the USB reset time.

Whatever is going wrong is happening very early, before any software like udev or modemmanager could possibly come into play.

Usually when people have bad cables, there is some sort of error with a negative number. You're not getting any error in syslog, almost as if you don't have the main USB host driver. But that doesn't make any sense, since you can use Teensy 3.6 at 12 Mbit. It's almost as if you have the OHCI driver but not EHCI driver, but a modern Linux kernel configured that way seems somewhere between extremely unlikely to completely impossible.

To actually see what's going on with the USB signals you would need fairly expensive hardware. Then you could see if any sort of USB communication is actually occurring. Or maybe you could run wireshark or other snooping software to see the USB messages? I personally don't ever do that, since I have that USB hardware capture, so can't really help.

If you do figure out what's wrong, I hope you'll post a followup. I'm really curious, as I've never see Linux kernel log quite like this. Very mysterious.

[PaulStoffregen]

As another quick & easy test, after confirming you can talk to Teensy 3.6 plugged in directly, what do you get in the kernel log if you plug in a USB hub, and then plug Teensy 3.6 into that hub?

[mklod]

I don't know why it's not working.
..

If you do figure out what's wrong, I hope you'll post a followup. I'm really curious, as I've never see Linux kernel log quite like this. Very mysterious.

I'm guessing it's something to do with cdc-acm on my linux install. I'm using raspbian buster, and I get the same result with raspbian bullseye. I may try ubuntu next. I read on another forum of people having similar issues with teensy on linux on rpi due to the cdc-acm drivers being moved to a separate package, but in that case I'd expect all teensy versions to not show up. I have not found anyone else with the same problem: some teensy versions being assigned ports and other teensy versions not being assigned ports.

I tried programming teensy 4.1 using dual serial, triple serial, and no change to the problem. I bought a brand new teensy 4.1, no change. I've tested 3 different teensy 4.1s and all have this problem. I have two teensy 3.6 in hand and neither have this problem. It's been really frustrating since teensy 3.6 is not available with the chip shortage and that's the only reason why we switched to teensy 4.1...

[PaulStoffregen]

I plugged a Teensy 4.1 (previously programmed with default USB serial setting) into my Raspberry Pi 4 which runs Raspbian 10 (buster).

This is the syslog result:

Dec  7 15:12:54 pi4 kernel: [124493.083857] usb 1-1.3: new high-speed USB device number 6 using xhci_hcd
Dec  7 15:12:54 pi4 kernel: [124493.224422] usb 1-1.3: New USB device found, idVendor=16c0, idProduct=0483, bcdDevice= 2.80
Dec  7 15:12:54 pi4 kernel: [124493.224433] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec  7 15:12:54 pi4 kernel: [124493.224441] usb 1-1.3: Product: USB Serial
Dec  7 15:12:54 pi4 kernel: [124493.224448] usb 1-1.3: Manufacturer: Teensyduino
Dec  7 15:12:54 pi4 kernel: [124493.224455] usb 1-1.3: SerialNumber: 12161130
Dec  7 15:12:55 pi4 kernel: [124493.318308] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Dec  7 15:12:55 pi4 kernel: [124493.318699] usbcore: registered new interface driver cdc_acm
Dec  7 15:12:55 pi4 kernel: [124493.318709] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

This is the output from "lsb_release -a"

No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

And this is the "uname -a" result

Linux pi4 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux

[mklod]

I plugged a Teensy 4.1 (previously programmed with default USB serial setting) into my Raspberry Pi 4 which runs Raspbian 10 (buster).

Good to know, thanks. I'm actually using a cm4 module, I suppose you are using the standard rpi4, right? Is your raspbian buster 32 bit or 64 bit?

[PaulStoffregen]

We've seen reports before where very minimal Linux systems were missing the cdc_acm driver. The result has been those first 6 lines appear in syslog, but the last 3 are missing without the cdc_acm driver.

Whatever is wrong with your setup runs deeper than just cdc_acm, since you're getting only the first "new high-speed USB device" but not the other 5 lines that come from the main USB host driver.

I know it's really frustrating, but hopefully this at least helps you avoid a fruitless search for the higher level stuff like udev, modemmanager or even the cdc_acm driver. Something much deeper is wrong with your Linux setup. If you have a spare SD card, maybe best to try with a brand new Raspbian install?

[PaulStoffregen]

I suppose you are using the standard rpi4, right? Is your raspbian buster 32 bit or 64 bit?

Yes, normal Raspberry Pi 4 with 4GB memory running 32 bit (armhf) Raspbian.

[mklod]

This is somewhat embarrassing, but I have to say it. My problem was in fact the micro USB cable. The same (relatively long) micro USB cable works with teensy 3.6 on win64 and linux and it works with teensy 4.1 on win64. But this same cable does NOT work on teensy 4.1 and linux.

Interestingly, even with a different much shorter USB cable, I still get only a partial ACM assignment on one of the USB ports on the linux machine (rpi cm4). If I pick a different USB port, I get the complete info from the syslog. I wonder if it has anything to do with power supplied to the cm4 (5v 3A) or, perhaps more likely, quality issues related to the USB hub (USB2514B) on the cm4 carrier PCB. I don't have a spare non-cm4 rpi4 to thoroughly test this, and I'm not sure it's worth examining further since this is the only circumstance in which I've had any issues with the cm4's USB ports and I don't actually need to spend the additional time answering the question of why the same cable works for teensy 4.1 + win64 and NOT for teensy 4.1 + linux/cm4. As I said previously, teensy 3.6, mouse, keyboard, flash drive all work fine on the cm4 USB ports.

The main takeaway here is that low quality micro USB cables may work fine with teensy 3.6 but can't reliably handle the teensy 4.1 speeds.

I haven't yet done a full characterization of which cables / what lengths are OK for the teensy 4.1 + cm4, but I'll probably follow up when I've found what works reliably at 3-6 ft.

[PaulStoffregen]

Glad you finally found the problem.

We've seen this low quality cable issue before several times with normal computers, where 12 Mbit works but 480 Mbit is problematic. But it got ruled out with msg #15. At least you didn't have to waste a lot of time on the udev & software side!