CDC ACM USB Serial Device doesn't show up on ls /dev/tty*, can't access it

This guarantees we got the right driver, at least for the UART part (there might be more than a UART on a single USB cable):

…so cdc_acm is valid and is loaded and is attached to that part of the USB devices. The name provided is a “traditional” name since it is a “ttyACM#” format. Sometimes udev rules would need to change to reflect a custom name, but this is low on the list of problems. We could probably adjust your udev rule based on one of the rules of the laptop, but since the device is functioning, this too seems unnecessary.

I am unfamiliar with this particular device, but whatever comes next will be related to the software which uses that UART, or software which uses some other device within. Note that you also get this upon cable plugin:

…this idProduct and idManufacturer is not something I can identify (this is not a published ID). This is probably just a hack to provide an ID by a manufacturer who did not want to pay to register an ID (it costs money to have a manufacturer ID), and the device is custom in such a way that there was no way to identify this for a generic driver. Some software provided by the manufacturer may be required to use this device.

Keep in mind that software which uses this ID 0001:0002 (Mfr=1, Product=2) may depend on firmware. Firmware essentially changes the API/ABI of hardware in the same way that a system library may get a major revision and only be compatible with software updated for that revision. Or the serial UART may need to be used to set up a correct state before software of Mfr=1, Product=2 will succeed.

So the question now is if you have firmware for this device (many devices do not load firmware) or some sort of software to use with the device? If you have software to run, keep “dmesg --follow” running to see output, and then report what the software (and log) does when running it (error messages or incorrect behavior). What is the software doing, and what should the software do?

I’ve been trying to install the VESC tool on my ubuntu laptop as per this guide but it’s saying I need to build it with Qt. I installed Qt but I’m not sure which file to select or how to build with it.

I’m still wondering why this issue is happening in the first place, the software I’m running has been commonly used. Would it be easier to just start from scratch or reflash a new kernel?

Thanks again.

Here’s what’s in the vesc_tool folder:
android lzokay res_original.qrc application main.cpp res_platinum.qrc bleuart.cpp mainwindow.cpp res.qrc bleuart.h mainwindow.h res_silver.qrc build_all mainwindow.ui setupwizardapp.cpp build_android map setupwizardapp.h build_cp_fw mobile setupwizardmotor.cpp build_lin packet.cpp setupwizardmotor.h build_lin_original_only packet.h startupwizard.cpp build_macos pages startupwizard.h build_win parametereditor.cpp tcpserversimple.cpp build_win_original_only parametereditor.h tcpserversimple.h commands.cpp parametereditor.ui utility.cpp commands.h README.md utility.h configparam.cpp res vbytearray.cpp configparam.h res_bronze.qrc vbytearray.h configparams.cpp res_config.qrc vescinterface.cpp configparams.h res_free.qrc vescinterface.h datatypes.h res_fw_original.qrc vesc_tool.pro digitalfiltering.cpp res_fw.qrc vesc_tool.pro.user digitalfiltering.h res_gold.qrc widgets LICENSE res_neutral.qrc

I see this documentation, but beware I have no experience with this topic:
https://vesc-project.com/node/178

Looks like there may be a firmware update. If this is so, then any update might work from another computer if the device stores the update itself. If a firmware update is loaded at each boot, then you’ll need the firmware on whichever platform the firmware loader runs from.

Is this tool running on the Jetson, or is it to run on an Android phone/tablet? From what you’ve said I am guessing you are trying to build this to run directly on the Jetson, but I want to confirm.

I could not tell you what is needed to build this on a Jetson, but Qt has been added and used by many users. This does not mean it was “easy” to do, but if you give more details about this, then someone who has used Qt to build on a Jetson can likely help. Sometimes it is a case of getting the right release of Qt (which can be an adventure in itself since some releases are commercial pay depending on circumstances).

NOTE: You will want to provide any build commands and any error logs from the build, along with what you’ve installed related to Qt itself.

The tool is running on Jetson. The trouble with Qt only happens when I try to run the tool on my Ubuntu laptop, but the tool seems to run just fine on Jetson. I monitored “dmesg --follow” on the Jetson when I run the VESC tool and nothing seems to happen.

I’m going to try installing a different version of this VESC tool per this guide from Jetsonhacks. Although it says it’s meant for a newer version of Vesc firmware (I’m running 4.12) I see the 4.12 firmware files in the repo so it might work.

That is probably your best bet.

FYI, it would be an interesting test if you could ssh from your laptop (which it works on) into the Jetson with “ssh -Y …”, where the “-Y” causes forwarding to the laptop for X GUI events. The result would be that the core program runs on the Jetson, but the GUI requirements offload to the laptop. If this works, then it means your issues are entirely GUI related. If this fails, then it probably means something else is going wrong before the GUI ever starts.

Ok I setup the Vesc tool on my Ubuntu laptop. Apologies for the delay.

When I first plugged in the Vesc before running the tool everything showed up fine in “lsusb” and “ls /dev/tty*”. But once I tried to connect to the serial port it had an error and told me to install a setting (can’t remember which) and reboot.

Once I logged in again I immediately got errors on dmesg --follow and the device wouldn’t show up in lsusb or /tty anymore. Here’s the error msg:

Thanks again.

Those errors are from USB failure. That failure is more “generic” than anything related to the serial UART itself…the USB pipe failed before even getting a chance to understand what the USB device was. If you unplug this USB device, does the error go away?

I’m guessing removing the one USB device causes the error to stop. Can I verify if this error was on the laptop, or if this was on the Jetson (e.g., perhaps you are using the Jetson directly, or Jetson through laptop)? We will need to know exactly what USB devices are plugged in where, and if you were running through “ssh -Y”, serial console, local GUI, so on. Any USB HUB should be mentioned as well.

Not sure, but how is powered your device ?
The attempts to power cycle might tend to wonder for external powering.

[EDIT: Also remember that in older releases usbcore.autosuspend was messing with some ttyACM devices and disabling it in kernel boot args was solving this. Maybe no longer useful, but if out of ideas you might try, or someone may update the status of this]

I finally got it! Looks like it was a loose usb port in my laptop where every time the cable would move around it would disconnect. I managed to successfully flash the new firmware via the vesc tool on my laptop, and now it finally shows up in /dev/tty* as serial ACM4 on my jetson.

The next step is figuring out some install issues I’m having with ROS (do you have any experience with this?). But this is finally fixed.

Thanks so much for your help and I really appreciate all the time and thought you put into your advice.

1 Like

Thanks for the advice @Honey_Patouceul, looks like it was partly due to a loose usb port on my laptop. I got it working.

Sorry, I have no experience with ROS. You could start a new topic though since many readers here do have ROS experience.