Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
05/13/03 19:25
Read: times


 
#45385 - Conflicts between endpoints in USB uC
Hello,

This may be a bit long and particular question but perhaps someone in
this forum has found a similar problem beforehand and is able to help me.

I am developing firmware for a W81E381AD microcontroller. This
microcontroller has an USB Full Speed controller integrated, with
4 endpoints (interrupt in/out and bulk in/out), although the firmware
I am developing only uses bulk out, interrupt in and control endpoints only.

The problem is that bulk out endpoint usually gets blocked when I use
the other Endpoints. When I say that bulk out gets blocked I mean Host
receives NAK all times it sends data to this endpoint, generating time out
all time. The Host is a PC with linux and I use OHCI. But I am sure it is
not a Host's problem because I am using an USB analyser and I see how
it sends data to bulk out correctly.


It happens in two situations:

INTERRUPT IN - BULK OUT CONFLICT
--------------------------------

If I read data that arrives at bulk out endpoint using the bulk out
interrupt (that is, setting a flag in that interrupt, and so on), it
works perfectly until I send data over Interrupt IN endpoint.
When I use Interrupt In endpoint the bulk out interrupt is not generated
anymore.
But according to bulk out receive fifo flags, there is new data pending:

(EPINDEX=BULK_OUT)

RXFIFO=1 -> 1 packet in RX FIFO.
RXFULL=1 -> rxfifo is full.
RXVOID=1 -> Last out token was NAKed (this happens when rx fifo
is locked)
RXACK=1 -> Last valid out toked was ACKed. (it means there was no error).

(all other bits in RXSTAT and RXFLG are disabled).

So it seems that bulk out rx fifo is locked (therefore it responds NAK)
because there is data pending that has not been processed (because the
interrupt is not generated anymore)

According to the Interrupt Enable registers neither there is any interrupt pending
nor bulk interrupts are disabled nor bulk endpoint is disabled.

(EPINDEX=BULK_OUT)

FIFLG=0000 0000 -> no interrupt pending.
EPCON=0000 1100 -> rx endpoint enabled, interrupt enabled.
FIE=0011 1111 -> all endpoints interrupts enabled.

I have checked all interrupt IN code to see if there is any conflict when
using EPINDEX (USB registers have the same name for all endpoints, but they are indexed by epindex), but there is not. EPINDEX is accessed in the USB isr but I save
it before I modify its value:

// beginning of isr.

epindex_old=EPINDEX; // save epindex

...

if(FRXD2()) // New data arrived at bulk OUT endpoint
{
EPINDEX=BULK_OUT;
bulkData=1;
Clear_FRXD2(); // clear interrupt pending.
}

...

EPINDEX=epindex_old; // restore epindex

// end isr.

So, I decided to ignore bulk out interrupt and used RXFIFO flag (tracks how many packets
there are in bulk out fifo. In this uController: 0 or 1, single packet) to read bulk out
data. And it worked great but now I have some problems when I use
control endpoint.

CONTROL - BULK OUT CONFLICT
---------------------------

If I only use bulk out and interrupt in endpointIt it works well . But when I
use Bulk out and control endpoints at the same time, bulk out gets blocked again.
But now it is because it gets the "receive fifo underrun" error.
According to Winbond's technical manual this happens when reading from an empty
fifo. But in my situation I think this has no sense because I only read bulk data
after ensuring that RXFIFO!=0 (that is , there is one packet at rx fifo), and, as
I said, it only happens when I also use control endpoint
. This is the piece of code where I read endpoint data in main():


...

EPINDEX=BULK_OUT;

if((RXFLG&0x40)==0x40) // check if FIF bit is set.
{
i=RXCNT;

while(i>0)
{
usbData[i]=RXDAT;
i--;
}
if(RXURF()!=0x00) // after read and
{ // before RXFFRC according Technical manual RXURF must be checked.
Clear_RXURF(); // this bit must be cleared.
Set_RXCLR(); // technical manual recommends to clear rx fifo

while((RXCLEAR())!=0) // wait until rx fifo is cleared
{
// wait
}
}

if((RXFIFO())!=0x00) Set_RXFFRC() // Set_RXFFRC() releases rx fifo. but according
// to Winbond's manual if RXFIFO==0 this would
// produce Underflow.
}

...

Thank you very much,

Javier

List of 4 messages in thread
TopicAuthorDate
Conflicts between endpoints in USB uC            01/01/70 00:00      
   RE: Conflicts between endpoints in USB uC            01/01/70 00:00      
      RE: Conflicts between endpoints in USB uC            01/01/70 00:00      
   RE: Conflicts between endpoints in USB uC            01/01/70 00:00      

Back to Subject List