Hello,
This is a non-Keil specific question but since lots of folks familiar with the Fx2Lp seems to be hanging out here i'm hoping that someone might have an answer:
I'm using EP2 as an input endpoint that is automatically filled via the external slave FIFO. This pipe is transporting data from my hardware to the PC. I also need a generic command/status mechanism so i want to use EP6 and EP8 as OUT/IN endpoints respectively so the PC can send various command requests to the FX2. The FX2 will send back response messages over EP8. The problem now is that i don't seem to be able to reliably source packets under CPU control over EP8 while the SLAVE FIFO is being used for EP2.
To source packets i simply put data into the EP8FIFOBUF, set the EP8BCH:EP8BCL and write 08h into ENDPKTEND to send the packet to the host. The host sometimes receives the packet and sometimes not. When running the code in a loop (host command / status from FX2) i'm seeing a kind of random behavior (sometimes it works, sometimes not). I'm using SYNCDELAY between the register wites.
Can anyone tell me if it is even possible to source data over the "big" endpoints while another big endpoint is being serviced by the slave FIFO?
Thanks, /John.
"The problem now is that i don't seem to be able to reliably source packets under CPU control over EP8 while the SLAVE FIFO is being used for EP2."
I've usually applied GPIF on FX2LP, instead of slave FIFO. I've not experienced any interference between the EPs controlled by GPIF and the MCU core. I think slave FIFO hasn't so much difference from GPIF on this point. In either case, proper SYNCDELAY ensures time-sharing access to the common resources. Then, I suppose the packet drop on the EP8 is caused by another factors.
You seem to apply usual command-reply protocol, which has been popular in legacy RS232 age. To run this protocol on USB, you may need to consider the difference of RS232 and USB.
For RS232, the data written to UART TX is sent immediately when the MCU core writes it to the UART. On the host PC, the data is held in a RX buffer on the device driver. The host app accesses to this RX buffer. Then, the data doesn't drop even if the host app doesn't read it so often.
For USB, however, the bulk IN transfer does not start until the host app accesses to the EP. No buffer on the generic device driver. Then, the write to the EP on the firmware is more tightly associated to the read on the host app including the timing. They must be strictly matched one by one.
a) FULL bit On the firmware, do you check EP2468STAT (or EP8CS:FULL) before writing to EP8? The double-buffered FIFO may overflow, and overwrite may occur.
b) Polling-IN transaction and buffering You can make up the buffering similar to RS232 on the host application.
Using asynchronous Read call (OVERLAPPED ReadFile or ReadFileEx) seamlessly, polling-IN transaction is always issued on the bus. ie. when the last ReadFile finishes, start next one immediately. If you need to maximize the transfer speed, multiple OVERLAPPED ReadFile calls are issued simultaneously. Then, the received data is stored to a buffer on the host app. This process is assigned to a sub-thread, so that it doesn't disturb the main thread. In the main thread, the host app accesses to this local buffer.
Tsuneo
Thanks Tsuneo,
I'm seeing on my USB analyzer that the FX2 sometimes NAKs the IN transfers from the host although other times the transfers work. I think this is clearly an issue with the FX2 that makes sourcing packets over the large endpoints (via the CPU) not reliable if the large endpoints are configured to be serviced by the FIFO (and possible by the GPIF).
I have worked around this issue by instead using EP1 which is clearly decoupled from the large endpoints and the slave FIFO. My bidirectional communication now works fine.
As I said in above post, I've not seen such an interference with GPIF. It may be a difference of slave FIFO and GPIF. Anyway, I'm glad to hear your problem was fixed, cheers.