dwc_otg rpi3b+ 4.14.52-v7 usb/serial dropping data #2687
Comments
|
I'm having a potentially related issue with USB MIDI. I get dropped events resulting in stuck notes or missed control messages. This is a low speed device. It does not seem to matter which port it is plugged into. I'm running 4.14.70-v7+ Dmesg contains nothing interesting when packets are dropped, but the device info on connect is: |
|
If any admins have suggestions as to how I can further debug this, I would be more than happy to assist. |
|
Can you add the parameter |
|
I tried it with both configurations. Stuck events persisted in both cases, did not observe any difference in frequency or severity versus no nak_holdoff value set. |
|
But, did you mean |
|
Typo. It needs to go in /boot/cmdline.txt. |
|
Ok I’ll rerun these tests with that in cmdline.txt shortly. |
|
Good news: nak_holdoff=1 improved it significantly, but still a very few dropped events. holdoff=0 seems to have fixed it entirely, although I only gave it about 5 min of good data. That said, it's a clear and marked improvement. Does this help you figure out where the problem is, and is it possible to fix it so we can effectively guarantee that we'll never lose an event using these low speed devices? Is there any negative side-effect of keeping nak_holdoff=0 in the meantime? Thank you! |
|
Unfortunately neither setting of nak_holdoff has made a noticeable difference to my situation. Still seeing sequences of 16 byte messages returning. |
|
@edwar64896 just checking you put that in |
|
@malacalypse What baudrate is in use with your device? You run into this issue if you fill the device's internal receive FIFO within the 1ms hold-off window, so it's a function of device FIFO size and incoming baudrate. |
|
@P33M I'm not using a serial device - just class-compliant MIDI and audio stuff. |
|
MIDI is 31250 baud. |
|
Not over USB, there are no limits. That's only for DIN serial MIDI. https://www.usb.org/sites/default/files/midi10.pdf : "The USB transfers MIDI data at rate hundreds of times faster than the original MIDI 1.0 hardware specification." (section 2) USB MIDI is true USB, not USB->Serial. Devices consuming the MIDI commands MAY implement a serial converter with the downstream data but that will not be visible to nor operating on the USB bus directly. |
|
Ah it's an Arturia Keystep device. Previous testing with these devices has shown that they do not have any internal buffering past the 64-byte maximum packet size - so any data generated by key events that exceeds 64 bytes in size since the last time the endpoint was polled results in data loss. Setting dwc_otg.nak_holdoff=0 in cmdline.txt is recommended if you're using devices from this manufacturer. Still waiting for confirmation that this has changed the behaviour on the other device... |
|
@malacalypse yes the kernel configuration parameters have always gone into /boot/cmdline.txt |
|
I'm pretty sure that the device I am using has an internal hub as the usb gadget function it exposes is switchable in the config. You can either have it running as a serial device or as a mass storage device. Will this affect the way that the RPi sees it? |
|
@P33M Ok, good to know, and thank you for the explanation. With this configuration my setup appears stable, so I'll continue with that! |
|
Update: Ok so to keep things moving, I built an RS232 to TTL converter, enabled the onboard UART and connected it all up via the onboard UART. Situation is much worse than with the USB! literally every single packet is losing data. Does this give anyone any more of an idea as to what is happening? I am completely stumped. |
|
That doesn't sound right. The BCM2835 family of devices have 2 UARTs:
UART0 is normally used for Bluetooth on Pis that have it, otherwise it is the console UART. /dev/serial0 is (by default) an alias for the best available UART. You can swap the roles on a BT Pi and free UART0 for other applications with either Pi 3's BT didn't wire up the flow control signals to the modem for pin count reasons, and we found that 921600 baud was about the highest we could run UART0 reliably (this was after I fixed a few bugs in the UART driver). For UART1 we settled on 460800 baud. On Pi Zero W and 3B+, which have RTS and CTS connected, you can run UART0 at 3Mbaud with no loss of data. Using an overlay or some GPIO manipulation program (e.g. |
|
I spoke a bit too soon. I still have significant drops when I have the MIDI data go in the Keystep, out to another device (like a sequencer), back in from that device, and out again to the ultimate synth endpoint. So it seems like the timing on the USB interface has a strong effect on the reliability of the bulk data transfer here. If I get time I'll drop back a few kernel versions to see if that solves the issue. |
|
@P33M Any recent changes that may have helped here? This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested. |
JamesH65
added
Close within 30 days
|
Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant. |
I am interfacing with a device which exposes a serial interface over USB. I am regularly seeing data being "lost" or "dropped" in the kernel/driver layer. Attempts to use some of the dwc_otg configuration parameters are yet to be fruitful.
When I get a chance I'll post lsusb and dmesg dumps from the box in question. the serial device is a cp210x chip. The code is attempting to read a sequence of 17 bytes, however intermittently only 16 bytes are being received for the message string in question. This causes the high-level code to fail a checksum check. The same codebase has been used on a x86 machine with no issue. The USB layer in the RPI just seems to be randomly discarding bytes.
dmesg.txt
lsusb.v.txt
The text was updated successfully, but these errors were encountered: