Potentional BUG inside USBSample.c
Dears,
__arm void vUSB_ISR( void )
……………
/* If there are bytes in the FIFO then we have to retrieve them here.
Ideally this would be done at the task level. However we need to clear the
RXSETUP interrupt before leaving the ISR, and this may cause the data in
the FIFO to be overwritten. Also the DIR bit has to be changed before the
RXSETUP bit is cleared (as per the SAM7 manual). */
I have found that it is a total nonsense and very dangerous to flip DIR bit inside USB_ISR.
Please never do this.
The problem occurs when data stage follows a control stage. Data stage has a same direction
and when a DIR bit is flipped, it causes total blocking of USB transfer.
The correct place for setting DIR is here:
static void prvProcessEndPoint0Interrupt( xISRStatus *pxMessage )
{
xRequest.usLength = pxMessage->ucFifoData[usbLENGTH_HIGH_BYTE];
xRequest.usLength <<= 8;
xRequest.usLength |= pxMessage->ucFifoData[usbLENGTH_LOW_BYTE];
/* Clear direction when neccessary. */
if (xRequest.ucReqType & 0x80)
{
AT91C_BASE_UDP->UDP_CSR[0] |= AT91C_UDP_DIR;
while ( !(AT91C_BASE_UDP->UDP_CSR[0] & AT91C_UDP_DIR) );
}
/* Manipulate the ucRequestType and the ucRequest parameters to
generate a zero based request selection. This is just done to
break up the requests into subsections for clarity. The
alternative would be to have more huge switch statement that would
be difficult to optimise. */
switch(xRequest.ucReqType & 0x7F)
{
It took me a week of hard debugging. If you have further questions, please feel free to contact me.
The problem occurs only when PC emits a data stage packet on point0.
good luck
Jara