Trying To Get Fmc Carrier S6 Usb-uart Working

[helmutforren]

I have an FMC Carrier S6 board.  I'm using Xilinx ISE Design Suite 14.7.  

 

My program is periodically sending out a text string.  I can probe the TXD_IN pin 13 of the IC11 FT232HQ on the FMC Carrier S6 board, and I see the characters at the desired 115,200 baud.

 

However, on my host PC I don't see the text strings coming in.  Specifically, the virtual port comes up as COM13, and I've connected to it with TeraTerm configured for 115,200,8,N,1.  

 

I've used both FTDI usb-to-serial adapters and Teraterm a great deal.  I should have that all done correctly.  In fact, I have two other usb-to-serial adapters plugged in right now.  In the Windows 7 device manager, the other two are using an FTDI driver version 2.10.0.0 dated 1/27/2014.  The COM13 I'm on is using an FTDI driver version 2.12.0.0 dated 8/26/2014.  I would *not* think this difference is a problem.

 

I also have another copy of TeraTerm connected to one of those other serial ports, and it's working bi-drectionally just fine.

 

So why is this one not working?

    - There is TX data being sent to the FT232HQ chip at the correct baud rate.

    - I have a terminal program at the correct baud rate connected to the correct virtual serial port.

 

There's got to be something I'm missing here.  Below is a list of considerations:

    - The FMC Carrier S6 schematic does NOT provide a EEPROM to the FT232HQ.  I hope this means the FT232HQ operates in default UART mode... which should be fine.

       (Page 5, https://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC%20Carrier-S6_sch.PDF)

    - I have always assumed that when from TeraTerm I configure the port baud rate, bits and stuff, that the software driver commumicates over USB some special commands to the FT232HQ

        in order to configure its TX/RX pins to the desired baud rate, bits and stuff.  Is this perhaps not the case?

    - Is there anything else I need to do in order to get the USB side actually transferring characters ?

 

Your help is greatly appreciated.

[helmutforren]

Yep.  I just found it.  I just came back here to answer.  Here's the clipboard text I was about to paste:

 

Fixed.  Age old RS-232 problem:  swap RX/TX.  It turns out that TXD_IN on the FMC Carrier S6 schematic is not the input to the FT232H that then gets transmitted out USB.  No, it's the transmit FROM the FT232H that goes IN to the FPGA.  So I swapped FPGA pins U10 and T10, and it started working.  T10 is FPGA RX.  U10 is FPGA TX.

 

Funny, that's backwards from your email, hihaita!  It seems YOU may have also fallen into that trap just now.  It's so easy to get these reversed.  Note, I now see in the FMC Carrier S6 datasheet, that T10 has an arrow pointing into it.  That's correct.  The FT232HQ next to it has that line labeled TXD.  That's correct from the FT232HQ perspective.  But from the FPGA perspective, TX is U10.

Whatever!  If somebody reading this can't get it working, just twy swapping.

 

Thanks for your help, regardless.  I might not have found it already, and your advice would have led me to trying the swap.  (I should know better.  Been doing RS-232 for 39 years.)

[Mihaita]

Hello helmutforren,

 

Are you sure you correctly mapped the FPGA RX/TX pins?

What I do know is that pin U10 of the FPGA should be output on the FPGA, hence input for the FTDI; pin T10 set as input on the FPGA and output of the FTDI.

 

That means that from the FPGA standpoint: Uart Tx = U10, Uart Rx = T10.

 

- Mihaita

[helmutforren]

Of course, it's never that simple!

 

Now I'm running out of .text linker space.  I saw this a little bit before.  It's funny.  The instruction printf("hello worldn") compiles successfully.  Omit the "n" from the string and it does not.  I guess the compiler is doing some under-the-covers optimization, using like a writeln() if there's a carriage return, but using a different, larger function if not -- and there's no room for the larger function.  (My real intent is use % format string to output some debugging values.  Ading the % format string also causes the .text error.)

 

Here's the error message:

m:/xilinx/14.7/ise_ds/edk/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.6.4/../../../../microblaze-xilinx-elf/bin/ld.exe: LockinAmp.elf section `.text' will not fit in region `ilmb_cntlr_dlmb_cntlr'

m:/xilinx/14.7/ise_ds/edk/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.6.4/../../../../microblaze-xilinx-elf/bin/ld.exe: region `ilmb_cntlr_dlmb_cntlr' overflowed by 7928 bytes

 

In XPS, I've given ilmb_cntlr and dlmb_cntlr 64K bytes each.  If I try to give them next next highest value, 128K, the [synthesis?] fails.  I'm using an XC6SLX45.  I read it should have 116 blocks of 18K, totalling 2088K.  I'm far under that.  So maybe 64K is stingy and my problem is my failing [synthesis?] with 128K...

 

I haven't written much code yet at all.  So I'm thinking there's some kind of snafu.  Any clue as to what that snafu might be?

[JColvin]

Hi helmutforren,

 

I am by no means an FPGA expert so I can't guarentee this will solve your problem, but did you regenerate your linker script? Apparently, according to this Xilinx post, you need to regenerate the linker script in order to have the new values of 128K be updated.

 

Thanks,

JColvin

[duskwuff]

The instruction printf("hello worldn") compiles successfully.  Omit the "n" from the string and it does not.  I guess the compiler is doing some under-the-covers optimization, using like a writeln() if there's a carriage return, but using a different, larger function if not -- and there's no room for the larger function.

 

The compiler is optimizing printf("hello worldn") to puts("hello world"). Without the n, it can't use puts, so it has to pull in the whole printf() implementation. Depending on the libc you're using, printf can be rather large, particularly as it often pulls in large chunks of floating-point code (for %f). You may want to consider using a purpose-built printf() implementation that leaves out unnecessary features.