gibberish data in loopback of lib uart 3.0.2 rc2

[sprajagopal]

I tried the following test code with libuart 3.0.2 rc2 (only the main parallel assignment is shown, as the functions are all library functions):

Code: Select all

par
	{

		on tile[0]:
		{
		    par {
  	
          input_gpio_1bit_with_events(i_gpio_rx[0], rx_fw);
          uart_rx(uif[0], null, 16, 115200, UART_PARITY_NONE, 8, 1, i_gpio_rx[0]);
          uart_tx_buffered(utif[0], null, 50, 115200, UART_PARITY_NONE, 8, 1, i_gpio_tx_world[0]);
          output_gpio(i_gpio_tx_world, 1, tx_ack, null);
        
        }

		on tile[1]:
		{
			par{

        {
          while(1){
            unsigned char ch = uif[0].wait_for_data_and_read();
            utif[0].write(ch);
          }
        }
     }
   }
}
     

When I send something on the rx_fw pin, I expect the same reply on tx_ack. I am testing with a ttl-usb converter and a serial terminal.
I find that when the hex string is short (<3 bytes), the reply is identical. Anything longer and the reply gets garbled after 3 bytes.
Any clues?

[mon2]

Believe the issue is with the clock used for the UART module. What is the value ?

Fairly sure that you are required to feed an external clock source of 1.8432 Mhz (common to the PC UARTs) into a single bit pin of the XMOS device which will serve as the UART clock.

See here for more details:

https://www.xmos.com/published/xa-sk-ua ... ware-guide

Otherwise, you will have to settle on the baud rates which are derivatives of the applied clock source and this computed baud rate may not be compatible with the PC baud rates (ie. as supplied by your USB to UART dongle = 9600 bps, 19200 bps, etc.).

In short, the gibberish is due to mismatched clocks on your XMOS controller vs. the external USB to UART dongle. With an external clock of 1.8432 Mhz on the XMOS, you should be fine to frame the traffic with the external dongle and/or standard PC serial ports. However, be sure to watch the voltage levels on each such external port. That is, if using a true USB to UART dongle - you may be dealing with 3V3 swings or if RS232 then possibly +12 to -12V (although most are +6 to -6V). If dealing with RS232, you MUST use a similar transceiver on the XMOS controller - or consider the above referenced UART slice (which features RS232 transceivers onboard).

BTW: The XMOS UART slice features an onboard 1.8432 Mhz clock source.

http://www.digikey.com/product-search/e ... RT-8&v=880

[sprajagopal]

Believe the issue is with the clock used for the UART module. What is the value ?

Fairly sure that you are required to feed an external clock source of 1.8432 Mhz (common to the PC UARTs) into a single bit pin of the XMOS device which will serve as the UART clock.

See here for more details:

https://www.xmos.com/published/xa-sk-ua ... ware-guide

Otherwise, you will have to settle on the baud rates which are derivatives of the applied clock source and this computed baud rate may not be compatible with the PC baud rates (ie. as supplied by your USB to UART dongle = 9600 bps, 19200 bps, etc.).

In short, the gibberish is due to mismatched clocks on your XMOS controller vs. the external USB to UART dongle. With an external clock of 1.8432 Mhz on the XMOS, you should be fine to frame the traffic with the external dongle and/or standard PC serial ports. However, be sure to watch the voltage levels on each such external port. That is, if using a true USB to UART dongle - you may be dealing with 3V3 swings or if RS232 then possibly +12 to -12V (although most are +6 to -6V). If dealing with RS232, you MUST use a similar transceiver on the XMOS controller - or consider the above referenced UART slice (which features RS232 transceivers onboard).

BTW: The XMOS UART slice features an onboard 1.8432 Mhz clock source.

http://www.digikey.com/product-search/e ... RT-8&v=880

Hi,
(1) the external clock source is only for muart.
(2) I have used the older channel-architecture based sc_uart library with this same stup and it works fine.

I found the following things in the code:
(a) since the library uses combinable functions, it doesn't use ordering for its select cases. For a test, I removed the combinable keyword and introduced ordering to the select cases. The result: for 100 byte hex strings, 1-2 bytes are garbled in the middle but that's all. Earlier, only the first few bytes were properly read.

I think this has something to do with the code structuring rather than the external setup.