AMIC110: USB FLUSHFIFO of RX double buffer

Hi Stan-san,

I understand.

Thank you very much.

Best regards,

Kibata

Hi Stan-san,

Please excuse me for asking another question.

If both buffer flashes are successfully flushed during a single FLUSHFIFO write, could it be possible that if the next packet is received during the second FLUSHFIFO write, its data would also be flushed?

I am concerned that a series of FLUSHFIFO operations may flush more data than the FIFO size.

Best regards,

Kibata

Hi Kibata-san,

As described in the TRM, FIFOFLUSH needs to be requested twice by SW in certain conditions: During endpoint setup

Here, SW must check for a packet in FIFO by reading RXPKTRDY bit. Therefore SW will skip the flush if there is no packets in the FIFO. It will also skip the second flush if a first flush succeeds.

Best regards,

Stan

Hi Stan-san,

Thanks for your reply.

Suppose writing to the FLUSHFIFO bit successfully flushes the buffer in one attempt.
If the next packet is received from the PC before reading RXPKTRDY, and the read result is 1, causing a second FLUSHFIFO write to be executed, wouldn't that packet also get flushed?

Best regards,

Kibata

Hi Kibata-san,

My understanding is that at this point the peripheral is still not configured and bulk transfers will not happen until the host also re-configures it's endpoints.

Speaking about controller's function, the Flush FIFO is not deleting the FIFO contents but only resets the FIFO pointer and clears the Packet Ready flag. Therefore this a relatively fast procedure.

There is also a mechanism to prevent FIFO Flush if there is only partial  packet in the FIFO. Please see the description below:

Regards,

Stan

Hi Stan-san,

I apologize; it seems our understanding diverged due to insufficient explanation of the situation.
I am attempting to perform a FLUSHFIFO on EP1 (PERI_RXCSR) while the device is in the configured state.
Under these conditions, would the behavior I described previously not occur?

Motofumi Kibata said:

Suppose writing to the FLUSHFIFO bit successfully flushes the buffer in one attempt.
If the next packet is received from the PC before reading RXPKTRDY, and the read result is 1, causing a second FLUSHFIFO write to be executed, wouldn't that packet also get flushed?

Best regards,

Kibata

Hi Kibata-san,

Thanks for the elaboration.

I'm not an expert in Mentor USB controller but my understanding is the following :

If a FLUSHFIFO is issued for a configured endpoint in the middle of a transfer,  then yes, there is a possibility a new packet to arrive into the second FIFO during the first FIFO flush. This possibility is minimal however, because the whole procedure of flushing in hardware is very fast - controller only resets the FIFO pointer and clears the Packet Ready flag. 

 I can see from the TRM that the FIFOFLUSH-request-twice is only required as part of Bulk IN or Bulk OUT Setup procedures. At that time (setup), the setup is not yet finished and data packets are not expected and any must be disregarded anyway.

Overall, from USB protocol standpoint, if the controller is not able to to receive packets for some reason, it must reply to the host with STALL to indicate this condition. The host also must keep track of the peripheral condition and avoid  sending data packets when the peripheral EP is not ready (EP not set up, etc.).

Best regards,

Stan

Hi Stan-san,

I understand.

Thank you very much for your various assistance.

Best regards,

Kibata