USB FS setup packets and buffer overrun

[ashibakov]

Posted on July 16, 2012 at 07:23

Hi all!

I have two questions on how to interpret the documentation for the USB FS device macrocell in medium density devices. 1. The section on OUT transactions states that when a buffer is overrun (i.e. the data payload is longer than the allocated length of the buffer in the PMA) no interrupt is generated. There is some wording to the effect that SETUP transactions are handled `similarly', however, when I deliberately set the buffer to, say, 2 bytes, an interrupt is still generated,  only 2 bytes are written into the buffer, and the length of the packet is reported as 0. Is this the correct behavior according to the docs? I think the description of OUT and SETUP transactions should be more precise. 2. The same section mentions that in the case of a successful SETUP/OUT transaction, the buffer is written for the number of bytes equal to the length of the packet, CRC included (i.e. data payload + 2). It is careful enough NOT to say that the extra 2 bytes are actually the CRC of the data payload but does not mention what they are. In my experience those data bytes are not the CRC (the two bytes are always identical, for starters which makes me think they are the result of an 8-bit access on the APB1 bus), so what are they? Also, if I set the buffer length to exactly 8 bytes (the length of the data payload WITHOUT the CRC) then everything goes according to the manual and NO extra bytes are written and no overrun condition or any other errors are reported. Why are these bytes written in the first place? Thanks.

[tsuneo]

Posted on July 16, 2012 at 11:16

> Is this the correct behavior according to the docs?

In the first place, the description of the manual is insufficient. This description gives us an impression that buffer overrun of OUT and SETUP packets always results in STALL handshake.RM0008 Reference manual http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf OUT and SETUP packets (data reception) (p604) Reception memory buffer locations are written starting from the address contained in the ADDRn_RX for a number of bytes corresponding to the received data packet length, CRC included (i.e. data payload length + 2), or up to the last allocated memory location, as defined by BL_SIZE and NUM_BLOCK, whichever comes first. In this way, the USB peripheral never writes beyond the end of the allocated reception memory buffer area. If the length of the data packet payload (actual number of bytes used by the application) is greater than the allocated buffer, the USB peripheral detects a buffer overrun condition. in this case, a STALL handshake is sent instead of the usual ACK to notify the problem to the host, no interrupt is generated and the transaction is considered failed. ''Buffer overrun - STALL'' is fine just for DATA stage of Control transfer. For other cases, supposed responses by the USB spec are,   SETUP transaction - no response on handshake phase   STATUS stage        - ACK   Bulk and Interrupt endpoints - no response on handshake phase The manual refers to SETUP transaction case in this section,Control transfers (p605) Since the USB specification states that a SETUP packet cannot be answered with a handshake different from ACK, eventually aborting a previously issued command to start the new one, the USB logic doesn’t allow a control endpoint to answer with a NAK or STALL packet to a SETUP token received from the host. Obviously, the first description is denied here. In this reason, I believe the manual doesn't describe fully on the response of buffer overflow.> In my experience those data bytes are not the CRC I'm not sure, too. Maybe, result of CRC check? Tsuneo

[ashibakov]

Posted on July 17, 2012 at 17:06

Another vague statement in the same section is that upon the receipt of the SETUP packet the values of DTOG_TX and DTOG_RX are set at 1 and 0. That would make sense (and is actually what happens despite what the docs say) if those values were set upon the successful receipt of the SETUP PID and then DTOG_RX would get toggled after the data part of the setup packet is received. So while almost correct, albeit too vague, this statement is way too confusing. Those values of toggle bits would never be seen by the user. I wish that ST would publish a new revision of the manual but it is probably not happening because the USB macrocell is likely a much older design than the stm32 chip. Oh well, one can hope