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.

IWR6843AOPEVM: Trying to find magic word of UART data stream from simple C application

Part Number: IWR6843AOPEVM
Other Parts Discussed in Thread: UNIFLASH

Hi all,

I flashed the 68xx_mmwave_sdk_hcc demo from the mmwave industrial toolbox (ver 4.7) on my IWR6843AOPEVM board and I am trying to read from the data port using a simple C program, but so far failing to find the magic word of the message header. I believe I'm using wrong UART settings on my Linux machine (Ubuntu 20.04), but can't seem to find the exact UART settings one needs to successfully read from the data port of the IWR6843AOPEVM.

Here is my C Code to initialize the UART connection to the IWR6843AOPEVM:

#define IWR6843AOPEVM_DEF_BAUD B921600
int uart_init(int fd)
{
int rv = 0;

speed_t baudrate = IWR6843AOPEVM_DEF_BAUD;
struct termios2 settings;

if (ioctl(fd, TCGETS2, &settings))
{
printf("Error loading UART settings from device\n");
rv = 1;
goto err;
}

settings.c_cflag &= (unsigned int)~PARENB; // no parity bit
settings.c_cflag &= (unsigned int)~CSTOPB; // one stop bit
settings.c_cflag &= (unsigned int)~CSIZE; // character size mask
settings.c_cflag |= CS8; // data word = 8 bits
settings.c_cflag |= CLOCAL; // ignore modem control lines
settings.c_cflag &= ~CRTSCTS; // disable hardware flow control
settings.c_lflag &= ~ICANON; // non-canonical mode
settings.c_lflag &= ~ISIG; // ignore signals INTR, QUIT, SUSP, DSUSP
settings.c_lflag &= ~ECHO; // echo off

settings.c_iflag &= (unsigned int)~(ICRNL | IXON | IXOFF); // cr not interpreted, no software flow control

settings.c_oflag &= ~OPOST; // raw output
settings.c_oflag &= ~ONLCR; // map cr to cr-nl

settings.c_ispeed = baudrate;
settings.c_ospeed = baudrate;

if (ioctl(fd, TCSETS2, &settings))
{
printf("Error storing UART settings to device\n");
rv = 1;
goto err;
}

err:
return rv;
}

Any suggestions on what I might be doing wrong or missing?

  • Hello

    Have you tried to

    1)  pipe the content to a file and check for the magic word

    2) Tried to see  result of parsing on  windows machine.

    Thank you

    Vaibhav

  • Hi Vaibhav,

    thanks for the quick reply.

    1) [cat /dev/ttyUSB1 > uart_test.txt] followed by [hexdump -C uart_test.txt | grep "01"] results in the following:

    Still no sign of the magic word. /dev/ttyUSB1 is definitely the data port, since I already successfully tested the out of the box cloud visualizer demo. Same goes for reading the data port with the above mentioned C program, dumping the buffer to a file and then looking for the magic word, haven't found it either that way.

    2) Unfortunately, Windows is not an option since I have no Windows machine at the moment. What would be different for/on a Windows machine?

    Is there any documentation on the IWR6843AOPEVM as to what the exact UART settings for the data port are?

  • Lars:

    You have stated that you have successfully ran the OOB demo and utilized the demo visualizer. Can you run the OOB demo, not the HCC, and have the output fed into your C program and see if you can find the magic word. Based on this result we will be able to determine if the HCC is the problem, or if your C-code is not capturing the data properly.

    Best regards,

    Connor Desmond

  • That's a great idea, however, how am I supposed to start the OOB demo without the visualizer? To be more precise, I'm running the web based cloud demo visualizer (because I am on Linux and the GUI program is for Windows only).

    The documentation explicitly states that one must use the visualizer to start the OOB demo properly, since the demo code of the IWR6843AOPEVM waits on the CLI part to get a config and start the sensor.

    Or is there a way to start the sensor using the demo visualizer and then terminate it to free up the serial port and start my C program? Because I've tried that already and the demo (the original OOB demo) freezes at a random point (i.e. the serial port stops receiving new data).

    I'm not trying to be sarcastic here, just genuinely want to get to the bottom of this problem :)

    Thanks for the quick replies!

  • Lars:

    Understood. You do not have to use the visualizer. The visualizer does two things: 1. It configures the device via .cfg file. The visualizer sends one automatically based on visualizer configurations, but you can send your own .cfg files as well. To do this without the visualizer just use a utility similar to Teraterm or PuTTY to send the .cfg file to the device. 2. It visualizes the data. For your purposes you just want to capture the data that is sent to the PC from the device. We provide .cfg files located here:

    Out of Box Demo Profiles:
    <MMWAVE_SDK_INSTALL_PATH>\packages\ti\demo\xwr68xx\mmw\profiles

    Let me know if you can get the OOB demo configured using a serial terminal.

    Best regards,

    Connor Desmond

  • Hi Connor,

    thanks for the quick reply.

    I now did the following:

    1. Put the IWR6843AOPEVM device in flash mode.

    2. Flashed the image "mmwave_sdk_03_05_00_04/packages/ti/demo/xwr68xx/mmw/xwr68xx_mmw_demo.bin" onto the device using uniflash (The GUI version under "uniflash_6.3.0/node-webkit/nw", which outputs successful flashing on its console).

    3. Put the IWR6843AOPEVM device back in operational mode and pushed the reset button.

    4. Using the linux terminal program "screen" like [screen /dev/ttyUSB0 115200] I send the config commands of the file "mmwave_sdk_03_05_00_04/packages/ti/demo/xwr68xx/mmw/profiles/profile_2d.cfg" like this:

    Since I'm getting an answer from the device, I assume this is correctly working. The last command "sensorStarts" starts the sensor.

    5a. Using another screen session like [screen /dev/ttyUSB1 921600] I listen to the data port, and the answer looks like this:

    5b. Using my C program, I read in 2^16 Bytes into a buffer from /dev/ttyUSB1 and look for the magic word, which I can not find.

    5c. Using stty like [stty -F /dev/ttyUSB1 speed 921600 cs8 -cstopb -parenb] I configure another terminal to treat the serial device /dev/ttyUSB1 as an 8N1 UART device with baudrate of 921600. I then dump the contents into a file with [cat /dev/ttyUSB1 > uart.txt]. with [hexdump -C uart.txt | grep "01"] I look for the magic word, which I can not find.

    I am puzzled by the fact that the config port works like a charm, but the output of the data port seems nonsensical. What am I missing here?

  • Lars:

    I am glad you were able to configure the device. The terminal only displays ASCII data, so when there is data streaming from the device it is expected to have a variety of fast streaming symbols in your serial terminal. The fact that you can see this means that the radar device has not crashed and is working. I believe that the problem here possible what you are using to package the data that you then subsequently search for the magic word. Honestly to simply the problem I would suggest getting CCS on your linux machine and modify the source code, so that only the magic word is sent out. Then if anything is sent out it has to be the magic word. See how this value compares to what it should be. Let me know how it goes.

    Best regards,

    Connor Desmond

  • Hey Connor,

    I changed the source code to only send out the message header. With a screen terminal like [screen /dev/ttyUSB1 921600] I get stuff like this:

    `�X�Ch
    B�G��X�Ch
    C*t¯X�Ch
    Dȇ�X�Ch
    E,�$�
         X�Ch
    F8�U�
         X�Ch
    G"���
         XCh
    H
    XCh
    I#��Ch�
    J����X�Ch
    K��K�X�Ch
    L��|�X�Ch
    Mj)��X�Ch
    N"�߼X�Ch
    O���X�Ch
    Pt�A�X�Ch
    Q$+s�X�Ch
    R�
    ��X��^C

    however the sequence:

    stty -F /dev/ttyUSB1 921600

    cat /dev/ttyUSB1 > uart_test.txt

    hexdump -C uart_test.txt | grep "02 01 04 03 06 05 08 07"

    reveals:

    00000000  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000040  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000080  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    000000c0  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000100  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000140  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000180  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    000001c0  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000200  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000240  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000280  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    000002c0  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000300  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000340  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000380  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    000003c0  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|
    00000400  02 01 04 03 06 05 08 07  04 00 05 03 00 00 00 00  |................|

    There it is. So I basically changed the sending data out routine to just send the message header and align to multiple of 32 bytes.

    Now I am confused by the fact that I didn't change the way I look at the data with my Linux machine, but rather told the mmWave demo to only send its message header and now the magic word appears.

    So if I look at this correctly, some of the other data sending routines of the OOB demo are the culprit?

    Anyhow, it's a step forward :)

  • Edit: My C program is also able to find the magic word with the modified OOB demo

  • Update:

    I seem  to have found the culprit behind the missing magic word. In the HCC as well as OOB demo inside the function [MmwDemo_measurementResultOutput] of [mss_main.c], the last operation is sending padding bytes, like this:

    numPaddingBytes = MMWDEMO_OUTPUT_MSG_SEGMENT_LEN - (packetLen & (MMWDEMO_OUTPUT_MSG_SEGMENT_LEN-1));
    if (numPaddingBytes<MMWDEMO_OUTPUT_MSG_SEGMENT_LEN)
    {
    UART_writePolling (uartHandle,
    (uint8_t*)padding,
    numPaddingBytes);
    }

    If I deactivate this part of the code and just send the message header as it is (40 bytes), everything inside the header is correctly transferred to my host PC. However, if this part of the code is active, it

    1. sends random bytes (because the variable padding is not correctly initialized with = {0} at the start of the function)

    2. it doesn't send 24 bytes (64 - 40, if you just send the header) and more important, it starts to "swallow" bytes from the magic word, so the start sequence of the packet becomes unusable.

    Any idea what this may be caused by?

    Ah, and for anyone trying to use the sensor like me, the correct linux terminal settings for receiving on the data port are:

    speed 921600 baud; line = 0;
    min = 1; time = 0;
    -brkint -icrnl -imaxbel
    -opost -onlcr
    -isig -icanon -echo

    which one can set using stty.

  • Update:

    So to wrap things up, the last error was on my side. Apparently the "min" and "time" setting of stty are important as well. With the following stty settings:

    speed 921600 baud; line = 0;
    min = 100; time = 2;
    -brkint -icrnl -imaxbel
    -opost -onlcr
    -isig -icanon -echo

    I am now able to read and parse the full message coming from the data port correctly.

    Thanks to Vaibhav and Connor for the help along the way, Cheers!