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