Teensy LC on TX2 shows as HIDRAW2 after pressing reset switch

Status
Not open for further replies.
S

snowface

Member
Hi,
I am using Teensy LC on a TX2 (Auvidea J120 IO board). I have connected the Teensy via a USB cable to the TX2.
When I first plug in the Teensy, it shows up as ttyACM0 which is what I expect.

But when I press the reset button on the teensy, the device shows up as HIDRAW2 instead of ttyACM0. What is going wrong here?

I have remove and plug in the USB cable to reset back to ttyACM0.

Output when teensy shows up as ttyACM0:
base_arm$ sudo lsusb -d 16c0:0483 -vvv

Bus 001 Device 009: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x16c0 Van Ooijen Technische Informatica
idProduct 0x0483 Teensyduino Serial
bcdDevice 2.73
iManufacturer 1 Teensyduino
iProduct 2 USB Serial
iSerial 3 6319350
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 1
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 64
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
 
snowface said:
But when I press the reset button on the teensy, the device shows up as HIDRAW2 instead of ttyACM0. What is going wrong here?
Click to expand...

It's a Program button, not a Reset button. Pressing the button puts Teensy into programming mode, which uses HID protocol. So on Linux, a hidraw device is supposed to appear.

Again, the button is not Reset. It does not cause Teensy to restart your program. It causes Teensy to stop running your program and instead start running the bootloader.
 
Yes, thanks. This helps.
Now the second problem is, I am using the teensy inside a docker. So the moment teensy reboots it shows up as ttyACM1 instead of ttyACM0 loaded to the docker. Is there a way to bind teensy LC to a fixed ttyACM0 port?
 
snowface said:
Is there a way to bind teensy LC to a fixed ttyACM0 port?
Click to expand...

As far as I know, there isn't any reasonable way to stop the kernel from doing device assignment this way. (editing the Linux kernel source code would be an "unreasonable" way....)

But udev offers plenty of ways to match against things like the unique serial number and create a distinctive symbol link, which you can then use to access the device. I can't personally guide you on how to create custom udev rules, but if you search you'll find plenty of tutorials online about the intricacies of udev.

You should probably also keep in mind this assignment of the next number usually happens because some program is still holding a file descriptor open to the old device instance. The Arduino software doesn't do this, especially if using the native "Teensy ports" selection in the Tools > Ports menu. Maybe you're running some other software? I believe the default driver has a fixed limit of how many instances it can create. If whatever software is holding the file descriptor open keeps doing so indefinitely, as you reconnect the device over and over you'll eventually run out of available instances the driver can use. The only viable solution is to fix whatever software is keeping the file descriptor open after the device has disconnected.
 
Status
Not open for further replies.
Back
Top