EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Cypress FX1 / FX2LP bulk transfers - interrupt based

Started by gmonteyne August 26, 2005
Setup
- Cypress Development Board, with FX1
- out bulk transfer on EP6 - double buffering
- ports I/O (IFCONFIG:0.1 = 00b)


Firmware is based upon the samplecode 'bulkloop' supplied with the
Development Board.
Extract from ISR_EP6inout:
{
    ....
    EP6BCL = 64;                     // write anything to BC to allow
EP to be written to again
    EZUSB_IRQ_CLEAR();         // Clear USB interrupt
    EPIRQ = bmEPIRQ_EP6;
}


Problem
- only the first 2 out packets generate an EP6inout interupt on the
usb-device
- the following transfers (third, fourth, aso) generate a time-out


Question
It seems like the endpoint is not re-armed. When changing to triple
buffering one more packet is transferred. The same occurs when using
quadruple buffering: 4 packets are transferred, the next packets are
blocked.
What must be changed on the configuration and/or re-arming to allow
more packets to be send?

the bulkloop example is not interrupt transfers though. I would seek out the
interrupt example.. if there is one.. The Cypress docs and support is very
poor.
"gmonteyne" <geert.monteyne@transics.com> wrote in message
news:1125038643.816460.256420@o13g2000cwo.googlegroups.com...
> Setup > - Cypress Development Board, with FX1 > - out bulk transfer on EP6 - double buffering > - ports I/O (IFCONFIG:0.1 = 00b) > > > Firmware is based upon the samplecode 'bulkloop' supplied with the > Development Board. > Extract from ISR_EP6inout: > { > .... > EP6BCL = 64; // write anything to BC to allow > EP to be written to again > EZUSB_IRQ_CLEAR(); // Clear USB interrupt > EPIRQ = bmEPIRQ_EP6; > } > > > Problem > - only the first 2 out packets generate an EP6inout interupt on the > usb-device > - the following transfers (third, fourth, aso) generate a time-out > > > Question > It seems like the endpoint is not re-armed. When changing to triple > buffering one more packet is transferred. The same occurs when using > quadruple buffering: 4 packets are transferred, the next packets are > blocked. > What must be changed on the configuration and/or re-arming to allow > more packets to be send? >
gmonteyne wrote:

> Question It seems like the endpoint is not re-armed. When changing to > triple buffering one more packet is transferred. The same occurs when > using quadruple buffering: 4 packets are transferred, the next > packets are blocked. What must be changed on the configuration and/or > re-arming to allow more packets to be send?
I'm not sure about the FX1, but on the FX you need to write a '0' to the BC of the OUT endpoint to re-arm it (obviously after you've read all the data). Regards, Mark
We found out that you have to write exactly 0x80 bytes into the Low
Bytecount to re-arm it on the FX1 and FX2LP endpoint for endpoints
2,4,6 and 8. This is also done in the examples that are delivered with
the Cypress development kit. The datasheets of the FX2LP say you can
write any value to the bytecount to re-arm it, but it must be exactly
0x80, otherwise it doesn't work.

Just for the record, so you all don't make the same mistake.

Greetings,
Peter.

Mark McDougall schreef:

> gmonteyne wrote: > > > Question It seems like the endpoint is not re-armed. When changing to > > triple buffering one more packet is transferred. The same occurs when > > using quadruple buffering: 4 packets are transferred, the next > > packets are blocked. What must be changed on the configuration and/or > > re-arming to allow more packets to be send? > > I'm not sure about the FX1, but on the FX you need to write a '0' to the > BC of the OUT endpoint to re-arm it (obviously after you've read all the > data). > > Regards, > Mark
We found out that you have to write exactly 0x80 bytes into the Low
Bytecount to re-arm it on the FX1 and FX2LP endpoint for endpoints
2,4,6 and 8. This is also done in the examples that are delivered with
the Cypress development kit. The datasheets of the FX2LP say you can
write any value to the bytecount to re-arm it, but it must be exactly
0x80, otherwise it doesn't work.

Just for the record, so you all don't make the same mistake.

Greetings,
Peter.

Mark McDougall schreef:

> gmonteyne wrote: > > > Question It seems like the endpoint is not re-armed. When changing to > > triple buffering one more packet is transferred. The same occurs when > > using quadruple buffering: 4 packets are transferred, the next > > packets are blocked. What must be changed on the configuration and/or > > re-arming to allow more packets to be send? > > I'm not sure about the FX1, but on the FX you need to write a '0' to the > BC of the OUT endpoint to re-arm it (obviously after you've read all the > data). > > Regards, > Mark

The 2024 Embedded Online Conference