Hi All
I am wondering whether any experienced ATMEL SAM7 user can give any details about the optimal use of the DTGLE flag? This flag can be read when an OUT token is received by the device and indicates whether it is a DATA0 or DATA1 type. If an incorrect DATA type is received it indicates a repetition (due to the loss of one of our ACKs causing the HOST to repeat).
However I have the following observations.
-
The polarity of this flag seems to be inverted to the explanation in the data sheet. When I receive a DATA0 type the flag is set and when it is a DATA1 type the flag is not set. This is consistent in all of my tests so I inverted the polarity in the SW and then it receives without recognizing errors under ‘normal’ conditions.
-
When the receiver is using ping-pong buffers all goes well as long as there is data in only one of these buffers. Under ‘normal’ conditions this is the case since the USB receiver routine reads the FIFO before the next OUT token arrives. But, if the SW doesn’t read the buffers fast enough then there are two buffers waiting to be cleared. The SW needs to keep its own flag in this case so that it knows which of the two buffers has to be read first (as stated in the user manual); since the received data is consistent (no buffers gets swapped) the driver doesn’t seem to have any difficulties here.
However… the status register (UDP_CSRx) contains information about which buffer(s) have data waiting (two flags) and one DTGLE flag. And tests have show that the state of the DTLGE flag in this case is not (necessarily) showing the token received in the first waiting buffer but seemingly the last one received.
Therefore I found that the case with 2 waiting buffers initially resulted in the driver declaring the DATAx type as being incorrect (subsequently rejecting the data). Then I found that I could get good results (not sure whether perfect yet) when I inverted the state of the DTLGE flag in the case that 2 buffers were waiting.
This leads to my understanding that the DTLGE flag is indicating the type of the last received DATA frame and so there is in fact no information available about the first one of them received.
Can anyone confirm this and suggest the best way to work around it? I checked a few ATMEL examples but didn’t find this flag actually being used (?)
Regards
Mark
PS. I noted that someone suggested (on ATMEL forum) that the DATAx integrity was handled automatically in the HW of the chip. Can anyone confirm this to be the case?