Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I have a CYUSB3KIT connected to a Xilinx KC705 eval board. I updated the AN65974 app note to work with Vivado 2020.1. I build slaveFIFO2b_fpga and the image seems good.
So my issue:
I seem to be able to do the loopback test fine. I send a file, and then I can receive the data back using the USB Control Center. I then continued with the examples in the AN65974 app note and could not get BULK IN to work. Here are the steps I do.
Power up the FPGA with the switches all set to zero (I am using SW11 on the KC705)
flash the RAM on the FX3 to use the pre-compiled SF_streamIN.img
flash the KC705 with my slaveFIFO2b_fpga
set the switch to be OFF, OFF, ON, ON (FPGA continuously writes full packets)
In the USB Control Center I hit the "Reconnect Device" button so that the FX3 is in the BULK IN mode
IN the C++ Streamer app, I select the Cypress FX3 USB StreamerExample device and choose the BULK IN endpoint
I set the packets for transfer to be 128 and the transfer to queue to be 32 (just like the app note) and click start
All I get is failed packets:
Following the same steps (still using the same img file for the FX3, but setting the jumpers to OFF, ON, OFF, OFF and choosing BULK OUT in the C++ stream seems to work great:
So what am I missing? I checked and the PMODE flags are toggling as they should as I flip the different switches. I am not sure what else I should be looking into next.
From the traces, I see that Flag B is LOw which is not expected. Initially, both the flags A and B should be HIGH i.e. after programming the FX3 which indicates that the DMA buffers (FX3) are ready to receive the data from the FPGA (master).
The FPGA code checks for both the flags to be high and only then it will assert the SLWR signal. As seen in the trace, SLWR is HIGH always which means the FPGA is not writing the data to FX3. For FPGA to assert SLWR LOW (Write data to FX3) both the Flags i.e. FLAG A &B should be HIGH.
This is the code snippet from the default FPGA code provided with the Application note AN65974
- Please let me know if you have changed the GPIF state machine using the GPIF designer tool or any firmware changes are done as the UART debug prints are not as per the default firmware.
- Also, confirm if any changes done in the default FPGA code
- If you are using the default FX3 firmware and default FPGA code. Please check if the following
1) Flag B signal is not pulled low internally from the FPGA side
2) Please check the initial condition i.e. Program the FX3 > program the FPGA (set the switches for selecting Stream IN) and then check the initial signals again.