CDC-ACM: Dropped packets when talking with ESP32? (IEC-242) #104
Comments
github-actions
bot
changed the title
|
@xobs Thank you for the report. The logs indeed seem incorrect. Is it possible to share the code that handles |
|
I can share the entire repository: https://github.com/xobs/rocom This is built for a board that uses a pair of buffers for an external PHY, but if you have a setup that works with the internal PHY that could work as well. |
|
Without actually running the code, I found out that you send the data to rfc in the rx callback https://github.com/xobs/rocom/blob/main/main/serial_port_relay.c#L133 A cleaner solution would be to pass the data by copy to a queue and then send it from other task. The CDC-ACM driver will not resume RX transfers before the RX callback returns. Could you please try moving the |
|
Thank you for the mini code review. I assumed that since everything in that path is blocking, I shouldn’t have to double buffer in that way. Additionally, the CDC code doesn’t submit a new IN request until after the callback finishes, so the usb controller shouldn’t be requesting data on that bulk endpoint. if it were the case that it immediately requeues the transfer and overwrites the buffer then I could see that causing this behaviour, but if it’s doing that then things will very quickly get silently overwritten. what I really want is a usb protocol trace to figure out if the C6 is sending different data, or whether it’s the S3 that’s missing packets. |
This is true. Until the RX callback returns, you own the data and the CDC driver will not overwrite them. The issues is, that if you do no enable the RX path (by returning from the callback), the USB device can discard some packets (== the device will not send them to the host).
Here the only option is to use a special USB analyzer (such as Beagle 480). Could you please refactor the RX callback so it returns fast and report with your findings? Then we can proceed with the USB bus analysis on our side |
|
I've added a second thread and I now use a ringbuffer to pass data to it. The ringbuffer has a timeout of 5 ms, which may be a bit high but it doesn't get triggered at any rate. I will have access to a USB Beagle next week, so I can see if I can record some traces. But adding the ringbuffer does not make any difference that I can see. I also tried increasing the priority of the USB task, which also hasn't had an affect on things. |
|
The tag I tried getting the USB Beagle to work, but was unable to configure it with the PCB. I have a new PCB that I may be able to get working with the Beagle, but it still has the same issue wherein packets are dropped by the ESP32-S3: |
|
There's definitely a race condition somewhere. I've stuffed most of the relevant structures into RAM, and now I'm able to get a bit further, but it's very slow and data is still getting dropped: |
|
It's not a race condition. I finally got access to a USB Beagle, and I'm seeing data corruption. Some examples: Wire bytesReported by
|
|
In looking at this, I've discovered that the rf2217 server doesn't properly escape 0xff bytes. Additionally, it seems to do bytewise reception of data when receiving data. By properly escaping 0xff bytes and storing everything in RAM, I have it working now. I'm going to add batching support, at which point it'll start working. If you want to see an example of remote programming of ESP32 via USB, then https://github.com/xobs/rocom will be interesting to you. But for now, I'm going to close this issue since it's primarily an issue with https://github.com/igrr/rfc2217-server/tree/main |
|
@xobs Thank you for the investigation! This will be taken care of in the rfc2217-server repo! |
espressif-bot
added
Status: Done
Answers checklist.
Which component are you using? If you choose Other, provide details in More Information.
host/cdc
ESP-IDF version.
v5.5-dev-847-gcb3ac7429c
Development Kit.
Custom Board
Used Component version.
2.0.6
More Information.
The CDC-ACM driver appears to drop packets.
I have an ESP32S3 that I'm using as a wireless serial port adapter. It's connected to an ESP32C6 via USB. I'm using an external PHY, but the PHY appears to work fine.
As an example of what I'm seeing:
A bit of explanation:
The PC running esptool.py sends a SYNC packet which contains a bunch of
Ucharacters. The ESP32C6 then responds with its own SYNC packets (the second byte is0x01indicating it's a response). It sends two of these, and then stops responding.In contrast, when I connect the ESP32C6 directly to a PC,
esptool.pyreports the following:You can see the two packets in the first read, but the two 42-byte reads have been lost.
I'm not sure if the ESP ROM is sending bursts of 14 bytes, and the ESP32S3 stack is seeing the repeated packets and dropping them, but this occurs both if I use https://github.com/igrr/rfc2217-server/ to act as an rfc2217-compliant server (and use
esptool.py rfc2217://server:port) or if I do my own thing and usesocket://URLs and directly communicate by sending TCP packets in thecdc_acm_host_device_config_tcallback.The text was updated successfully, but these errors were encountered: