Skip to main content
waldi
Associate II
August 9, 2019
Question

USB STM32F407 VCP Bidirectional communication bare metal?

  • August 9, 2019
  • 10 replies
  • 2147 views

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

DIEPINT_XFRC

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

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

send command from PC to uC-> receive data block

...

everything is working fine.

This topic has been closed for replies.

10 replies

waclawek.jan
Super User
August 10, 2019

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

JW

waldi
waldiAuthor
Associate II
August 12, 2019

bmRequest     2   

bRequest       1   

wValue       0   

wIndex      129   

wLength       0   

waldi
waldiAuthor
Associate II
August 12, 2019

@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.
August 12, 2019

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
Super User
August 12, 2019

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
waldiAuthor
Associate II
August 12, 2019

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

0690X00000A9QZUQA3.png

waldi
waldiAuthor
Associate II
August 12, 2019

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

waldi
waldiAuthor
Associate II
August 12, 2019

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!)