Where are the hub and serial device drivers in Linux and have you ever seen a serial TTL adapter cut off data after some period of time

Question

This question will be difficult to fully explain, I apologize in advance, but please read the entire description? Thank you.

NOTE: I'm primarily posted this to document it, and only asking for advice on how to identify the part of the Linux image that needs to be updated to fix this issue, and perhaps someone will have seen it and have a workaround. I've never seen a problem like this in 30+ years of working with serial TTL communications.

I have an embedded board which can not be easily updated for security / bandwidth reasons. Small updates my be possible but aren't the goal. More than fixing it, I want to understand what part of the system contains these drivers for my own education. I don't only want to solve the issue, I want to understand the issue.

This board has a USB connector and I can plug in different devices and they generally work. e.g. keyboard, wifi adapter, so on.

One type of device I have commonly used is a serial TTL adapter when I want to talk to an external serial device (e.g. Arduino or whatever).

When I plug those adapters directly into the USB port, they work flawlessly. I normally use CP210x, most often CP2102 / 2104, but have used CH340s, FTDI, etc... no problems.

Recently I had an application where I wanted two USB devices at the same time so I added a small USB hub. With the serial TTL adapter plugged via the HUB, I find that any data being sent after about 678uS is cut off. (!?)

For example, this screenshot of a set of scope traces shows, in grey, the trace when I have the serial TTL adapter plugged in directly, and the blue trace shows when it is plugged in via the hub.

Screenshot of scope traces showing the issue

As you can see, the data cuts off mid byte. Later measurements showed that time to be consistent +/- about 20uS irrespective of data length, or baud rate.

This happened x3 hubs, and x3 adapters.

I tried powering the hubs. One came with its own adapter, another had a standard power in connection, and the 3rd had power pins which I connected to the bench supply. This made no difference.

This is not RS232 so there is no charge pump failing. I've monitored the power supply on the chip and there is no loss of power.

The same hubs and adapters work perfectly when plugged into a PC x2 operating systems (Ubuntu 20.04, Windows 11).

My assumption is that there is a problem in the USB driver in the embedded image. Again, I can't update it, except in small ways, and my real goal is to understand the issue anyway.

• The actual question: What part of the Linux stack controls this?
• Extra credit: How would you update only that part?
• Extra extra credit: Have you ever seen that before?

Answer 1

The work needed to discover where the problem is in the Linux kernel is going to be very large. If you find it, fixing it will need you to recompile the kernel. You would need to have the exact version of the sources currently in the embedded device, and its build environment (compiler and so on). [This is one of the reasons why Yocto has become so popular for this sort of hardware, as it can allow you to retain a snapshot of all that is needed to rebuild something].

The ideal way to proceed would be to reproduce the problem on a board or PC on which you can easily download and try out different kernel versions, until you find the two closest versions that have and don't have the problem. You can then review the differences in the kernel sources for clues on what was fixed.

To just browse the sources and try to identify the problem, you can find the host hub drivers at ehci-hcd.c for USB2, and xhci-hub.c for USB3. The generic external hub driver is at hub.c. The usb-serial adapters are for example ch341.c. The above urls allow you to change to a different version of the kernel. You may find the filenames have changed if you go back to earlier versions of the kernel. There is some documentation on the usb code here.

You can find the same files on github, for example ch341.c, and if you click on the blame button, you can get an annotated listing where the reason for each line's current content is given. The history button provides the list of changes. You can use git to download this kernel tree locally, and git tools to search through the commit changes and extract a given version of the sources.