- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After a renumeration, the FX2 often starts with the FULL flags asserted in the EPxCS registers, despite the usual collection of FIFORESET assertions.
NPAK status for EP2 is 010, and for EP4 10. The others I am not interested in.
This happens, despite the EPxFIFOBCL registers correctly reporting 0 bytes.
From a cold boot, this does not occur.
Is there anyway to force the FULL flag to be deasserted after renumeration?
Am I also correct in assuming that this FULL flag is why I am unable to send data to the endpoints from the host (timeout instead)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ali,
What is the endpoint configuration you're using,
Endpoints used and their buffering. Most probably you're not configuring them right. One other thing is, are you arming OUT endpoints by writing 0x80 to the EPxBCL register after the FIFORESET sequence.
Regards,
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My initialisation code for setting endpoints:
void init_user()
{
EA = 0; //Interrupts disabled - simplify debugging and setup times
IFCONFIG = 0xE3; SYNCDELAY(); //internal, 48MHz, SYNC, slave
REVCTL = 0x03; SYNCDELAY();
//Setup debug endpoints
EP1OUTCFG = 0xB0; SYNCDELAY(); //Interrupt
EP1INCFG = 0xB0; SYNCDELAY();
REARMEP1OUT();
//init flags. listed in docs/fpga-cypacket.txt
PINFLAGSAB = 0x8C; SYNCDELAY();
PINFLAGSCD = 0x09; SYNCDELAY();
//FIFOINPOLAR = 0x00; SYNCDELAY();
//Setup LED output, and light it
PORTCCFG &= ~0x80;
OEC |= 0x80;
SYNCDELAY();
PC7 = 1;
//Sort out FIFOs
//see: http://www.embeddedrelated.com/usenet/embedded/show/65142-1.php
//Issue with cypress chip and 'full' flag on a warm start
EP2CFG = 0xE4; SYNCDELAY();
EP4CFG = 0xA2; SYNCDELAY();
EP6CFG = 0x00; SYNCDELAY();
EP8CFG = 0x00; SYNCDELAY();
FIFORESET = 0x80; SYNCDELAY();
FIFORESET = 0x82; SYNCDELAY();
FIFORESET = 0x84; SYNCDELAY();
FIFORESET = 0x86; SYNCDELAY();
FIFORESET = 0x88; SYNCDELAY();
FIFORESET = 0x00; SYNCDELAY();
OUTPKTEND = 0x84; SYNCDELAY();
OUTPKTEND = 0x84; SYNCDELAY();
INPKTEND = 0x82; SYNCDELAY();
INPKTEND = 0x82; SYNCDELAY();
EP2FIFOCFG = 0x00; SYNCDELAY(); //to ensure it sees a 0->1 transition
EP4FIFOCFG = 0x00; SYNCDELAY();
EP2FIFOCFG = 0x0B; SYNCDELAY();
EP4FIFOCFG = 0x11; SYNCDELAY();
EP2AUTOINLENH = 0x01; SYNCDELAY();
EP2AUTOINLENL = 0x00; SYNCDELAY();
EA = 1;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ali,
You're using an invalid endpoint configuration. Please look at page 30 of the latest TRM for the 12 valid endpoint configurations. Also if you're not using a endpoint do not write to its EPxCFG register to disable it. If an endpoint is not being used you should avoid writing to registers corresponding to it.
EP2CFG = 0xE4???? This statement also seems wrong.
Regards,
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, I should have spotted that. I have changed it to use type 11 (EP2 1024*3 + EP8 512*2):
EP2CFG = 0xFB; SYNCDELAY(); EP4CFG = 0x00; SYNCDELAY(); EP6CFG = 0x00; SYNCDELAY(); EP8CFG = 0xA0; SYNCDELAY(); FIFORESET = 0x80; SYNCDELAY(); FIFORESET = 0x82; SYNCDELAY(); FIFORESET = 0x84; SYNCDELAY(); FIFORESET = 0x86; SYNCDELAY(); FIFORESET = 0x88; SYNCDELAY(); FIFORESET = 0x00; SYNCDELAY(); OUTPKTEND = 0x88; SYNCDELAY(); OUTPKTEND = 0x88; SYNCDELAY(); INPKTEND = 0x82; SYNCDELAY(); INPKTEND = 0x82; SYNCDELAY(); INPKTEND = 0x82; SYNCDELAY(); EP2FIFOCFG = 0x00; SYNCDELAY(); //to ensure it sees a 0->1 transition EP8FIFOCFG = 0x00; SYNCDELAY(); EP2FIFOCFG = 0x0B; SYNCDELAY(); EP8FIFOCFG = 0x11; SYNCDELAY(); EP2AUTOINLENH = 0x01; SYNCDELAY(); EP2AUTOINLENL = 0x00; SYNCDELAY();The EP's no longer seem to be coming up marked as full anymore, but I am still unable to communicate with the FX2). After sending 2 packets (which fills the buffer), I get timeouts, and after 2 read attempts (I would have thought it should be after 3 since triple buffering), I get timeouts. Any more comments?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ali,
As stated before, When you are not using a particular endpoint avoid writing to the registers corresponding to it.
Try removing the lines
EP4CFG = 0x00 and
EP6CFG = 0x00
It should resolve the issue.
Regards,
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope, that doesn't help either.
If I remove those linse then those EPs think they are valid (so presumably memory allocation goes wrong?)
If I use EP4CFG &= 0x7F; To ensure the VALID bit is cleared, then they are no longer marked as valid, but I still get the same connectivity issues as before.
I had no problems getting EP1IN/OUT going - which I am using to provide readbacks of the registers to try to help work out why, but I have no idea why it won't let the computer access the FIFOs?
When I send the first 2 packets to EP8, the byte count increments by 2 each time (correct because they are 2 byte packets), and all subsuquent ones get rejected (double buffering, so this is the expected behaviour).
As soon as one of those packets gets received, EP2 gets filled by the FPGA, and the bytecount goes immediately to 1024, but I am unable to read anything out of this EP. AUTOIN and AUTOOUT and being used, as shown in the previous initialisation.
Also, for some reason when the FPGA reads EP8 (well, I think it reads the packets, because it doesn't provide any output untill it gets some packets - which is what it is programmed to do), the bytecount doesn't decrement (is it meant to? is this why I can't send any more to that EP?)
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ali,
As you would already know the endpoint buffer is shared by the 4 endpoints so when you configure for a configuration the register write is expected to take care of disabling not being used when you do so. It is strange that it didn't work.
I'm back after a long vacation. So I've boards with me to work on. Give me a little time I'll check on this and get back.
Regards,
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ali,
Just now got more time to look at this.
After sending 2 packets you're bound to get timeout. Have you tried sending packets after reading those 2 packets to the FPGA (through the Slave FIFO interface of FX2LP)?
How many packets are you sending to EP8 from the FPGA. If you're sending 3, you should be able to read 3. If you send 2 you will be able to read only 2.
Regards,
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I send 1 packet (2 bytes) to EP8: no timeout. EP2BC=0
FPGA reads (I think). Sends data to EP2. EP2BC > 0.
Try reading EP2 from PC: timeout (and all subsuquent attempts to read EP8)
Send again: no timeout.
Send again: timeout.
Once the FPGA receives its initial control commands, it will send data continuously to EP2 (EP2BC goes straight to 1024) at ~48MHz untill it gets told EP2FULL. Once it becomes empty, it will start trying to send again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When the TRM says (page 100):
"In synchronous mode SLRD and SLWR are enables for the IFCLK clock pin".
Does this mean that since I have the FX2 setup to drive the IFCLK pin from the internal 48MHz clock, that the IFCLK is not extervally visible on this pin (for the ext. master) until I take SLRD or SLWR low?
Thanks.
Ali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ali,
IFCLK will always be visible if you've configured it for being outputted. SLRD and SLWR being enables for IFCLK pin means that it'll qualify the data. So only when they're asserted the bus is sampled for data with respect to the IFCLK. Otherwise IFCLK will still be toggling but the bus won't be sampled.
Regards,
Anand