I'm looking for any pointers here on where to start debugging.
I have a composite device based on example code that implements CDC device + FATfs and MSC device. The FATfs and MSC are not active at the same time. The CDC is a gateway to SPI. Processor is STM32F769I on the discovery board.
When a remote processor is powered up the MSC reports "Media not present" and the FATfs is active. When the remote processor is off, the FATfs is unused and the MSC is active. That side appears to be working ok.
However, when the device is running and CDC <--> SPI is working ok I am intermittently getting port resets reported by the Linux kernel. When it reconnects, it is assigned a different /dev/ttyACM* number so the application loses connection.
I've traced this is Wireshark and the pattern of events seems very similar each time. I do not have a USB bus level sniffer to diagnose any deeper.
EP1 CDC control
EP2 CDC data
Wireshark seems to be showing a failed IN transaction from the MSC endpoint, it shows a message such as "protocol error" or "connection reset by peer"
then there's usually a failed IN transaction from EP1 "cannot send after transport endpoint shutdown"
Then a number of failed INs saying "No such file or directory"
Then the Host issues a port reset and enumeration completes and it works again for a bit. The processor is not resetting. USB_Init is not getting called. It is almost like the USB core gets stuck, but I don't know how to determine if that is true.
The incidence can be 5-15 minutes, it only seems to occur when CDC is active and MSC is in "Media not present" mode. The failure always seems to be from the MSC endpoint.
I had hoped that changing the TXFIFO registers (per my other post) would resolve this, but no change.
I have been delayering the code as I found it very difficult to follow and it has a noticeable performance hit. I can now understand the code better and MSC speed has improved, but the random port reset problem is still there.
In debugging I have caught an instance where a TXFIFO was partially filled and the code wasn't hitting the TXFE interrupt, but I'm hoping that problem was caused by the TXFIFO address/size registers being scrambled.
Any suggestions on where to start are appreciated.