Old data in endpoint is retransmitted

[cuwittrock]

Hi,
I have a problem with (IN) data being retransmitted unwantedly. I am using TinyUsb version 0.18.0 on the STM32C071KB. The device is set up as CDC and I am running without an OS, so I poll TinyUsb for e.g. free space in endpoint TX FIFO. It seems as if TinyUsb keeps the endpoint as valid making the Host pulling the same data multiple times. Does not happen every time but perhaps 1 out of 50 request/response pairs.
After each call to 'tud_cdc_write' I call 'tud_cdc_write_flush'. I have checked that my application only receives data a single time and only tells TinyUsb to send the response a single time. There is never a problem with receiving data - only sending to Host.

The USB block is clocked with HSIUSB48 and with CRS activated. Taken from STM example it should be synching to SOF and use an error limit of 34 (from STM USB HID example)

I am wondering if I could be doing something wrong, or if there could be a bug in TinyUsb?

Kind regards,
Christian

This is a raw dump from Ellisys USB analyzer:
// Normal OUT packet transmission
RawPacket data<C3 C0 08 01 14 12 08 00 00 00 06 00 00 00 2B 68 03 43 2B 60 07 F0 47 FA 33 00 4A 33 1B 78 00 ......> speed time<3.518 270 617>
RawPacket data<4B 2A 39 D0 01 99 07 22 01 29 3D D0 59 78 3B 00 13 40 8B 42 34 D0 3B 09 1A 40 91 42 05 D0 26 ......> speed time<3.518 322 100>
RawPacket data<C3 49 24 48 07 F0 4B FA C6 E7 23 00 0F 3B 01 2B C2 D9 F4 E7 80 23 02 9A 1B 04 1A 43 02 92 BB ......> speed time<3.518 564 783>
RawPacket data<4B 9B 01 33 03 93 7B E7 5B 78 3A 40 9A 42 F7 D0 01 9A 08 34 A2 40 1B 01 1F 43 17 43 02 23 EE ......> speed time<3.518 713 150>
RawPacket data<C3 B0 F0 BD DB DC 46 B8 95 01 08 00 04 00 50 74 00 C0 09 DB> speed time<3.519 554 233>
// Normal IN packet as response to the OUT packet
RawPacket data<C3 C0 01 00 15 12 00 1D 96 C0 21 F6> speed time<3.522 834 667>

// Next OUT packet transmission. Starts as expected but then a spurious retransmission of the previous IN packet appear out of the blue
RawPacket data<4B C0 08 01 14 12 08 00 00 00 07 00 00 00 4C AF 01 08 A5 AF 01 08 9F AF 01 08 00 24 01 40 08 ......> speed time<3.523 845 950>
RawPacket data<C3 6C 1A 60 1F 4B 9A 68 0A 42 06 D0 10 22 98 68 02 43 9A 60 9A 68 0A 42 FC D1 02 22 99 68 0A ......> speed time<3.524 742 617>

// Unwanted IN packet containing the response from the last OUT/IN transmission. This is an unwanted retransmission as the original transmission was received successfully
RawPacket data<4B C0 01 00 15 12 00 1D 96 C0 21 F6> speed time<3.524 834 567>

RawPacket data<C3 6C 1A 60 1F 4B 9A 68 0A 42 06 D0 10 22 98 68 02 43 9A 60 9A 68 0A 42 FC D1 02 22 99 68 0A ......> speed time<3.524 854 183>
RawPacket data<4B 60 99 62 19 68 11 42 FC D0 00 22 27 00 0E 4B 36 37 1A 60 39 78 E0 6B 03 F0 0F FF 39 78 E0 ......> speed time<3.525 487 767>
RawPacket data<C3 01 08 00 24 01 40 FF 7F FF FF 08 27 01 40 4C AF 01 08 C7 AF 01 08 15 4A F8 B5 13 00 37 30 ......> speed time<3.525 555 800>
RawPacket data<4B 07 F0 49 F9 33 68 BC 43 2B 43 33 60 33 68 9B CC C0 2F BC> speed time<3.526 560 550>

// Response (IN) should been here. Instead a new request is sent because the Host application has seen the out-of-order response but still accepts it as valid

// Normal OUT packet transmission
RawPacket data<C3 C0 04 00 0C 12 09 00 00 00 19 56 C0 2F 6E> speed time<3.528 436 467>

// Here is the real response, which comes after the next request/response pair is ongoing. Host started this transmission because it saw the wrong response packet and took it for the real
RawPacket data<C3 C0 01 00 15 12 00 1D 96 C0 21 F6> speed time<3.531 834 217>

// Normal IN packet as response to the OUT packet
RawPacket data<4B C0 28 00 0D 12 80 2E AA DB DC 00 D0 FF 1B 29 4B 52 88 D1 AE 14 21 EA DF 5B 2D 38 A8 75 2B ......> speed time<3.539 615 833>