AnsweredAssumed Answered

Problem with USB on BF527

Question asked by ChrisCEA on Mar 26, 2012
Latest reply on Apr 24, 2012 by gvasanth

Hello,

 

 

I'm using ADI's USB libraries on a BF527, but I encounter some problems which seem to be very close to this one http://ez.analog.com/message/25602#25602. However, I didn't find a correct fix in the answer.

 

My application uses USB in device mode mainly to send data to a PC. I would like the data to be sent in the same way whatever happens at the PC side. My first problem is that, if the data is not read at the PC side, the blackfin's program is stalled in the TransmitDataBuffer function:

 

/* check if FIFO is empty or not */

       if(*pUSB_TXCSR & (1 << 1))

       {

           /* only for the bulk endpoints we will wait */

               if(IS_BULK(pEpO->pEndpointDesc->bAttributes))

                  while(*pUSB_TXCSR & (1 << 1)) ;

               else

               *pUSB_TXCSR |= (1 << 3);

 

       }

Is there a way not to wait that the data is being received or is that something mandatory in the bulk class (my knowledge about USB is close to zero) ?

 

 

USB also causes a problem related to LCD screen exactly like in the post above mentioned. In my hardware, the LCD screen is controlled by an FPGA which has a small buffer that stores locally the pixels' values corresponding to 3 lines of the LCD screen (=960 values). This controller reads the pixels' values and generates the appropriate signals for the LCD screen. While one buffer is being read, another one is being filled by the Blackfin processor (connected through the EBIU port) with the next 3 lines using a MDMA channel. When the first buffer becomes empty, the two buffers are swapped and the FPGA triggers an interrupt to the DSP to inform him that a buffer is empty and to start a new DMA transfer. This process implies that the interrupt must be serviced (soon) before the second buffer will be empty, otherwise the same 3 lines will be displayed on the screen.

I'm not sure that the explanation is very clear but anyway, the problem is that when the USB is not connected this works properly but when USB starts sending data, the image starts to "jump", which means that the interrupt is not serviced on time and the same 3 lines are copied one or several times on the screen. I've tried to map the LCD interrupt to the highest priority level (IVG7) but this didn't change anything. Do you have any idea ?

Thanks for your help

 

Chris

Outcomes