cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
4,222 Views
Registered: ‎12-15-2016

Weird characters on Terminal (SEM IP, Monitor Interface)

Hello,

 

I'm using the Zybo board. I have a design like the following one:

 

Καταγραφή.JPG

 

On the SDK, I have a code like the following one to handle data exhange between PS Uart0 (where the SEM signals are connected, monitor_rx and monitor_tx) and the device's UART1 that is responsible for stdin,stdout transmission:

 

for(;;)
{

if (XUartPs_IsReceiveData(((&xuartps0)->Config.BaseAddress)))
{
XUartPs_SendByte(((&xuartps1)->Config.BaseAddress),XUartPs_RecvByte(((&xuartps0)->Config.BaseAddress)));
} if (XUartPs_IsReceiveData(((&xuartps1)->Config.BaseAddress)))
{
XUartPs_SendByte(((&xuartps0)->Config.BaseAddress),XUartPs_RecvByte(((&xuartps1)->Config.BaseAddress)));
}

}

 

I set up SDK's terminal with a 9600 baud rate like that:

 

Καταγραφή4.JPG

 

And after I program the FPGA and run the code I get something like this:

 

Καταγραφή3.JPG

 

While I was expecting something like this:

 

Καταγραφή5.JPG

 

SEM IP was configured with a 100 MHz clock, TeraTerm baud rate is 9600, Uart0 and Uart1 are configured with a baud rate of 115200.

 

I tried changing the baud rate of one of the two, or both PS-Uarts with the XUartPs_SetBaudRate(&xuartps0, 9600); function, but the outcome is even worse than the first try (less and more weird characters). I also tried to change the BaudRate of SEM by changing the V_ENABLETIME (to 115200) variable before the creation of the IP, but the results was more of the same. I also tried running the code with TeraTerm on 115200 baurate but nothing changed.

 

Any ideas on why it doesn't work?

 

 

0 Kudos
8 Replies
Highlighted
Scholar
Scholar
4,168 Views
Registered: ‎04-13-2015

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

This may be due to a bad RS323 signal level.

Looking at the first few wrong characters:

Z instead of X

e instead of E

6 instead of 4

and checking the the bit pattern that should be on the line.

Here, S is the start bit, s is the stop bit and FYI, RS-323 transfers LSBit first:

 

X  S 0 0 0 1 1 1 0 0 s

Z: S 0 1 0 1 1 1 0 0 s

2nd data bit is seen as a 1 instead of a 0. the rest is OK

 

E: S 1 0 1 0 0 0 1 0 s

e: S 1 0 1 0 0 1 1 0 s

6th  data bit is seen as a 1 instead of a 0. the rest is OK

 

4 : S 0 0 1 0 1 1 0 0 s

6 : S 0 1 1 0 1 1 0 0 s

2nd data bit is seen as a 1 instead of a 0. the rest is OK

 

This doesn't look like a clock mismatch to me but a line level issue.

After a few wrong bits, it is possible the UART receiver could lose sync with the start & stop bit because UART will typically resync their internal sampling at every bit transitions,

 

If you have access to a scope, it wouldn't harm to look at the UART line. The standard requires between +3 -> +15 V for a "0" and between -3 -> -15 V for a "1".

 

Good luck.

Regards

 

 

Highlighted
Visitor
Visitor
4,126 Views
Registered: ‎12-15-2016

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

Thank you so much for your help!

 

So, the bad signal level could possibly reveal a problem on the board, or is it related to something I did on the design, code etc? You said, that I should look on the UART Line for errors. How exactly can this be done?

 

I also want to mention that the "for loop" is a standard code I found on the Internet (specifically, on a tutorial video for SEM integration on the UltraScale+ devices). I was wondering, if XuartPS_SendByte is the right function to use. Is it possible that due to the way it works, some bits are not transmitted and the result I get on the terminal is looking weird? Lastly, I think about how it is possible for the whole thing to work in the first place, because of the difference in baud rates. I mean SEM is 9600, Uart0 is 115200, same for Uart1 and Terminal is 9600. Shouldn't they all have the same baud rate?

 

Thank you!

0 Kudos
Highlighted
Scholar
Scholar
4,111 Views
Registered: ‎04-13-2015

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

Normally there should be matching baud rate between UART0 & SEM

The baud rate for UART1 should match your terminal setting.

You've indicated this set-up was tested and it was worst.

Without going into details, your specific baud rate mismatch would normally provoke the loss of bits (not the flipping), more likely losing sequences of 1's and one 0's as the receiver waits for the stop and start bits; the first few chars in error don't show that.

 

Try to go back to the UART0-SEM at 9600 and UART1-terminal at 115600 set-up and make sure the # of bit matches between UART0 & SEM / UART1 & Terminal.

Try 7 and 8 bits.

The number of stop bit is only relevant for the TX side, simply make sure the RX side is set to 1.

 

The UARTs transmitter shouldn't be the cause of the flipped bits.

They are fed full bytes and send them serially.

Serial bit errors are very rarely caused by the transmitter; transmitter errors are typically loss of byte due to uncontrolled over feeding of the UART.

 

Regards

 

 

0 Kudos
Highlighted
Visitor
Visitor
3,998 Views
Registered: ‎12-15-2016

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

Thanks for your answer.

 

I tried adding a few more lines of code and I managed to get a different output on the terminal, this time for a 9600 baud rate for all 4 components (SEM, Uart0&1, Terminal) which seems more logical:

 

Καταγραφή2.JPG

 

Now as you can see the last part of the output looks correct, but the first part doesn't. Good news is that the terminal reacts to  the command I send. For example the "S" command for a status report:

 

Καταγραφή3.JPG

 

The code I use for the main() function is the following:

 

int main()
{


	XUartPs xuartps0;
	XUartPs_Config *xuartps_config0;
	XUartPs xuartps1;
	XUartPs_Config *xuartps_config1;
	int status;
	int status1 =2;
	/*SETUP*/
	init_platform();
	Delay(200);
	init_GPIO();
	//init_TIMER();
	Delay(200);
	init_Dcfg();
    //Delay(200);



	XUartPsFormat xuartps0_format;
	XUartPsFormat xuartps1_format;



	xuartps_config0 = XUartPs_LookupConfig(XPAR_XUARTPS_0_DEVICE_ID);
	  if (xuartps_config0 == NULL) {
	    return XST_FAILURE;
	  }
	  XUartPs_ResetHw(xuartps_config0->BaseAddress);
	  status = XUartPs_CfgInitialize(&xuartps0, xuartps_config0, xuartps_config0->BaseAddress);
	  if (status != XST_SUCCESS) {
	    return XST_FAILURE;
	  }

	 xuartps0_format.BaudRate=9600u;
	 xuartps0_format.DataBits=XUARTPS_FORMAT_8_BITS;
	 xuartps0_format.Parity=XUARTPS_FORMAT_NO_PARITY;
	 xuartps0_format.StopBits=XUARTPS_FORMAT_1_STOP_BIT;
	 XUartPs_SetDataFormat(&xuartps0, &xuartps0_format);
	 XUartPs_SetFifoThreshold(&xuartps0,63u);/* Receive threshold*/
	 XUartPs_SetOperMode(&xuartps0,XUARTPS_OPER_MODE_NORMAL);
	 XUartPs_SetRecvTimeout(&xuartps0,4u);
	 XUartPs_EnableUart(&xuartps0);



	  xuartps_config1 = XUartPs_LookupConfig(XPAR_XUARTPS_1_DEVICE_ID);
	  	  if (xuartps_config1 == NULL) {
	  	    return XST_FAILURE;
	  	  }
	  	XUartPs_ResetHw(xuartps_config1->BaseAddress);
	  	  status1 = XUartPs_CfgInitialize(&xuartps1, xuartps_config1, xuartps_config1->BaseAddress);
	  	  if (status1 != XST_SUCCESS) {
	  	    return XST_FAILURE;
	  	  }

	  	xuartps1_format.BaudRate=9600u;
	  	xuartps1_format.DataBits=XUARTPS_FORMAT_8_BITS;
	    xuartps1_format.Parity=XUARTPS_FORMAT_NO_PARITY;
	  	xuartps1_format.StopBits=XUARTPS_FORMAT_1_STOP_BIT;
	  	XUartPs_SetDataFormat(&xuartps1, &xuartps1_format);
	  	XUartPs_SetFifoThreshold(&xuartps1,63u);/* Receive threshold*/
	  	XUartPs_SetOperMode(&xuartps1,XUARTPS_OPER_MODE_NORMAL);
	    XUartPs_SetRecvTimeout(&xuartps1,4u);
	  	XUartPs_EnableUart(&xuartps1);



	  	for(;;)
	  			{

	  				if (XUartPs_IsReceiveData(((&xuartps0)->Config.BaseAddress)))
	  				{
	  					XUartPs_SendByte(((&xuartps1)->Config.BaseAddress),XUartPs_RecvByte(((&xuartps0)->Config.BaseAddress)));
	  					//XUartPs_ReadReg(xuartps0,XUARTPS_FIFO_OFFSET);
	  					//XUartPs_Send(&xuartps1, XUartPs_RecvByte(((&xuartps0)->Config.BaseAddress)), 32);
	  			}			if (XUartPs_IsReceiveData(((&xuartps1)->Config.BaseAddress)))
	  						{
	  							//XUartPs_ReadReg(xuartps1,XUARTPS_FIFO_OFFSET);
	  				            //XUartPs_Send(&xuartps1, XUartPs_RecvByte(((&xuartps0)->Config.BaseAddress)), 32);
	  							XUartPs_SendByte(((&xuartps0)->Config.BaseAddress),XUartPs_RecvByte(((&xuartps1)->Config.BaseAddress)));

	  					}

	  			}






cleanup_platform();
return 0;
}

 

I tried making some changes to the UART1 Voltage through the Zynq PS Settings. The one I use here has the same settings as the monitor_rx, monitor_tx signals on the SEM constraints file:

 

 

Καταγραφή.JPG

 

 

A different project I tried with the same code and settings but with different SEM (and all the others too) baudrate of 115200 (I changed the V_ENABLEDTIME of SEM's .vhd file variable before creating the SEM IP) gives the following output (a little bit better) but doesn't respond to any command:

 

 

Καταγραφή4.JPG

 

What you suggested (SEM & Uart0 at 9600, Uart1 & Terminal at 115200) gives the following output and reacts to commands I send:

 

Καταγραφή5.JPG

 

 

You said "make sure the # of bit matches between UART0 & SEM / UART1 & Terminal". Do you mean actually counting the bits with a variation of a code like the following or something different altogether?

 

   /*
     * Send the buffer through the UartLite waiting til the data can be sent
     * (block), if the specified number of bytes was not sent successfully,
     * then an error occurred.
     */
    SentCount = XUartLite_Send(&UartLite, SendBuffer, TEST_BUFFER_SIZE);
    if (SentCount != TEST_BUFFER_SIZE) {
        return XST_FAILURE;
    }

    /*
     * Receive the number of bytes which is transfered.
     * Data may be received in fifo with some delay hence we continuously
     * check the receive fifo for valid data and update the receive buffer
     * accordingly.
     */
    while (1) {
        ReceivedCount += XUartLite_Recv(&UartLite,
                       RecvBuffer + ReceivedCount,
                       TEST_BUFFER_SIZE - ReceivedCount);
        if (ReceivedCount == TEST_BUFFER_SIZE) {
            break;
        }
    }

* The code was found here.

 

I was also thinking if the FIFO size or the fact that the whole system is not implemented in Interrupt mode plays a part.

 

Thank you!

 

0 Kudos
Highlighted
Visitor
Visitor
3,542 Views
Registered: ‎05-29-2017

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

Hi,

 

I had the similar problem. You should notice the SEM IP clock and baud rate relation.  In the MON shim system-level example design module, the parameter V_ENABLETIME should be set based on SEM IP clock and baud rate. for example for clock 8 MHz and desired baudrate 9600 , V_ENABLETIME should be 51. Also, FCLK should be the same as SEM IP clock.

 

please read the 38 and 39 of SEM_IP manual :pg036_sem.pdf.

 

Best

 

0 Kudos
Highlighted
Visitor
Visitor
1,975 Views
Registered: ‎01-29-2018

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

Hi,

I'd like to add SEM IP to my design. I included SEM example design as you did, but I noticed that the top-level entity doesn't have a direct access to icap_grant input, since it's fixed to 1 internally, while in your block diagram it is connected to the gpio of the MPSoC.

I'd like to ask you how do you control it...if you have a SDK code for this design to share it would be great!

I also noticed that  inject_strobe and inject_address are connected to  constant blocks(I guess it is because you want to use the monitor interface instead of error injection interface): do they have value 0?

Thanks.

 

Matteo

0 Kudos
Highlighted
Visitor
Visitor
1,918 Views
Registered: ‎01-29-2018

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

I left icap_grant tied to '1' as it is in the example design. I also mapped some status signal to leds, just to visualize the status of the controller. I'm using this code found in this therad:

https://forums.xilinx.com/t5/Embedded-Processor-System-Design/PCAP-configuration-for-Zynq-SEM-IP-core/m-p/643508/highlight/true#M29832

 

which is:

 

#include <stdio.h>
#include <xil_printf.h>
#include <xil_types.h>
#include "platform.h"
#include "xil_io.h"

int main()
{
    volatile unsigned int ctrl;
    volatile unsigned int reset;

    init_platform();
    xil_printf("Hello World\n\r");

    reset = Xil_In32(0xF8000240);
    xil_printf("RESETS: %08x\n\r",reset);

    Xil_Out32(0xF8000008,0x0000DF0DU);
    Xil_Out32(0xF8000240,0x0000000EU);  // to ensure icap_grant is 0

    ctrl = Xil_In32(0xF8007000);
    xil_printf("PCAP DEVCFG CTRL: %08x\n\r",ctrl);

    Xil_Out32(0xF8007000,(ctrl&(~0x08000000)));

    ctrl = Xil_In32(0xF8007000);
    xil_printf("ICAP DEVCFG CTRL: %08x\n\r",ctrl);

    xil_printf("ICAP granted\n\r");
    Xil_Out32(0xF8000240,0x0000000CU);  // icap_grant to 1

    reset = Xil_In32(0xF8000240);
    xil_printf("RESETS: %08x\n\r",reset);

    return 0;

}

 

The controller seems to work, since it asserts status initialization and then status observation, however I can't interact with the controller through ASCII characters, since the interface seems to be blocked to this status:

 

Hello Word

RESET: 00000000

PCAP DEVCFG CTRL: 4E00E07F

ICAP DEVCFG CTRL: 4600E07F

ICAP granted

RESETS: 0000000C

Anyone has a working SDK code to share?

Thanks.

0 Kudos
Highlighted
Visitor
Visitor
1,875 Views
Registered: ‎01-29-2018

Re: Weird characters on Terminal (SEM IP, Monitor Interface)

EDIT: Since the previous code doesn't seems to work, I tried another code, this time with a GPIO that asserts icap_grant after PCAP_PR bit 27 has been cleared:

#include <stdio.h>
#include <xil_printf.h>
#include <xil_types.h>
#include "platform.h"
#include "xil_io.h"
#include <unistd.h>
#include "xuartps.h"

 

int main()
{
init_platform();

XUartPs xuartps0;
XUartPs_Config *xuartps_config0;
XUartPs xuartps1;
XUartPs_Config *xuartps_config1;

int register_value;
int status;
int status1 = 2;

XUartPsFormat xuartps0_format;
XUartPsFormat xuartps1_format;


//----------------------------------------------------------------------------

//initialize the driver for UART0


xuartps_config0 = XUartPs_LookupConfig(XPAR_XUARTPS_0_DEVICE_ID);
if (xuartps_config0 == NULL) {
return XST_FAILURE;
}
XUartPs_ResetHw(xuartps_config0->BaseAddress);
status = XUartPs_CfgInitialize(&xuartps0, xuartps_config0, xuartps_config0->BaseAddress);
if (status != XST_SUCCESS) {
return XST_FAILURE;
}

xuartps0_format.BaudRate=9600u;
xuartps0_format.DataBits=XUARTPS_FORMAT_8_BITS;
xuartps0_format.Parity=XUARTPS_FORMAT_NO_PARITY;
xuartps0_format.StopBits=XUARTPS_FORMAT_1_STOP_BIT;
XUartPs_SetDataFormat(&xuartps0, &xuartps0_format);
XUartPs_SetFifoThreshold(&xuartps0,63u);/* Receive threshold*/
XUartPs_SetOperMode(&xuartps0,XUARTPS_OPER_MODE_NORMAL);
XUartPs_SetRecvTimeout(&xuartps0,4u);
XUartPs_EnableUart(&xuartps0);

 

//----------------------------------------------------------------------------

xil_printf("Hello world\n\r");

// Transfer control of the PL configuration logic
// from PCAP to ICAP, as ICAP is used by SEM IP. This is
// accomplished by clearing PCAP_CTRL (0xF8007000) register
// bit 27, which is named PCAP_PR.

register_value = Xil_In32(0xF8007000); //read PCAP_CTRL
register_value = register_value & 0xF7FFFFFF; //clear PCAP_CTRL, bit 0 [ICAP]
Xil_Out32(0xF8007000, register_value); // write PCAP_CTRL


sleep(2);

// set pin zero of GPIO into the PL to logic one.

register_value = Xil_In32(0xE000A284); //read DIRM_3 : DIRECT_MODE: 
register_value = register_value | 0xFFFFFFFF; // set_DIRM_3, bit 0 [OUTPUT]
Xil_Out32(0xE000A284, register_value); //write DIRM_3

register_value = Xil_In32(0xE000A288); //read OEN_3 : OUTPUT_ENABLE: 
register_value = register_value | 0xFFFFFFFF; // set OEN_3, bit 0 [ENABLE]
Xil_Out32(0xE000A288, register_value); // write OEN_3

register_value = Xil_In32(0xE000A048); //read DATA_3
register_value = register_value | 0xFFFFFFFF; //set DATA_3, bit 0 [HIGH]
Xil_Out32(0xE000A048, register_value); //write DATA_3


//----------------------------------------------------------------------------

// SEM IP should properly initialize and transmit
// characters to UART1. The following infinite loop
// forms a software bridge between UART1 and UART0,
// for interaction with SEM IP over the COM port.

for ( ; ; ) {
if (XUartPs_IsReceiveData(((&xuartps0)->Config.BaseAddress))) {
XUartPs_SendByte(((&xuartps1)->Config.BaseAddress),XUartPs_RecvByte(((&xuartps0)->Config.BaseAddress)));
}
if (XUartPs_IsReceiveData(((&xuartps1)->Config.BaseAddress))) {
XUartPs_SendByte(((&xuartps0)->Config.BaseAddress),XUartPs_RecvByte(((&xuartps1)->Config.BaseAddress)));
}
}

cleanup_platform();
return 0;

}

 

 


I also mapped some status signal to the leds of the board and added ILA to monitor SEM signals through JTAG.

When I program the FPGA the controller goes to idle state, then when I launch the SDK code on hardware it goes to initialization state, asserts icap_grant and it goes to observation state and status heartbeat is alive.

However, i'm not still able to see the initialization status on the terminal and I can't interact with the controller.
UART0 and UART1 are set to 9600,

SEM has a 100MHz clock,

V_ENABLETIME = 650.

I tried to disconnect monitor_tx and monitor_rx from UART1 and  connect it to a pair of free header pin of my board, which are connected to PC trough a UART-to-USB adapter, and after the execution of the code I can read this characters:

Does anyone know what the problem could be?

Thanks

 

sem.PNG
0 Kudos