UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
274 Views
Registered: ‎10-10-2018

Data garbled for baud rate > 115.2K for Zynq

Jump to solution

I have been working successfully for some time on a MicroZed (Zynq 7020) with UART1 at 115,200 baud.  I use a Windows 7/64 laptop with an Adafruit "CP2104 Friend" dongle and RealTerm terminal software.

I now want to boost the baud rate to 230,400 or 460,800.  The FPGA design was created by someone else, who suggested that I could change the baud rate in Vivado in the Block Design (PS-PL Config, choose from baud rate drop list for UART1).  I did this change (460,800 option) and regenerated bitstream, changing a version number as well to be sure this was the bitstream that got loaded.

In my ARM app, I am also calling the BSP's UART driver function XUartPs_SetBaudRate().

If I set baud rate via this function to 115,200 or lower, everything communicates cleanly (despite Vivado design being set for 460,800).  However, if I try to set for 230,400 or 460,800, I see in RealTerm either nothing or else very garbled data.

The FPGA designer suggested there could be enough difference between serial clocks of the two devices that they cannot properly sync on the serial stream.  230,400 seems a pretty low rate for that to occur.

Given that I don't have easy access to any kind of scope... What else can I try, or registers to check, to find out why 230K and 460K aren't working for me?

Thanks!  P.S.  some of my parameters:

/* Definitions for driver UARTPS */
#define XPAR_XUARTPS_NUM_INSTANCES 1

/* Definitions for peripheral PS7_UART_1 */
#define XPAR_PS7_UART_1_DEVICE_ID 0
#define XPAR_PS7_UART_1_BASEADDR 0xE0001000
#define XPAR_PS7_UART_1_HIGHADDR 0xE0001FFF
#define XPAR_PS7_UART_1_UART_CLK_FREQ_HZ 50000000
#define XPAR_PS7_UART_1_HAS_MODEM 0

/******************************************************************/

/* Canonical definitions for peripheral PS7_UART_1 */
#define XPAR_XUARTPS_0_DEVICE_ID XPAR_PS7_UART_1_DEVICE_ID
#define XPAR_XUARTPS_0_BASEADDR 0xE0001000
#define XPAR_XUARTPS_0_HIGHADDR 0xE0001FFF
#define XPAR_XUARTPS_0_UART_CLK_FREQ_HZ 50000000
#define XPAR_XUARTPS_0_HAS_MODEM 0

0 Kudos
1 Solution

Accepted Solutions
Contributor
Contributor
195 Views
Registered: ‎10-10-2018

SOLUTION: Data garbled for baud rate > 115.2K for Zynq

Jump to solution

[Short answer: Hardware configuration error -- a DIP switch on "carrier" card was in wrong position]

After several hours of experimentation, web searches and couple of phone calls with my FPGA consultant, I have found and fixed my issue.  My setup is the combo from Avnet of Zynq-based MicroZed board with their Embedded Vision "carrier" board.  The two boards are joined by 200 signals across "micro header" connectors.  These products are for R&D and thus have lots of configurability.  Some signals from the Zynq are routed to multiple connectors.

The essence of my problem was that I should have had a certain DIP switch in the Off position (#3 of SW1 on the carrier board). In the On position, it was connecting two sections of circuitry, one of which was not intended.

The documentation did mention a couple of times about certain MIO pins should "not be simultaneously used by both the MicroZed and MicroHeader interfaces".  This was a clue but I had to dig deeper to understand.

See section 2.8.1 in:  http://microzed.org/sites/default/files/documentations/MicroZed_HW_UG_v1_4.pdf

Also sections 2.4.1 User Push Buttons, 2.4.2 User LEDs in:  http://zedboard.org/sites/default/files/documentations/5188-UG-AES-MBCC-EMBV-DEV-G-V1.pdf

They never quite explain the use of the 4 DIP switches, instead referring always to SW1 for buttons, LEDs, etc.  But by trial-and-error, I found that position 3 in SW1 is the critical switch for my TX problem.  I am now able to successfully transmit to at least 921K baud, rather than being limited to < 200 K baud.

uzed_carsw.JPG
0 Kudos
4 Replies
Xilinx Employee
Xilinx Employee
253 Views
Registered: ‎09-14-2018

回复: Data garbled for baud rate > 115.2K for Zynq

Jump to solution

hi @jsam062 

Most time if you get garbled data from terminal, it's because of baud rate is not configured correctly.

I think you can try:

1. Set your terminal to series of different baud-rates to see if it works at one of them. You may find some clues from it.

2. Refer to "19.2.3 Baud Rate Generator" of UG585 to find out how baud rate is generated by seviral registers. Sometimes drivers may have bugs, but it's always cool to check the registers under the hood.

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

Contributor
Contributor
229 Views
Registered: ‎10-10-2018

Re: Data garbled for baud rate > 115.2K for Zynq

Jump to solution

I have done some experiments and gathered additional information.  My observations suggest some sort of hardware limitation on the MicroZed board.

Areas which do work:

1. Zynq can RX incoming data from outside device at up to 921,600 baud cleanly (I only tried up to this rate, higher might also work).

2. Zynq UART using internal loopback mode can TX/RX cleanly up to 921,600

3. Simple wired loopback of Zynq UART (see image - short jumper wire between TX/RX connector pins on board) can TX/RX cleanly for any rate up to 167,700 baud (repeatable).  It falls apart at 167,800 baud (repeatable) and for everything higher.

I repeated the testing with two different units and two different jumper wires and got exactly the same results.

There seems to be a definite electronic limit happening here.

Should I be looking more closely at the MicroZed board's design and talking to Avnet?

Thanks!

uzed_uart1.JPG
0 Kudos
Xilinx Employee
Xilinx Employee
200 Views
Registered: ‎09-14-2018

Re: Data garbled for baud rate > 115.2K for Zynq

Jump to solution

hi @jsam062 

Nice test!

I think you can definitely use a oscilloscppe to see if the signal goes bad.

 

-chaoz

0 Kudos
Contributor
Contributor
196 Views
Registered: ‎10-10-2018

SOLUTION: Data garbled for baud rate > 115.2K for Zynq

Jump to solution

[Short answer: Hardware configuration error -- a DIP switch on "carrier" card was in wrong position]

After several hours of experimentation, web searches and couple of phone calls with my FPGA consultant, I have found and fixed my issue.  My setup is the combo from Avnet of Zynq-based MicroZed board with their Embedded Vision "carrier" board.  The two boards are joined by 200 signals across "micro header" connectors.  These products are for R&D and thus have lots of configurability.  Some signals from the Zynq are routed to multiple connectors.

The essence of my problem was that I should have had a certain DIP switch in the Off position (#3 of SW1 on the carrier board). In the On position, it was connecting two sections of circuitry, one of which was not intended.

The documentation did mention a couple of times about certain MIO pins should "not be simultaneously used by both the MicroZed and MicroHeader interfaces".  This was a clue but I had to dig deeper to understand.

See section 2.8.1 in:  http://microzed.org/sites/default/files/documentations/MicroZed_HW_UG_v1_4.pdf

Also sections 2.4.1 User Push Buttons, 2.4.2 User LEDs in:  http://zedboard.org/sites/default/files/documentations/5188-UG-AES-MBCC-EMBV-DEV-G-V1.pdf

They never quite explain the use of the 4 DIP switches, instead referring always to SW1 for buttons, LEDs, etc.  But by trial-and-error, I found that position 3 in SW1 is the critical switch for my TX problem.  I am now able to successfully transmit to at least 921K baud, rather than being limited to < 200 K baud.

uzed_carsw.JPG
0 Kudos