USB STM32F407 VCP Bidirectional communication bare metal?

waldi · ‎2019-08-09

I'm sending a continuous data stream from uC to PC via VCP which is implemented as CDC. During stream every responded IN token for EP1 generates DIEPINT_XFRC, so I'm seeing interrupts:

DIEPINT_XFRC

...

Now I send something to uC and get these interrupts:

1. GINTSTS_RXFLVL (GRXSTS_PKTSTS_OUT_DATA_RECEIVED)

2.GINTSTS_RXFLVL (GRXSTS_PKTSTS_OUT_TRANSFER_COMPLETED)

3. GINTSTS_OEPINT (DOEPINT_TRANSFER_COMPLETED)

thereafter again, the stream to PC

...

DIEPINT_XFRC

...

But sometimes (I thing if the OUT token is received at some wrong uC USB stage) i get:

1. GINTSTS_RXFLVL (GRXSTS_PKTSTS_OUT_DATA_RECEIVED) //ok

2. GINTSTS_RXFLVL (GRXSTS_PKTSTS_OUT_TRANSFER_COMPLETED) //ok

3. GINTSTS_OEPINT (DOEPINT_TRANSFER_COMPLETED) //ok

4. GINTSTS_RXFLVL (SETUP_DATA_PACKET_RECEIVED)

5. GINTSTS_RXFLVL (SETUP_COMPLETED)

6. GINTSTS_OEPINT (USB_REQUEST_CLEAR_FEATURE) <---

Why clear feature? It seems that the core is not acknowledging the last OUT transfer and PC tries to reset the device.

With limited transmission blocks from uC to PC:

send command from PC to uC-> receive data block

...

everything is working fine.

Pavel A. · ‎2019-08-09

Please look at this thread. Does it resemble your situation?

https://social.msdn.microsoft.com/Forums/en-US/b61dad9b-48f7-4eca-ab56-3c2ee92d62fa/windows-10-usbsersys-has-a-bug-it-corrupts-data-how-can-i-report-it-and-how-can-i-demonstrate-it

-- pa

waclawek.jan · ‎2019-08-10

What exactly is the content of the Setup packet arriving in 4.-6.?

JW

waldi · ‎2019-08-12

bmRequest 2

bRequest 1

wValue 0

wIndex 129

wLength 0

waldi · ‎2019-08-12

@Pavel A.

I don't know how to change "usbser.sys" to "winusb.sys", thus cannot test. But the error description seems very similar.

Pavel A. · ‎2019-08-12

Usbser and winusb are very different, one can just change one to the another. If you have similar issue with winusb, please report on the MSDN forum.

Regards,

Pavel A.

waclawek.jan · ‎2019-08-12

So it's CLEAR_FEATURE on the *IN* endpoint 1 of the ENDPOINT_HALT feature.

IMO the host (PC) sees IN EP1 returning STALL on IN tokens, so it attempts to clear the HALT state of that endpoint.

JW

waldi · ‎2019-08-12

It seems that there are 0x40 bytes missing in the last transfer so the host resets the endpoint.

waldi · ‎2019-08-12

Packet count is 1, that means one packet is still not emitted? It would explain 0x40 difference.

waldi · ‎2019-08-12

The mess starts if the OUT interrupt with 5 chars from PC is coming in during buffer load:

for (uint32_t i = 0; i < words_to_write; i++){
	*(USB).DFIFO[1]=USB_buffer[i];
}

I've deactivated OTG_FS_IRQn interrupt before load and activated it directly after - now the bidirectional data transfer is stable.

Hope this will help someone else!)