Tracing the TX code it indeed looks like the TX path just sets up some memory values, and does not do any obvious hardware interaction, so something is monitoring those values (struct members) and kicks off the TX.
It is like ETH, where the 32F4 ETH controller is continually monitoring some pointers in a linked list of packets, to see if any new ones have been left there. I spent a whole load of time there too but that now seems to be all working fine. (Actually I have some questions on that which I will post separately).
The TX path is
CDC_Transmit_FS
USBD_CDC_TransmitPacket
USBD_LL_Transmit
HAL_PCD_EP_Transmit
and in there, just some hpcd-> value gets set
so "something else" is monitoring the memory. And presumably enabling the interrupt you mention.
I would happily test out suggestions for any low hanging fruit but I am out of ideas : - )
I doubt the RTOS is at all relevant, except to the extent of exposing an issue via timing being "just right".
The 1st keystroke, always corrupted in CDC_get_rx_bytes, is delivered correctly into fred1234[0] here. I trigger the breakpoint, line 984, with "3" on the terminal, and this enables it to isolate the issue
This is CDC_get_rx_bytes:
It is all the stuff in between where I struggle to find the data. Various buffers get passed by address.
AFAICT the data (the byte, and count=1) is right oin here (called from an ISR) and USBD_CDC_DataOut returns the right data also.
OK, found it and fixed it. It was junk in CDC_Receive_FS().
Various junk, but most notably it was enabling reception of next packet before reading out the previous one. Most of the time this would work (and did) unless the RTOS got in just at the wrong point and delayed things just long enough.
Final code:
One ISR loads data into a 64 byte linear buffer and another ISR calls (eventually) CDC_Receive_FS() where in the above example this buffer gets copied into a 1024 byte circular buffer. This is the flow:
"Even a single fact that the ST's USB stack does everything in interrupt context is enough for me to never use it."
On the one hand you have a go at me for polling ETH RX and on the other you say the above.
In the end it turned out that the USB CDC "OUT" ISR chain was delivering the right data all along.
My criticism of "HAL" is that it has poor granularity. All the code is basically bloated. But it shows up especially in the ISRs, which people rarely look at because by their nature they are convoluted, and interrupt generation (IP bits) behaviour is often nontrivial. ISR-driven software tends to be convoluted anyway. It is only when one starts to step through one of the ex-MX generated ISRs that one sees just how bad it is. It is stepping through a large number of possible int sources (most of which are not enabled anyway). They get away with this at 168MHz and 1 clock per cycle... You would never write ISRs that way yourself; it would do only what is needed and then gets out of there.
Also a lot of the code comments are simply wrong - probably due to the coder not speaking English.
