Hi Sakshi,
Thanks for getting back to me! I'll first answer your questions and then give some additional insight into what it is I am trying to accomplish. My apologies if this is a repeat, I had written a reply earlier but upon reloading the page I am no longer seeing my reply. It doesn't show on my profile, nor if I open the thread in Incognito mode. Not sure what happened there.
To answer your questions:
- I am using a modified version of the GPIFtoUSB code that I changed to write data from USBtoGPIF instead, plus some I2C writes to set up the downstream IC. I have attached my code.
- The state machine is of my own making. It is included in the data_out.cydsn folder inside the UsbtoGpifModified.zip file.
- My DMA buffer size is (640 x 360 x 16). The display I am writing to is 640 pixels wide and 360 lines long and 16bits per pixel. The buffer count is 2. As far as my understanding goes, this should exceed the internal memory of the FX3 but the CyU3PDmaChannelCreate was unhappy with only 1 buffer and didn't complain when I asked for 2 of this size so I just left it at that for now.
- I am out of the office today so I will need to share my USB debug prints another time, but as far as I recall there were no errors in the initialization and operation.
- I am monitoring the GPIF interface with a Saleae logic analyzer. I have attached the logic capture below. If you'd like to open it you will need the Saleae Software.
- I am looking to write RGB565 data to a 640 x 360 display.
Additional information:
I am working to build a USB -> parallel RGB565 bridge that interfaces with a DLPC2607 driving a 640 x 360 display. 16-bit parallel RGB is comprised of 16 data pins, HSYNC, VSYNC, CLK and DATAEN. With my analyzer I am capturing PCLK, HSYNC, VSYNC, DATAEN, DATA[0], and DATA[1].
At a high level,
- Data is written out in 640 cycle chunks, representing the 640 pixels per line.
- Each clock cycle clocks out 16 bits (2 bytes) at a time, representing the RGB values for a single pixel.
- At the beginning of each line, HSYNC is pulled high for at least 4 clock cycles, indicating the beginning of a new line
- At the beginning of each image, VSYNC is pulled high for 2 empty lines, indicating the beginning of a new frame.
Given this, the expected behavior is that VSYNC goes high for two empty lines, followed by 360 cycles of HSYNC + DATA being written. I have simulated the beginning of a frame write using the GPIF II designer:
You can see VSYNC asserting for two HSYNCs with no activity on the data bus, followed by 5 lines. Each line is a HSYNC pulse, followed by 640 clock cycles of activity on the DataBus. In simulation this looks like it works quite nicely.
However, when I write (640 pixels/line x 360 lines/frame x 2 bytes/pixel x 1 frame=) 460,800bytes to the FX3 using the Data Transfer on the FX3 Control Center I am seeing the following output captured by the Saleae:
As you can see, VSYNC asserts many, many times. Instead of just once at the beginning. Zooming in, we can see the following:
As we can see the frame starts fine, with VSYNC asserting and two empty lines written, however only ~1.6 lines of data are written afterward before VSYNC asserts again, instead of the 360 lines that I want to write.
Data is clocked out at 20Mhz, and both DATAEN blocks combined are 31.844us + 19.048us wide, which yields about 1017 clock cycles of valid data. I suspect that there are some rounding errors in the measurement and that the true number is 1024 cycles.
The total transaction is 26.787ms while each partial transfer is 119.292us long, which yields about 225 transfers. Combined the 225 chunks thus write out (225 chunks x 1024 data_writes/chunk x 2 bytes/data_write 😃 460,800 bytes of data.
So the whole image is being written out. But the transaction is chopped into 2048 byte chunks and in the process becomes unusable for the downstream IC. I suspect that this has something to do with this line from the FX3's programmer's Manual:
Because the state machine resets when DMA_RDY_0 deasserts, which I assumed it would do if all the data from the buffer has been written out. My current suspicion is that the P-Port buffer is empty after 2048 bytes have been written and DMA_RDY deasserts as another chunk of 2048 bytes is moved into the buffer, resetting the state machine in the meantime.
Hope this explains the problem well enough.
Thanks! EZ_Engineer
Quick update: I have modified the state machine such that it keeps writing data until 640pixels x 360 lines have been written, and from the looks of it, I am now getting a proper VSYNC, followed by 360 HSYNCs:
However, there's still an issue with the data being written and I think that issue is still related to the size of the P-Port buffers. As you can see, the Data lines only move at the beginning of the transition. Roughly 25 lines + some spares. Measurements place tell me there are 16,465 clock cycles of data being written - so about 32,930 bytes of data. I suspect that the actual number is 32,768, equal to 32KB, the size of the P-Port buffer.
Additionally, after one data transfer of (360 x 640 x 2 ) bytes from the Infineon Control Center any subsequent writes are timing out with "BULK OUT transfer failed with Error Code:997". This suggests that data isn't being consumed by the GPIF block (as discussed in this thread).
My data writes are set to remove data from the source:
So I'm curious why the buffer is filling up. Any ideas? Thanks!
I've attached the modified state machine to this post.
