Nexus Video UART Issue

[zygot]

Moderator's Note: Digilent strongly discourages using FT_PROG to reprogram the FTDI devices on the Nexys Video. This utility can permanently break certain functionality on this board. If you have a problem using UART, please create a new topic on this forum. Please read on for further information.

Hey Nexus Video users:
I ran into an issue with my first project using this board because I require the use of the UART. I spent quite some time tracking down what I thought was a non-connectivity issue between the FT232R Tx output and the FPGA pin. It turns out that in my case the FT232R eeprom was mis-programmed. The FT232R CBUS2 GPIO pin was programmed as a TXen input. Of course there are no traces on CBUS2, CBUS3 or CBUS4 so any functionality associated with them might cause problems. You can get the FT_PROG application from FTDI to correct this. The only 2 CBUS IO with connectivity are CBUS0 and CBUS1 which were correctly set as LED indicators.

To Digilent Management: Shame on you for expecting your customers to do your engineering work.
To Digilent Engineers: This issue is a reason why you HAVE to provide documentation and demo code that exercises ALL of the board functionality. If you think that you can't afford to do your due diligence consider that your customers can't afford to buy from a vendor that wastes their time.

[sbobrowicz]

First off, I need to be clear here: Nexys Video users should not use FT_PROG to program the FT232R on the Nexys Video. It's unlikely, but you could damage your board or put the UART in an unusable state if not careful. Moreover, this will not solve any problems you are having with using the UART on the Nexys Video. The FT232R functionality is tested on all Nexys Videos after manufacturing, and if you are having a problem using it, please create a new post on this forum and we will help you get to an answer.

zygot, I'm assuming you are saying that CBUS2 is set to TXDEN, which is no surprise as that is its default setting. This would not cause any problems though, because that is actually an output meant to drive a buffer when in RS485 Mode (see page 29 of the FT232R datasheet). If you agree with this, I'd ask that you edit your initial post to stop suggesting that people use FT_PROG. 

It seems like you managed to get UART working now, but if you'd like to provide some more information on the issue you were experiencing, we can investigate it further here. 

Edit: Regarding your comments on lack of documentation, please visit this site: https://reference.digilentinc.com/nexys-video:start . You can find reference projects there that exercise all of the features on the Nexys Video.

[hamster]

I just had to see if this was the case - below is the code I am using to show incoming characters on the LEDs, and send '0' over and over again. Works as it should.

Constraints:

## Clock
set_property -dict {PACKAGE_PIN R4 IOSTANDARD LVCMOS33} [get_ports clk100]
create_clock -period 10.000 -name clk100 -waveform {0.000 5.000} [get_ports clk100] 

## LEDs 
set_property PACKAGE_PIN T14 [get_ports {led[0]}] 
set_property IOSTANDARD LVCMOS25 [get_ports {led[0]}]
set_property PACKAGE_PIN T15 [get_ports {led[1]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[1]}]
set_property PACKAGE_PIN T16 [get_ports {led[2]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[2]}]
set_property PACKAGE_PIN U16 [get_ports {led[3]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[3]}]
set_property PACKAGE_PIN V15 [get_ports {led[4]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[4]}]
set_property PACKAGE_PIN W16 [get_ports {led[5]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[5]}]
set_property PACKAGE_PIN W15 [get_ports {led[6]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[6]}]
set_property PACKAGE_PIN Y13 [get_ports {led[7]}]
set_property IOSTANDARD LVCMOS25 [get_ports {led[7]}]

##UART
set_property -dict {PACKAGE_PIN AA19 IOSTANDARD LVCMOS33} [get_ports uart_rx_out] 
set_property -dict {PACKAGE_PIN V18 IOSTANDARD LVCMOS33} [get_ports uart_tx_in] 

 

VHDL file:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity rs232_test is
    Port ( clk100      : in  STD_LOGIC;
           uart_rx_out : out STD_LOGIC;
           uart_tx_in  : in  STD_LOGIC;
           led         : out STD_LOGIC_VECTOR (7 downto 0) := (others => '0'));
end rs232_test;
architecture Behavioral of rs232_test is
    signal tx_in_counter  : unsigned(19 downto 0)        := (others => '0');
    signal rx_out_counter : unsigned(19 downto 0)        := (others => '0');
    signal char_to_send   : std_logic_vector(7 downto 0) := "00110000";
begin
process(clk100)
    begin
        if rising_edge(clk100) then
            -------------------------------------------
            -- Sending out the character over and over
            -------------------------------------------
            case rx_out_counter is
                when to_unsigned(100000000/9600*0,20) => uart_rx_out <= '0'; 
                when to_unsigned(100000000/9600*1,20) => uart_rx_out <= char_to_send(0); 
                when to_unsigned(100000000/9600*2,20) => uart_rx_out <= char_to_send(1); 
                when to_unsigned(100000000/9600*3,20) => uart_rx_out <= char_to_send(2);
                when to_unsigned(100000000/9600*4,20) => uart_rx_out <= char_to_send(3); 
                when to_unsigned(100000000/9600*5,20) => uart_rx_out <= char_to_send(4); 
                when to_unsigned(100000000/9600*6,20) => uart_rx_out <= char_to_send(5); 
                when to_unsigned(100000000/9600*7,20) => uart_rx_out <= char_to_send(6); 
                when to_unsigned(100000000/9600*8,20) => uart_rx_out <= char_to_send(7); 
                when to_unsigned(100000000/9600*9,20) => uart_rx_out <= '1'; 
                when others                               => NULL;
            end case;
            rx_out_counter <= rx_out_counter + 1;
            
            ----------------------------------------------
            -- Receiving the character and show it on LEDs
            ----------------------------------------------
            if tx_in_counter = 0 then
                if uart_tx_in = '0' then
                    tx_in_counter <= tx_in_counter + 1;
                end if;
            else
                tx_in_counter <= tx_in_counter + 1;
                case tx_in_counter is
                    when to_unsigned(100000000/9600*15/10,20) => led(0) <= uart_tx_in; 
                    when to_unsigned(100000000/9600*25/10,20) => led(1) <= uart_tx_in;
                    when to_unsigned(100000000/9600*35/10,20) => led(2) <= uart_tx_in;
                    when to_unsigned(100000000/9600*45/10,20) => led(3) <= uart_tx_in;
                    when to_unsigned(100000000/9600*55/10,20) => led(4) <= uart_tx_in;
                    when to_unsigned(100000000/9600*65/10,20) => led(5) <= uart_tx_in;
                    when to_unsigned(100000000/9600*75/10,20) => led(6) <= uart_tx_in;
                    when to_unsigned(100000000/9600*85/10,20) => led(7) <= uart_tx_in;
                    when to_unsigned(100000000/9600*95/10,20) => tx_in_counter  <= (others => '0');
                    when others =>
                end case;
            end if;
        end if;
    end process;
end Behavioral;

[zygot]

You are correct about the functionality of the CBUS2 pin and configuring it to TxDen functionality. It is an output not an input. So I was wrong about changing its configuration. Regardless, the Txd pin on the FT232R was not being driven before I programmed the eeprom. The only changes to the configuration that I made was to the functionality of the IO pins that are unconnected. Everything else read by the FTDI utility appeared to be correct. So I have no explanation for why programming the part made it work. Either the functionality of the FT232R TXd was not tested before it was shipped to me or it failed after I powered the board. When I programmed the eeprom configuration for CBUS2 from TXen to IO I was able to receive data from a terminal. Clearly something changed that was different from my intention. Before using the programming utility the FT232R Txd was undriven. I proved that by, as I mentioned, routing the UART tx-in pin on the FPGA to a PMOD pin and observing it on an oscilloscope. I knew that I was getting data to the FT232R through the USB because the Rx LED was blinking even though the FPGA was not receiving any transitions on its UART RxD pin. My design started working perfectly once the FT232R was re-programmed; and I did not reconfigure the FPGA during that process. So now I have a mystery that is more bothersome than getting a board that was not properly tested. I'm not an expert on FTDI devices nor privy to unpublished information about their products but I'm interested in hearing plausible explainations.

On the topic of users rendering their FT232R device useless I have an opinion on that. There are certain IC vendors who think that It's OK to design products that can be rendered useless, either by accident or nefariously in the field through software. It is NOT OK. The fact that a vendor does something stupid doesn't mean that a designer using such a device has to be complicit in the folly. The FT_Prog application clearly warns the user that if you program the device to use an external oscillator and there is none you will brick your device. A competent designer (given the time time to do the work properly), not wanting to use an external oscillator with this part will, at least, provide some traces and pads so that an oscillator can be connected in an emergency. This does not take that much effort or add appreciable cost to either develop or produce the product. Another option is to just not use such parts and let your vendor's sales rep know why.

There are two schools of thought when it comes to problems or potential problems. One is to pretend that they don't exist and hope that no one finds out about them accidentally or intentionally . The other is to address them in the design phase so that no one has to worry about them. I understand that some of your customers might be inexperienced. Every company that sells a product has customers who find a way to do something unexpected or silly with it. Help and educate them.

[sbobrowicz]

Your description of the problem does suggest that the FTDI part was temporarily in a state where it was not functioning properly, but without the problem presenting, there really isn't any way to investigate it further. I get your frustration here, you spent a lot of time debugging this problem, yet the cause is still not clear. All I can really offer is that if the problem presents again, post here immediately and we can run some tests to get to the bottom of it. The good news is that you have a fully functioning Nexys Video.

Regarding our design practices, we treat the FT232R device and its firmware as a sub-component of the Nexys Video that provides a USB-UART bridge to the FPGA. If a customer contacts us and it becomes clear that the USB-UART bridge is not performing correctly, our support team would deem the Nexys Video as non-functioning and proceed with an RMA request. A case like yours where the UART_TX_in pin was not toggling definitely would have fallen into this category. 

When it comes to the FT232R, there is no way to prevent users from reprogramming the part into an unusable state (the oscillator concern you mention is not the only way to brick the device). Doing this, however, requires completing a very deliberate procedure that is plastered with warning signs along the way. The fact is that our customers are not approaching us with boards that have had their FTDI parts bricked due to accidental reprogramming so there really isn't a problem to solve here.

edit: Can you please edit in a note at the end of your initial question so that people are at least aware that they do not need to use FT_PROG and that it is potentially dangerous? 

[zygot]

Sam,

I'm not sure what you mean by editing the initial question. I only see how to add to the message thread.

We certainly agree that using the FT_PROG utility from FTDI can potentially render either of the FTDI devices on the Nexus Video useless and should be used with caution and at the users own risk. I'll concede that using the utility should not have caused any desirable change in its functionality and should not be necessary. And yet for me doing so, for reasons unknown, fixed an issue that only would have been resolved ony by returning the board for a replacement.  ( I actually sent a request to Digilent Support to authorise an RMA a few minutes before getting the idea to check the device configuration.  )

I invite you to run all of the available demos for this board and the Genesys 2 and tell me which one uses user input from the UART. I've been through all of the code and the answer is none. The first thing that I do when getting a new development platform is to check out all of it's functionality with the vendor's demo. This saves me from wasting time trying to develop an application that uses a feature that doesn't work, In the past I could do that with (most of) Digilent's products. In fact, both boards have an Adept parallel interface that isn't supported by any Adept API. Neither board can use the Windows Adept utility to program the FPGA.... etc, etc.

 

[sbobrowicz]

I'm not sure what you mean by editing the initial question. I only see how to add to the message thread.

Sorry, you may not have the ability to edit questions, I'll have to ask the admins about that. I added a note to the original question.

I invite you to run all of the available demos for this board and the Genesys 2 and tell me which one uses user input from the UART.

You are correct, thanks for pointing this out. We have a video project that uses UART input that will be released for the Nexys Video soon, and then the Genesys2. We also have someone adding a UART_RX core to the Basic GPIO design we post for our products. Again, thanks for reporting this mistake, we are working to fix it.

both boards have an Adept parallel interface that isn't supported by any Adept API

Let's move this discussion over to your other thread:  https://forum.digilentinc.com/topic/1321-adept-dpti-support/ .

Neither board can use the Windows Adept utility to program the FPGA

This should not be the case, I just tested it with my boards. If you cannot program your boards using the Adept System GUI in Windows please create a new topic and we will investigate the problem.