Unerklärliches Verhalten von CY7C68013A (USB-Controller)?!

Hallo,
ich bin gerade dabei, den CY7C68013A USB-Controller (die 56-Pin 
Variante) von Cypress zusammen mit einem FPGA in Betrieb zu nehmen. Ich 
arbeite im Bulk-Modus und verwende Puffergrößen von 4 mal 512 Byte (also 
alle Endpoints (2, 4, 6 und 8) werden benutzt).
Die Datenübertragung vom PC zum FPGA funktioniert auch schon 
einwandfrei, nun mache ich allerdings eine äußerst merkwürdige 
Beobachtung beim Übertragen von Daten vom FPGA zum PC: Pakete mit einer 
Größe bis 63 Byte werden wie erwartet übertragen. Beim Versuch größere 
Pakete zu übertragen, wird aber beim Lesen vom PC der Wert 0 für die 
Größe des übertragenen Paketes angegeben und die Daten können nicht 
korrekt ausgegeben werden.
Ganz gleich, welche Einstellungen ich schon geändert habe (z.B. 
Busbreite, Auto-Commit, Puffergrößen...), verändert sich dieses 
Verhalten des Controllers nicht und es können nur Pakete mit einer Größe 
unter 64 Byte übertragen werden. Ich würde gerne nachvollziehen, woher 
dieser markante Wert stammt.

Seit einiger Zeit zerbreche ich mir schon den Kopf, von was dieser 64er 
Wert abhängt und wie man ihn ändern (-> 512)  könnte. Habt ihr schon 
einmal ähnliche Beobachtungen gemacht oder vielleicht sogar einen 
Verdacht, woran es liegen könnte?

Es wird übrigens noch viel merkwürdiger: Wenn man am Anfang die gleiche 
Konfiguration (siehe unten) lädt, die aber statt EP6 den EP8 neu 
konfiguriert (vgl. „###“-Markierung im Quelltext), dann einmal ein Paket 
(< 64 Bytes) überträgt, anschließend ganz kurz Reset aktiviert, danach 
die eigentliche Konfiguration lädt und schließlich noch mal ein Paket (< 
64 Bytes) überträgt, so funktioniert auch die Übertragung von größeren 
Paketen (z.B. 512 Bytes) tadellos. Sobald man aber irgendetwas an diesem 
Verfahren verändert, gibt es wieder den bekannten Fehler.

Ich verfolge schon seit längerer Zeit die anderen Beiträge zum Thema 
USB-Übertragung im Forum und hoffe, dass jemand von den erfahreneren 
Experten meine Beobachtung zu deuten weiß. Ich erwarte keinesfalls, dass 
hier jemand die Arbeit für mich macht ;-) Über jeden kleinen Hinweis 
würde ich mich sehr freuen, vielleicht kommt euch das ja bekannt vor.

Vielen Dank für eure Mühe,
Julius






Hier ist ein Ausschnitt (nur der Initialisierungs-Teil, sonst wird 
außerhalb von „fw.c“ nichts mehr gemacht) des Quelltextes:
______________________________________________________________

// set the CPU clock to 48MHz
CPUCS = ((CPUCS & ~bmCLKSPD) | bmCLKSPD1) ;

// set the slave FIFO interface to 48MHz
IFCONFIG |= 0x40;
//IFCONFIG = 0xc3;
SYNCDELAY;

// default: all endpoints have their VALID bit set
// default: TYPE1 = 1 and TYPE0 = 0 --> BULK
// default: EP2 and EP4 DIR bits are 0 (OUT direction)
// default: EP6 and EP8 DIR bits are 1 (IN direction)
// default: EP2, EP4, EP6, and EP8 are double buffered

// we are just using the default values, yes this is not necessary...
EP1OUTCFG = 0xA0;
EP1INCFG = 0xA0;
SYNCDELAY;                    // see TRM section 15.14
EP2CFG = 0xA2;
SYNCDELAY;
EP4CFG = 0xA0;
SYNCDELAY;
EP6CFG = 0xE2;
SYNCDELAY;
EP8CFG = 0xE0;

    // out endpoints do not come up armed

// since the defaults are double buffered we must write dummy byte 
counts twice
SYNCDELAY;
EP2BCL = 0x80;                // arm EP2OUT by writing byte count 
w/skip.
SYNCDELAY;
EP2BCL = 0x80;
SYNCDELAY;
EP4BCL = 0x80;                // arm EP4OUT by writing byte count 
w/skip.
SYNCDELAY;
EP4BCL = 0x80;

// enable dual autopointer feature
AUTOPTRSETUP |= 0x01;

PINFLAGSAB = 0xE4;SYNCDELAY; // 10.07.08 send flags to pins, FLAGA=EP2PF 
!
PINFLAGSCD = 0xF5; SYNCDELAY;// 10.07.08 send flags to pins, FLAGC=EP4PF 
!

EP2FIFOPFH = 0x00;SYNCDELAY;  // Configure programmable flags A/C
EP2FIFOPFL = 0x01;SYNCDELAY;
EP4FIFOPFH = 0x00;SYNCDELAY;
EP4FIFOPFL = 0x01;SYNCDELAY;

Rwuen = TRUE;                 // Enable remote-wakeup

IFCONFIG = 0xc3;  SYNCDELAY; // internal clock set 48MHz, fifo slave + 
external master

REVCTL=0x03; SYNCDELAY;


 // auto in
REVCTL = 0x03; // REVCTL.0 and REVCTL.1 set to 1
SYNCDELAY;
//##########################
//########################## !!! In anderem (erstem) Hexfile bezieht 
sich dieser markierte Teil statt auf EP6 auf EP8.
EP6CFG = 0xE0; // EP8 is DIR=IN, TYPE=BULK
SYNCDELAY;
FIFORESET = 0x80; // Reset the FIFO
SYNCDELAY;
FIFORESET = 0x08;
SYNCDELAY;
FIFORESET = 0x00;
SYNCDELAY;
EP6FIFOCFG = 0x0C; // EP8 is AUTOOUT=0, AUTOIN=1, ZEROLEN=1, WORDWIDE=0
SYNCDELAY;
EP6AUTOINLENH = 0x02; // Auto-commit 512-byte packets
SYNCDELAY;
EP6AUTOINLENL = 0x00;
//########################## !!!
//##########################


// auto out
REVCTL = 0x03; // REVCTL.0 and REVCTL.1 to set to 1
SYNCDELAY;
EP2CFG = 0xA2; // EP2 is DIR=OUT, TYPE=BULK, SIZE=512, BUF=2x
SYNCDELAY;
FIFORESET = 0x80; // Reset the FIFO
SYNCDELAY;
FIFORESET = 0x02;
SYNCDELAY;
FIFORESET = 0x00;
SYNCDELAY;
OUTPKTEND = 0x82; // Arm both EP2 buffers to “prime the pump”
SYNCDELAY;
OUTPKTEND = 0x82;
SYNCDELAY;
EP2FIFOCFG = 0x10; // EP2 is AUTOOUT=1, AUTOIN=0, ZEROLEN=0, WORDWIDE=0


EP2FIFOCFG = 0x19; //0x1D; //0xFF; // Auf diese 4 Zeilen reagiert 
SLWR-Funktion sensibel: Als ob PKTEND aktiv wäre, falls nicht bestimmtes 
Bit 0 oder default...??..??
EP4FIFOCFG = 0x19; //0x1D; //0xFF;
EP6FIFOCFG = 0x19; //0x1D; //0xFF;
EP8FIFOCFG = 0x19; //0x1D; //0xFF;