Beagle analyzer shows orphaned packets when using CDC ACM interface

[jeremyherbert]

Beagle analyzer shows orphaned packets when using CDC ACM interface

[jeremyherbert]

The situation seems to improve if use usb_serial.tx.first.eq(0), there are still some orphaned packets but far less. However, this comment: https://github.com/greatscottgadgets/luna/blob/c7617ec7b7903a6d8e1fa4f4a637bbfedb2b0616/luna/gateware/usb/usb2/transfer.py#L39C30-L39C30

seems to imply that first is unused, so I'm even more confused now.

[zyp]

Hi, can you try doing a sequential mode capture with the beagle? The captures you've attached are aggregate mode which discards some details, making it hard to see exactly what's going wrong.

[jeremyherbert]

This one has tx.first and tx.last tied to 1 (there are a lot more errors than previously for some reason):

luna_usb_serial_sequential.tdc.zip

Is this the correct format?

[zyp]

Yes, thanks. The packets that's showing up as orphaned are IN requests from the host without a handshake from the device. Normally the device should reply NAK to every IN token it receives when it doesn't have any data to respond with, but in the capture roughly one in two thousand IN tokens on average doesn't get a reply.

I believe this is a lower layer problem than the FIFO signals you've been experimenting with, and wouldn't expect them to actually affect the behavior.

The reason the data is still coming through fine is because this is well within what USB's error handling can deal with and recover from, but the rate this is occuring at still suggests this is a problem that should be tracked down and fixed.

I'll try porting your code to one of my boards here tomorrow and see if I can reproduce the issue.

[jeremyherbert]

Thank you. Please let me know if there is anything I can do to help test - I'm not too comfortable with the deeper internals of this code but happy to do what I can.

[zyp]

I'm unable to reproduce your issue, it's behaving fine here:

Statistics shows no missed replies to over 10M IN requests:

I'm testing on a colorlight i5 in a custom carrier board with a FS USB connector and apart from changing the PLL config to account for the input clock being 25 MHz instead, I'm running the exact code you provided.

[jeremyherbert]

Well this is embarrassing... It appears that the USB-C cable I was using was causing signal integrity issues. I have changed to a known high-quality cable and now everything works fine.

I will close this issue. Thanks very much for the reproduction attempt and sorry for wasting your time.

[straithe]

Thank you for the update. We're happy that you were able to find a solution!