UART - How is it used? (Nexys 3)

[krb686]

I've got the Nexys 3 board and it's reading some data from a peripheral, but I can't debug what's on the board because I'm not about to spend 600+ on chipscope.  So I've thought about the possibility of using the UART to send data back to the PC to analyze there, but the problem is there's really just about zilch information out there on how to use the UART on this board.  Let's be honest, the  Digilent Nexys 3 user guide (pg 12) is absolutely useless in this regard.  It explains what the UART does from a high level, and mentions using free FTDI drivers, but has absolutely no information whatsoever on how to actually use this feature. 

I've tried approaching this at a xilinx angle, searching for "UART cores", which are hard to find, potentially not free, and not simple to actually implement or use. (I managed to acquire a "XPS 16550 UART" license, but can't figure out the first thing about how to use it, since Xilinx loves to massively overcomplicate what should be simple instructions)

 

So I'm abandoning that approach, and now I'm here. Shouldn't there be an easy way to get, this UART up and running?

[hamster]

Here's a little project that can Log 11 pins over the UART, as ASCII  1s and 0s:

 

http://hamsterworks.co.nz/mediawiki/index.php/Log_Pins

 

It will be fine for slow speed debugging. For high speed designs you will need to store the information of interest, then send it out, which is quite a bit more complex.

 

I've got a smallish project to do that too...

 

http://hamsterworks.co.nz/mediawiki/index.php/CheapScope

 

.. however it is a lot more complex to get working.

 

Building up a toolkit of debug strategies is one of the harder bit of FPGA development. You can connect signals to PMOD pins, allowing you to hook up an external Logic Analyser. You can use the LEDs or 7segment display to view state information.

 

But here are my most useful tips:

 

* Always start  with LEDs that do something, even if it is only blinking. I have spent a long time trying to get projects to work where the code was perfect but the clock signal was connected to the wrong pin.

 

* Always check your pinout report to check that everything is connected to the outside world correctly.

 

* 10 minutes writing a reasonable test bench will save an hour debugging on hardware

 

* Start small - don't try and bring an entire project up at once. Verify it in small parts in isolation before connecting them all together

 

* Work out what coding styles/patterns actually work more reliably, and use them first before trying the more bug-prone ones. I like using (sometimes very long) shift registers to push commands to a new device over coding an uber-complex state machine or a soft-CPU solution. For example, here is part of a design for mucking around with SD cards... you wouldn't do this in a 'real' design, but for experimenting having a 1024 bit shift register to play canned commands is a great way to make something happen:

 

-- Loop through the first 8 bits for a while, then bring up the data lines
seq_mosi(1023 downto 896) <= x"0000FFFFFFFFFFFFFFFFFFFFFFFFFFFF"; -- Sequencing for powerup (must be at least 80 clocks)
seq_cs (1023 downto 896) <= x"0000FFFFFFFFFFFFFFFFFFFFFFFFFFFF";
seq_scke(1023 downto 896) <= x"000000FFFFFFFFFFFFFFFFFFFFFFFFFF"; -- I use 104 clocks
powerup_address <= 1016;

-- Then reset the card
seq_mosi(895 downto 832) <= x"FF400000000095FF"; -- CMD0 - should return 0x01 - busy.
seq_cs (895 downto 832) <= x"FF00000000000000";
seq_scke(895 downto 832) <= x"FFFFFFFFFFFFFFFF";
response_init <= 832;

-- This command has to be sent for SDHC cards to reveal their true identity...
-- See http://www.netlist.com/files/6313/9482/1001/DS_SDVAULT_1v9_GENERAL.pdf
seq_mosi(831 downto 704) <= x"FF48000001AA87FFFFFFFFFFFFFFFFFF"; -- CMD8 - SEND_IF_COND (SEND INTERFACE CONDITIONS)
seq_cs (831 downto 704) <= x"FF000000000000000000000000FFFFFF"; -- should gives x09 for v1.x cards, a 48-bit reply for v2.x cards
seq_scke(831 downto 704) <= x"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; -- "01AA" = 2.7-3.3V, check pattern of 'AA'
response_cmd8 <= 768;
v1_v2_decision <= 704;

 

Oh, and for our hobby projects ChipScope is expensive, but in the commercial world it pays for itself if the insight it offers solves one thorny "stuck for a couple of days" bug.

[hamster]

Oh, and if you currently don't have enough experience with the RS232 protocol to implement and troubleshoot it, this link will help.

 

http://www.fpga4fun.com/SerialInterface.html

 

And actually a qn for Digilent, looking at the Nexys3 reference manual, why is the signal from RXD to N18 bidirectional? Surely it is an output only pin on the FPGA?

[JColvin]

Hi hamster,

 

Yes, the RXD to N18 should (and is) only an output pin on the FPGA. What you see in the image is incorrect and just hasn't been corrected and re-uploaded yet.  Hence why we have created the Digilent wiki so that mistakes like this can be corrected quickly, which I have done now

 

Thanks,

JColvin

[krb686]

Thanks for the help, hamster.  I got this to work surprisingly, and I am successfully reading in some data to a python script.  It works similar to the script you sent me.  While I was getting this working, I encountered something interesting on my Analog Discovery that I'm making a separate post about, and I'll link to it from here.