Open oktokl opened 1 year ago
Hi @oktokl! We appreciate you submitting your first issue for our open-source project. π
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. π€π
@loicpoulain Would you have time to take a look ?
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
@oktokl i confirm that when we send a packets >= 64 bytes it doesn't works with the nucleo_h723zg in fact the nucleo_h723zg use Otg_HS and not Otg_FS to increase the length of the packet you must enable the CONFIG_USB_DC_HAS_HS_SUPPORT=y after that in my case i can send more than 64 byte for example 101 bytes see after:
and in debug mode see the console ( first 64 byte and after 37 bytes)
I read that the host must also manage the ZLP ( zero length packet).
@oktokl We consider this is closed by https://github.com/zephyrproject-rtos/zephyr/pull/66692. Please reopen if it is not the case.
I reopened this issue because the proposed solution caused a problem with the WebUSB sample.
Enabling the CONFIG_USB_DC_HAS_HS_SUPPORT flag with the current OTG_HS configuration leads to issues with USB.
We may need to add an external ULPI PHY to support High-Speed USB operation to be able to set CONFIG_USB_DC_HAS_HS_SUPPORT without having any issues with High-Speed USB operation.
Describe the bug When I send packets >= 64 bytes to the USB CDC ACM sample, I either get no reponse or get one after several more transmission without response.
To Reproduce Steps to reproduce the behavior:
Expected behavior USB full speed packets have a maximum size of 64 bytes. Data packets >= 64 bytes are assembled out of multiple USB packets. The sample should handle this packets or at least the receiver shouldn't stop working.
Impact In case it is the usb cdc implementation, it's really bad if it can be put in a freezed state. Also, in order to reach high data rates, it's generally a good idea to transmit big packets. Actually, that seems not possible.
Logs and console output Here are different outputs of SerialTest and the corresponding traces: wireshark-trace.zip The traces show that the sample application successfully echos the first 64 bytes of the first 64+ bytes packet. After this reponse, rx doesn't accept any further packets.
Packet size 63 (working)
Packet size 64 (not working)
Packet size 65 (not working)
Environment (please complete the following information): Platform: nucleo_h723zg; full speed usb interface with internal PHY Host: Windows 10 Pro 22H2 Zephyr version: v3.4.0