FTDI Usb to Serial Converter issues1KHz interrupts on cRio-9068 per channel

[WillsG]

We are using compactRio-9068 platform with RT Linux 2013. We are connecting one off-the-shelf USB to 4 port Serial converter device to cRio-9068 over USB bus. After plugging this serial converter device, we could see 4 serial ports as /dev/ttyUSB0 to /dev/ttyUSB3. The device uses FTDI FT232 chipset. We could see that cRio loads usbserial and ftdi_sio driver modules to support these usb to serial devices.

However, when we open any of these serial ports from SW application to connect to other device, we see around 1KHz interrupts "ehci_hcd:usb1" on CPU-0. These interrupts are seen continuously even when we don't send any command on that serial port. In fact even if we open the serial port without any end device connected to it, we still see these interrupts. These soft interrupts takes around 2 to 3% of CPU system time in kernel mode per channel for servicing them. In our final form system we have use 8 usb to serial channeled ports which provides around 8KHz interrupts and takes around 15 to 20 % of CPU in system usage mode and also impact our SW stability. Closing the serial ports from SW will stop the ehci_hcd interrupts for that channel.

On contrary, I tried to open /dev/ttyS1 which is true serial port on cRio-9068 and behavior there is pretty stable. We only see few interrupts on 'serial' interrupt line only when we talk to that device. Not sure why USB to serial driven port will have high rate of interrupt issue.

I wanted to know what is causing this high rate of interrupts. And if there is any way we can disable them and still have usb to serial mapped ports for our use?

[BradM]

I would guess that the fact of the matter is that USB, as a bus, is not device-interrupt-driven is to blame. USB events from the device must be polled from the host controller (in this case, the UBS host controller interface on the 9068).

http://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt

Normally, this is handled by the UHCI hardware, only interrupting the CPU when there's need for CPU intervention. However, digging a bit deeper into the Zynq technical reference manual (UG585), section 15.11.2, full- and low-speed devices are not handled by the hardware transaction translator unit. Checking the details of the FT232, it is indeed a full-speed USB 1.1 device. This means that the hardware meant to manage the basic operations are not handling the needs of these lower-speed devices, instead depending on the interrupt and DMA subsystems to hand off the needed bits to the kernel for it to handle.

In comparison, there is indeed an interrupt line from the dedicated 16550-compatible serial UART that drives the built-in serial ports on the controller.

[WillsG]

Thank you, BradM for the information.

What I understand from the above explanation is - it is not possible to stop those interrupts coming over ehic_hcd:usb1 line as devices will keep handing off the needed bits to the kernel through interrupts and associated DMA transfers. In that case, is there a way to lower the interrupt rate by some means? any ftdi_sio serial driver/module options (inputs) to make it happen? We can live with some reduced rate as currently for 8 channels we are seeing around 8 KHz interrupts hogging the CPU time significantly.

[BradM]

Since we're working with USB full-speed devices, part of the USB standard is to have the controller send Start-of-Frame packets at 1kHz. If we're talking about needing to talk to 8 full-speed devices, I don't think there's a way to work around this issue (it is part of the USB standard).

[WillsG]

Thank you, BradM for the information.

[BradM]

The only recourse you may have to help out the situation would be to try to track down a USB 2.0 USB to serial adapter. This is going to be a bit tricky since you don't really need the speed of USB 2.0 for most serial applications, so most chipmakers don't bother with anything better than a full-speed USB device.

While I cannot verify, it seems that, if you can track down something that uses the FTDI 2232H IC, that would take advantage of the EHCI TT on the Zynq, preventing the CPU from being interrupted.

[DAQjr]

Another option is to use a USB 2.0 hub between the serial devices and the controller. This should expose only 2.0 signalling to the controller, thus avoiding the problem.

[WillsG]

BradM,

Yes, that might be worth to try. However, it is little bit tricky at our end. Especially by the fact that for 7 out of 8 channels which gets mapped as ttyUSB ports, USB to serial converter chip is located on a temp controller board which is 3rd party off-the-shelf HW. We only have control over type of USB to Serial converter device used for the remaining 8th channel.

Given the constraints, I am thinking to implement a strategy where we will open the ports and keep it active one at a time for duration required and close it after each command/reply cycle. This will involve lots of overhead through opening the port, setting serial settings and closing at the end of cmd/reply cycle. (We are estimating this operation will run at around 2 to 3 minutes interval). Not sure if there is a better option.

[WillsG]

Hi DAQjr,

The current hub we are using is with USB 2.0 with 480 Mbps max data transfer rate. It is backward compatible with USB 1.1. It appears to be constrained by the USB to Serial converter chipset which is FULL speed capable only.

[DAQjr]

Please see the Transaction Translator section of this article: https://en.wikipedia.org/wiki/USB_hub

If your hub is actually USB 2.0 high speed, then there should be no 12 MBit signalling that ever reaches the controller. That means that what BradM said in his intial reply does not apply to you.