I work with two prototyping board from cypress: CY8CKIT-043 and CY8CKIT-049.

When I plug the first into a usb port, a /dev/ttyACM0 is created and I can communicate with the device.

For the second, things are more complicated, it seems that a USB-serial device is on the board, but nothing is mounted.

The second device is seen as a thermometer (as dmesg and lsusb report)

I search in udev the rules associated with each device, but I only get more puzzled:

For the working one, in 60-openocd.rules

# Cypress KitProg in KitProg mode
ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="f139", MODE="660", GROUP="plugdev", TAG+="uaccess

For the other, I found it in 77-mm-usb-serial-adapters-greylist.rules, I'm not sure, but if I understand well, the device is prevented to be used normally (?)

ATTRS{idVendor}=="04B4", ATTRS{idProduct}=="0002", ENV{ID_MM_TTY_MANUAL_SCAN_ONLY}="1"


  • Do I try to make something impossible?
  • If not, how can I just tell the system to create a /dev/ttyACMx file using driver cdc_acm for usb bus xxx device yyy ?

What I tried reading https://www.linuxquestions.org/questions/linux-hardware-18/forcing-a-specific-driver-for-a-device-through-udev-836411/, I tried to create some udev rules like

ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="0002", RUN+="modprobe cdc_acm", NAME="ttytest"

But without success.

More info

lsusb for the 043 (working device):

Bus 001 Device 029: ID 04b4:f139 Cypress Semiconductor Corp. Cypress KitProg
Device Descriptor:
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0xf139 
  bcdDevice            2.15
  iManufacturer           1 Cypress Semiconductor
  iProduct                2 Cypress KitProg

dmesg for the 043 (working device):

usb 1-2: New USB device found, idVendor=04b4, idProduct=f139, bcdDevice= 2.15
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=128
usb 1-2: Product: Cypress KitProg
usb 1-2: Manufacturer: Cypress Semiconductor
usb 1-2: SerialNumber: 0B05091C02179400
hid-generic 0003:04B4:F139.000B: hiddev0,hidraw3: USB HID v1.11 Device [Cypress Semiconductor Cypress KitProg] on usb-0000:00:14.0-2/input0
cdc_acm 1-2:1.2: ttyACM0: USB ACM device

lsusb for the 049 (not working):

Bus 001 Device 011: ID 04b4:0002 Cypress Semiconductor Corp. CY7C63x0x Thermometer
Device Descriptor:
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0x0002 CY7C63x0x Thermometer
  bcdDevice            0.00
  iManufacturer           1 Cypress Semiconductor
  iProduct                2 USB-Serial (Single Channel)

dmes for the 049 (not working):

usb 1-2: New USB device found, idVendor=04b4, idProduct=0002, bcdDevice= 0.00
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: USB-Serial (Single Channel)
usb 1-2: Manufacturer: Cypress Semiconductor
cytherm 1-2:1.0: Cypress thermometer device now attached
cytherm 1-2:1.1: Cypress thermometer device now attached
cytherm 1-2:1.2: Cypress thermometer device now attached

1 Answer 1


For some reason, the board 049 presents an USB product ID that is associated with the CY7C63x0x Thermometer, which has its own cytherm driver.

Because the cytherm driver is matched by vendor+product IDs, it is considered a higher-priority match than a match by interface class, subclass and protocol, which would match the cdc-acm driver.

You could blacklist the cytherm driver by adding this line to e.g. /etc/modprobe.d/blacklist.conf:

blacklist cytherm

and then modprobe -r cytherm to unload the cytherm driver if it is already loaded.

After that, if you unplug & re-plug the device, it should then be claimed by the cdc-acm driver.

You don't seem to be the first with this issue: see https://community.infineon.com/t5/USB-low-full-high-speed/USB-to-serial-bridge-recognized-as-Thermometer-04b4-0002-instead-of-as-a-serial/td-p/350483

The udev rule with ENV{ID_MM_TTY_MANUAL_SCAN_ONLY}="1" just tells ModemManager to not probe the resulting TTY device for mobile data modems and the like, unless the administrator explicitly tells it to scan this device. That's actually a good idea for any TTY-like non-modem device, as the probe attempts might cause errors or undesired operation of the device.

You might also need an udev rule like this to specify permissions for the device:

ACTION=="add", ATTRS{idVendor}=="04B4", ATTRS{idProduct}=="0002", MODE="660", GROUP="plugdev", TAG+="uaccess"

Apparently it is also possible to use Cypress programming tools to change the product ID of the board, to persistently remove this conflict. If you need this board to work with multiple Linux systems, this might be the way to go (see the link above for more info).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .