TriEndpointInterface, cdc=True, not working nicely with TinyUSB

[gregdavill]

Hey, I've been trying for a couple of days to get the TriEndpointInterface with cdc=True working on an ECP5 platform, vexriscv CPU running at 75MHz.

Enumeration seems to work flawlessly, so I'm confident that clocks and i/o are setup correctly.

The issue is when running a simple TinyUSB example, cdc+msc.
I can open a minicom session and talk to the board, (sometimes dropping out). The msc device, however just never enumerates.

.547696] usb 1-1.2: new full-speed USB device number 80 using xhci_hcd
[118963.662597] usb 1-1.2: New USB device found, idVendor=cafe, idProduct=4003, bcdDevice= 1.00
[118963.662603] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[118963.662606] usb 1-1.2: Product: TinyUSB Device
[118963.662609] usb 1-1.2: Manufacturer: TinyUSB
[118963.662612] usb 1-1.2: SerialNumber: 123456
[118963.677026] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device
[118963.678086] usb-storage 1-1.2:1.2: USB Mass Storage device detected
[118963.678593] scsi host2: usb-storage 1-1.2:1.2

If I turn off cdc, and set my cpu_freq to 12MHz then it works as expected.

.716574] usb 1-1.2: new full-speed USB device number 81 using xhci_hcd
[119002.836084] usb 1-1.2: New USB device found, idVendor=cafe, idProduct=4003, bcdDevice= 1.00
[119002.836090] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[119002.836094] usb 1-1.2: Product: TinyUSB Device
[119002.836097] usb 1-1.2: Manufacturer: TinyUSB
[119002.836100] usb 1-1.2: SerialNumber: 123456
[119002.852608] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device
[119002.853709] usb-storage 1-1.2:1.2: USB Mass Storage device detected
[119002.854193] scsi host2: usb-storage 1-1.2:1.2
[119003.865558] scsi host2: scsi scan: INQUIRY result too short (5), using 36
[119003.865569] scsi 2:0:0:0: Direct-Access     TinyUSB  Mass Storage     1.0  PQ: 0 ANSI: 2
[119003.866169] sd 2:0:0:0: Attached scsi generic sg3 type 0
[119003.866970] sd 2:0:0:0: [sdd] 16 512-byte logical blocks: (8.19 kB/8.00 KiB)
[119003.867360] sd 2:0:0:0: [sdd] Write Protect is off
[119003.867367] sd 2:0:0:0: [sdd] Mode Sense: 03 00 00 00
[119003.867666] sd 2:0:0:0: [sdd] No Caching mode page found
[119003.867677] sd 2:0:0:0: [sdd] Assuming drive cache: write through
[119003.897260]  sdd:
[119003.901156] sd 2:0:0:0: [sdd] Attached SCSI removable disk

Any insights as to what might be going wrong here?

[mithro]

@xobs any thoughts?

@gregdavill - I would probably suggest spending your time on looking into LUNA rather than ValentyUSB.

[mithro]

It should have a compatible EPTri interface - https://luna.readthedocs.io/en/latest/gateware/endpoint.html#usb2-interfaces-eptri-components.

[gregdavill]

Looking at the sim output, when adding the cdc elements some critical timing, like async FIFO resets, can take upto 2-3 clocks in the slow domain. Which might require changes to the the TinyUSB EPTri interface. I did try some crude spin_wait() for 100 cycles after these calls, but it didn't appear to help.

I assume for betrusted, they're using a different USB stack in Rust.

@gregdavill - I would probably suggest spending your time on looking into LUNA rather than ValentyUSB.

I'll take a look. I think it was only recently Kate showed off a SoC demo. The main sticking point with LUNA on this project is a clean way to connect it to my LiteX project, and have the CSR registers all working.

[xobs]

I believe it was @bunnie who added the CDC stuff, and as of right now Betrusted is mostly using the Dummy endpoint.

Are you running from XIP flash? If so, TinyUSB may be taking too long to respond. This was a common issue in the initial CircuitPython port, which I worked around by placing various calls in RAM.

[gregdavill]

Are you running from XIP flash? If so, TinyUSB may be taking too long to respond. This was a common issue in the initial CircuitPython port, which I worked around by placing various calls in RAM.

Not right now, it's all in BRAM based ROM, so it should be just as fast as from RAM.