STM32 OTG_FS GRXSTSP returns invalid data at bulk-out traffic

[MWebj]

I'm using a Nucleo-U575ZI-Q board to test Azure USBx MSC storage protocol strack against an Ubuntu-16.04 LTS host, using STM sample MSC code stripped down with a dummy interface against local storage.
A Beagle USB 5000v2 is connected between host and device so that I can capture USB traffic. Enumeration works fine and host starts to talk MSC to device over ep 0x01 and 0x81, probing it for number of LUN, capacity, test-unit-ready and so forth, but no request for media transfer (rd/wr). But with 100% certianty it fails on the 24'th command which is a MSC Test-Unit-Ready.

Bus analyser show that Command Transport packet is correct on the bus, and device endpoint has ACK'ed the packet. But when MCU calls HAL_PCD_IRQHandler() and reads out OTG_FS::GRXSTSP::EPNUM, it points to an unconfigured endpoint (usually 15). Also, very often, the PKTSTS field of GRXSTSP contain a value that acc.to speification is Reserved. One odd thing is that BCNT field is always 0x6b6 which is way off for what a FS bulk transaction can contain.

The only interaction USBx MSC protocol stack has with platform code up to the failure is to read some variables. Other than that it's only USBx code that handles command from host.

Also, if I instead test using a Windows-10 host, then it fails after 42 commands on a Read Capactity, but for the same reason.

U575 specification states in 72.15.10 OTG_GRXSTSP "The application must only pop the receive status FIFO when the receive FIFO non-empty bit of the core interrupt register (RXFLVL bit in OTG_GINTSTS) is
asserted.", but HAL_PCD_IRQHandler() checks status of RXFLVL bit in OTG_GINTSTS before reading OTG_GRXSTSP so that should not occur.

Is there some other way that fw could cause OTG_FS function in STM32U5xx to crash (which it obviously has done) ?

[MWebj]

Some additional info: On the first MSC command sent over bulk-ep 1 OTG_GRXSTSP::BCNT contains the value 0x1f which matches the length reported by my USB analyser, and this is the length read out by HAL_PCD_IRQHandler().

But the odd thing is that if I read OTG_GINTSTS::RXFLVL immediately after unmasking RXFLVL interrupt then it's still set even if STM32U575 specification in  72.11.1 says
"The application keeps receiving the Rx FIFO non-empty interrupt (RXFLVL bit in OTG_GINTSTS) as long as there is at least one packet available for download", and I can see on the USB analyser that there has not been any more bulk-out traffic after this packet. So how come that RXFLVL bit is still set when I have read out all data for the last packet on the bus?

[MWebj · Accepted solution]

Problem found. Was a misconfig of Rx fifo size