FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: Problem communicating PC and FPGA with UM245R  (Read 2090 times)

abenitez

  • Newbie
  • *
  • Posts: 2
    • View Profile
Problem communicating PC and FPGA with UM245R
« on: March 10, 2021, 11:53:41 PM »

Hi everyone,
I have been trying for days to communicate an FPGA and a PC through the UM245R. The programming language that I use in the FPGA is VHDL, and in the PC I use the LabWindows software that programs in C. I am wanting to transmit data from the PC to the FPGA, for which I am using the D2XX library for FIFO Asynchronous communication. I have already achieved communication and data transmission, but sometimes the transmission is cut off, that is, not all the bytes are transmitted (this happens quite frequently) and I don't know what might be happening. I have simulated the VHDL code in ModelSim and it behaves as expected, while I have relied on the Ft_Write function for data transmission in LabWindows, I have even used code examples provided by manuals and libraries, and this problem remains. Finally, I was looking at the behavior with an oscilloscope of the RXF signal and it never changes state (always remains high) during the transmission of multiple bytes, but when the transmission is truncated this signal goes low. If you could explain any reason for this behavior, I would appreciate it.
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 612
    • View Profile
Re: Problem communicating PC and FPGA with UM245R
« Reply #1 on: March 12, 2021, 04:40:49 PM »

Hello,

Have you took a look at TN_167 FTDI FIFO Basics?

This also includes software examples.

You must monitor the TXE# and RXF# flags.

The TXE# and RXF# outputs are the buffer status pins (flags).
For both Asynchronous and Synchronous FIFO modes, the status of the internal transmit and receive buffers must be monitored by the external FPGA or microcontroller to avoid buffer over run and data loss.
The TX buffer is used by data sent from the FIFO pins back to the host (write operation)
The RX buffer is used by data sent from the host to the FIFO output pins (read operation)
When the TXE# flag is low, this indicates there is enough internal transmit buffer space available for writing data back to the host. The USB host application code (VCP or D2XX for Async FIFO, D2XX for Sync FIFO) must constantly read incoming data from the device to keep the buffer from filling up.
When the RXF# flag is low, this indicates there is still unread data in the internal receive buffer remaining to be read by the downstream FPGA or micro. Instead of interpreting this flag as “receive buffer full”, the RXF# flag can best be thought of as “receive buffer not empty yet”. When the RXF# flag stays high, the last byte of data in the buffer remains on the data bus and does not change.

Here is some other useful information:

The 245 FIFO interface should only be written to when the TXE# pin is logic 0.
The TXE# pin will go to logic 1 and back to logic 0 for every byte latched in.
If the application on the PC never reads any data the buffer on the PC (64kbytes) and the buffer on the chip will become full.
When these buffers are full the TXE# line should remain at logic 1 until the application on the PC does a read to free up some space.
Some users report TXE# goes back to logic 0 after a brief period (actually matches latency timer).
This can result in data loss due to overrun.
To prevent this from happening the application on the PC should have set flow control for RTS_CTS flow control.
Although the hardware does not have RTS/CTS pins the driver does not know this, but it is now forced to monitor certain status bits, which allows the TXE# pin to be kept at logic 1 until space is made available.

Maybe there are other FTDI Community users who can help you further.

Best Regards,
FTDI Community
Logged

abenitez

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Problem communicating PC and FPGA with UM245R
« Reply #2 on: March 13, 2021, 10:43:01 PM »

Hi, thanks for the reply. I have been using the TN 167 FIFO Basics, in fact, I used its FT_Write and FT_Read examples for my project. I think I narrowed a little bit more my problem, I got an osciloscope and design my example to transmit byte per byte one way (PC-FPGA) or the other (FPGA-PC) in order to see the states of RXF and TXE flags, and they do not behave as expected and as the datasheet and the TN 167 say. The TXE flag is always high (and even with this state there is transmision of data, I do not know how) and in the other example project the RXF flag is always low and the data is transmitted under this conditions. When the change of state occurs (a low for TXE or a high for RXF) the transmision stops inmediately, being impossible to re-startit. I would like to say that I configured the transmision of each byte for these examples every 1 second, so I could be able to see the change of states of both signals. The problem is still there, I do not know why.
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 612
    • View Profile
Re: Problem communicating PC and FPGA with UM245R
« Reply #3 on: March 16, 2021, 04:41:54 PM »

Hello,

Have you considered running a simple application like in TN_167 in Visual Studio?
This would take LabWindows/CVI out of the question which we don't support.

See TN_153 Instructions on Including the D2XX Driver in a Visual Studio Express 2013 Project.

Have you tried setting the latency timer to the minimum of 1ms?

Also ensure that you are sampling on the correct edge.

Best Regards,
FTDI Community
Logged