• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1330 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: UART receive issue

VICTOR VALENCIA
Expert 1070 points
Part Number: CC1310


Hi Everyone,

 I am trying to send variable length serial packets from Linux to the 1310 at 115200 baud.  To start with I am using the uartecho.c example application.  

From Linux (beaglebone black) I am sending 4 characters ("test").  I am expecting that, while running the uartecho application, the same 4 characters

will get echoed back to linux.  I have linux TX connected to 1310 RX and vice versa.  I have Putty running on my PC using FTDI with only the RX and GND connected

to the 1310 DIO3 (RXD) and GND respectively so I can see what is being received by the 1310.

The linux application just sends out the 4 characters "test" one time.

What I am seeing is that the 1310 sees the same 4 characters on input ("test") over and over and keeps echoing them out.  The uartecho.c example is configured to read

one character at a time.  It's acting as if the 1310 uart input buffer is never cleared but when I use the UART_control() function to read the number of chars remaining 

in the input buffer after calling UART_read() it always says 0.

The code for reading the input buffer size is: UART_control(uart, UART_CMD_GETRXCOUNT, &count);

On the Putty screen I see:

testtesttesttesttesttest...

etc.

The linux side only calls write(fd, "test", 4) once.

Now things get really strange :)

If for every 1310 input byte I added 2 to it's value and echoed that back to linux instead.  On the linux side I see:

successfully opened /dev/ttyO4
ping() sent 4 bytes

ping() received 4 bytes
sent: 0x74 (t) got: 0x76 (v)
sent: 0x65 (e) got: 0x67 (g)
sent: 0x73 (s) got: 0x75 (u)
sent: 0x74 (t) got: 0x76 (v)


This led me to believe that the "add 2" operation changed the timing but adding a 10 msec delay between each

1310 RX and TX instead of "add 2" made it fail again.

Any ideas?

Victor

  • 0
    TI__Mastermind 23730 points
    Hi Victor,

    Have you modified the uartecho example?
  • 0 in reply to Severin Suveren
    Expert 1070 points
    Hi Edvard,

    Thanks for responding. It is a pretty strange issue. I had not made any changes to the uartecho example. I did discover though that the tty
    port config on the linux side was wrong. Echo was enabled so there was an infinite receive/echo loop between the 2 devices. It appears to be working much better now although I am still seeing unreliable communication between the 2 devices.

    I am running at 115200 baud and sending 48 byte packets from Linux to the 1310. For some reason the 1310 seems to be receiving extra
    bytes causing all the packets to get shifted. It mostly looks like 0's are being added. The first packet always works but after
    that I see many different packet sizes being received by the 1310. The Linux side is sending a 48-byte packet once per
    second.

    Here is the output from RF studio showing the Linux packets as they are retransmitted from the 1310. I verified that the 1310 is
    sending exactly what it receives from Linux. The first packet shows what they should all look like. It has a counting pattern in
    the payload.

    11:35:29.604 | 2e | 01 00 01 00 83 00 78 56 34 12 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 00 00 | -41

    11:35:30.600 | 2e | 01 00 01 00 00 00 00 00 00 00 02 00 00 00 26 00 00 00 ff ff 83 00 78 56 34 12 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 | -41

    11:35:31.600 | 2e | 01 00 01 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 26 00 00 00 ff ff 83 00 78 56 34 12 00 01 02 03 | -41

    11:35:32.601 | 2e | 01 00 01 00 0e 00 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 | -41

    11:35:32.601 | 2e | 01 00 01 00 34 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 00 00 00 00 00 00 | -41

    11:35:33.599 | 2e | 01 00 01 00 00 00 02 00 00 00 26 00 00 00 ff ff 83 00 78 56 34 12 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 | -41

    11:35:34.600 | 2e | 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 26 00 00 00 ff ff 83 00 78 56 34 12 00 01 02 03 04 05 06 07 | -42

    11:35:35.599 | 2e | 01 00 01 00 12 00 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 26 00 00 00 | -41
  • 0 in reply to VICTOR VALENCIA
    TI__Guru 58425 points
    Hi Victor,

    It would help if you could highlight the parts of interest in the payload in question.

    Regarding the "UART_CMD_GETRXCOUNT" command from the first post, this is something that is not supported by the default UART driver that is included together with the uartecho example and thus would not yield any sensible result. There is two different drivers, UARTCC26XX and UARTCC26X0 where the first is the default one.

    Regarding the other issue when sending a lot of data, does it help to lower the baudrate? The uartecho example is not designed to echo longer sequences but manual user input (that has natural delay between transmissions) 1 byte at a time. As there is quite some overhead related to UART_write, there could be timing issues with a lot of data being received while writing it back 1 byte at a time.

    You could also try to increase the UART ringbuffer inside the board file (CC1310_LAUNCHXL.c) to be larger then 32 bytes and see if this makes a difference.

    Can you also provide what SDK version you are using?
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1070 points
    Hi M-W,

    Sorry for the late reply. I thought that everything was working but I am still running into issues. The issue is somewhat different though so I will ask a "related question" instead.