0 Members and 1 Guest are viewing this topic.
Are you using ping-pong buffers?Direct to port connection, i.e. no hubs?
I had a bunch of issues with ST's USB driver. It isn't really interrupt or multi-thread safe, and it would lock up on me with bidirectional traffic - that is, no transaction completion interrupts would fire after a few packets going both directions at the same time.I wrote a small new usb stack here with a H750 driver: https://github.com/jacobschloss/libusb_dev_cpp, https://github.com/jacobschloss/libusb_dev_cpp/blob/master/src/driver/stm32/stm32_h7xx_otghs2.cpp. It actually was also for a USB CAN adapter, coincidentally - https://github.com/suburbanembedded/hadoucan-fw. I have it working in HS mode (external PHY), haven't bench marked but its pretty fast, keeping up with 12Mbps CAN FD.So, it could be ST's driver.
HS has the advantage of being able to transfer 512 bytes from an bulk endpoint rather than 64 bytes. The Usbd_cdc descriptor is now set up for 512 bytes. I'm not sure how the stack performs if you still attempt so transmit 512 or 2K at a time.
.. it is not a joy to route high speed signals on a custom board...Did you use more then 3 endpoints or dma ?
I'm not sure how the stack performs if you still attempt so transmit 512 or 2K at a time.
What are you using to receive the Virtual COM with?
https://github.com/suburbanembedded/hadoucan-fw. I have it working in HS mode (external PHY), haven't bench marked but its pretty fast, keeping up with 12Mbps CAN FD.
Another interesting example for USB connection is the TeensyUSB stack for STM32 inc. H7.