Posted on March 03, 2012 at 06:09Hi All
I thought that I had managed to tame the USB FS device, but I was wrong. There is one simple thing that is not working and it is so simple that it seems impossible to solve...
I have a CDC class operating. Enumeration is OK and IN and OUT data exchanges work on the bulk endpoints. This links a UART to a virtual COM port (classic use of CDC) but I noticed that the UART baud date was not getting set correctly - this is set when the terminal emulator connects to the virtual COM port or when its settings are changed.
This is a simple SETUP (set line coding [0x20]) on endpoint 0 followed by a DATA packet with 7 bytes of data containing the settings.
After a few minutes of debugging it became obvious that the received data packet was incorrect. It was also quite clear that only 3 of the 7 expected bytes were in the input buffer. Seemed like something small but after several hours of low level debugging it has turned out to be something so small that it is invisible...
Any help on the following finding?
1) The first thing that happens is that the standard SETUP packet is received (popping the RxFIFO status gives the expected [OTG_FS_GRXSTSP = 0x014c0080] type status (SETUP with 8 bytes)).
2) The 8 bytes are extracted from the FIFO as normal and it is seen that it is a Set Line Coding with extra data so nothing more is done at the moment - the interrupt is quit.
3) Then something unexpected happens. The following interrupt signals the next another RxFIFO event but its FIFO status is invalid - [OTG_FS_GRXSTSP = 0x02000680] (this would be 0x68 bytes received and an invalid bit set and also an invalid reason). This is ignored (if the FIFO status is not popped the interrupt is not cleared though). [I did try to see whether there was some data to be read from the RxFIFO when it arrived but there wasn't - it just returned some pattern similar to reading when no data is waiting].
4) After this, the expected receive FIFO interrupt arrives showing an OUT reception with 7 bytes - [OTG_FS_GRXSTSP = 0x01450070]. So the RxFIFO is read out but the first word read returns the last 3 bytes of the expected 7 (the first 4 are not there) and the second word read returns something that has nothing to do with received data.
In fact a SETUP frame followed by a DATA frame is quite rare. USB-MSD, USB-HID projects don't encounter it on endpoint 0. It is only the USB-CDC Set Line Coding and (presumably) Set Control Line State (for controlling RTS/DTR) that are affected.
Endpoint 0 has been setup with large FIFO size (64 words) and also configured for reception of 3 back-to-back SETUPS. The SETUP reception causes just extraction of the SETUP data and no other register accesses that could go wrong. The behavior is consistent and I haven't been able to change it by whatever tricks I have been able to think up just yet.
Is there maybe some (bad) configuration setting that could cause this behaviour or could it be a problem with the USB controller? Is there an example of working USB-CDC supporting the line settings??
Regards
Mark
#usb-cdc #utasker #stm32f4-usb-rxfifo-[solved] #usb-otg-fifo-extra-bytes-trdt
