USB Problem handling SETUP token followed by DATA

[mjbcswitzerland]

Hi All

I have been using a USB CDC device driver successfully for a few years but recently had an instance where the emumeration once took some time to take place. This provoked an investigation which culminated in a stress-test being devised which sends the SET_LINE_CODING (used to configure the serial settings like Baud rate) repeatedly at a high rate.

The uses a SETUP token (class request OUT 0x20) and is a bit special because most other class SETUP tokens are not accompanied by data.

The result was that at some point during the test (maybe it took 1000 repetitions - sometimes more but also often less) the endpoint 0 operation would make a mistake (other endpoints still operate) and the USB host interface would stop and timeout (30s typical) before continuing normally again until the error maybe re-occurs at some point later in the stress test.

The first thing found was that the SETUP tokens are usually received in the EVEN frame buffer. When the problem occurs the frame however is received in the ODD frame buffer. The USD device is acknowledging the data and the host is then expecting a zero data termination. This is never sent back because the DATA1 frame neither causes an interrupt to be generated (the Kinetis SW is still expecting the data to be received) nor can be found in the receive frame buffer.

After various attempts to work out why the USB device was acknowledging the data but the data content not actually being received by the Kinetis SW driver layer a solution was identified:

Originally the code (for SETUP tokens) did:

- determine which frame buffer the reception is in (ODD or EVEN)

- ensure that the alternative frame buffer is free to receive (set OWN flag)

- allow SIE to continue token processing [CTL &= ~TXSUSPEND_TOKENBUSY;]

- handle the reception frame content

- clear the interrupt status

The 'solution' to the problem was to remove the [CTL &= ~TXSUSPEND_TOKENBUSY;] to after the reception frame content processing.

Now I never really understood the TXSUSPEND_TOKENBUSY bit but, if I remember correctly, its position was taken from a Freescale example (Coldfire at the time). I am wondering whether someone can explain the behaviour seen in relation to this bit??

Regards

Mark

[Kan_Li]

TXD_SUSPEND is set when the SIE has disabled packet transmission and reception in device mode. Clearing this bit allows the SIE to continue token processing. This bit is set by the SIE when a SETUP Token is received allowing software to dequeue any pending packet transactions in the BDT before resuming token processing.

For a SETUP token, it is followed by a DATA0, and device would ack after DATA received correctly, that is so called SETUP stage, and for your case, everything is fine till the end of the setup stage, right? if I understand correctly, problem happened after the following Data Stage, just during the end of Status Stage, because you mentioned "The USD device is acknowledging the data and the host is then expecting a zero data termination." so im my understanding, HOST sent OUT token followed DATA packet, and device sent ACK after DATA received, then HOST sent IN token expecting device send a zero length DATA0 for a normal Completion, which wasn't sent out by device(Kinetis SW) in such case.

Is my understanding right for your issue? Please kindly help to confirm.

Thanks for your patience!!

B.R

Kan