• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 1381 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.

IWR1642BOOST: Wrong Checksum or Data Loss while Sending through UART

LAXMI KANT TIWARI
Genius 3345 points
Part Number: IWR1642BOOST

Hi,

I am working on people count demo with SDK 2.0.0.4 and IT 2.4.0. I am receiving the data on MATLAB and found out that sometimes header checksum does not produce to zero. It is causing a crash to my application. I had printed the header values which look like this

header = [2 1 4 3 6 5 8 7 4 0 0 2 66 22 10 0 172 48 53 47 10 5 0 0 66 93 1 0 0 0 0 0 78 0 0 0 27 74 0 0 164 1 0 0 182 52 0 0 3 0 163 148]

The header seems right to me but somehow app is breaking after 4-5 seconds if it found checksum not equal to zero. I am checking checksum with below code

h = typecast(uint8(header),'uint16');
a = uint32(sum(h));
b = uint16(sum(typecast(a,'uint16')));
CS = uint16(bitcmp(b));

For the above header, it is producing 3 checksum. Although, header seems right to me. I had also printed decoded values of the header which are as follows

sync headers are: 258, 772, 1286, 1800
version: 33554436
platform 661058
timestamp 792015020
packetLength 1290
frameNumber 89410
subframeNumber 0
chirpMargin 78
frameMargin 18971
uartSentTime 420
trackProcessTime 13494
numTLVs 3
checksum 38051

Moreover, It seems somehow data is being lost while receiving through uart. UART baud rate is 921600. Need a piece of expert advice on it. 

  • 0
    Genius 3345 points

    Update:

    I have found most of the time checksum is producing either 3 or 768. One more odd behavior I have just discovered that wrong header had produced zero checksum. Following 52 bytes of data produced zero checksum.

    header = [0 187 219 189 110 232 123 190 85 116 110 65 116 81 17 189 90 187 219 189 128 81 17 189 1 146 72 63 223 34 155 64 18 0 0 0 144 31 199 190 246 65 2 63 0
 0 0 0 0 0 0 0 0];

    I was using a sliding window of size 52 bytes with 1-byte slide to the find out the start of a valid byte stream as UART is asynchronous. But, it seems my method is not 100% foolproof. So now, I have two problem

    1. Why wrong CRC is being produced?
    2. How can I check the start of the valid byte stream? i.e. UART should start processing the once it gets the valid 52 bytes header.

  • 0 in reply to LAXMI KANT TIWARI
    TI__Mastermind 28055 points

    Hi Laxmi,

    You can see the checksum creation process in task_mbox.c at line 267 or in the main_pplcount_viz.m at line 1164.

    The steps are as follows:

    1. Typecast from uint8 to uint16. If you have two uint8 values a and b in an array [a b], then the uint16 version is going to be ba. (Little endian in the device, this is also how matlab handles a typecast).
    2. Sum all of the new uint16 values and store in a uint32 to avoid overflow.
    3. Split the uint32 sum into 2 uint16 and sum these.
    4. Take the bitwise compliment of the sum obtained from the previous step.

    Since your example code shown is the excerpt from matlab, I do not think your technique is a problem, you seem to be following the steps above.

    From the header data you showed, it seems that you are not finding the magic number.  The header will always start with an 8 byte magic number, which will look like this in matlab [2 1 4 3 6 5 8 7].  To find the beginning of the header, you need to scan across the UART data to find this magic word.  Then, include the magic word as part of the header, and compute the checksum. 

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Genius 3345 points

    Hi Justin,

    Yes, I am doing checksum exactly same as TI had suggested. It is the same code. I think I have understood the answer for my question point 2 but point 1 is still unanswered.

    1. As you can see frame header contains magic number and header seems right even after that checksum is not equal to zero. I think data loss is being occurred and somehow UART is not able to transmit and receive this much of data. Do you have any suggestions to decrease 20 samples to somewhere 2 to 4 samples per second? 

    Moreover, I am looking for a piece of advice to modify call frequency of this line in tast_mbox.c

            Semaphore_pend(gMmwMssMCB.mboxSemHandle, BIOS_WAIT_FOREVER);

    Sometimes, I get the header in sync but after sometime, it is losing sync. Once code loses sync, it again goes for sync looking mode. Can you please look into it.

     

  • 0 in reply to LAXMI KANT TIWARI
    TI__Mastermind 28055 points

    Hi Laxmi,

    Please do the following - lower the frame rate of the device by increasing the frame periodicity:

    frameCfg 0 1 128 0 200 1 0

    trackingCfg 1 2 250 20 200 200 90

    This sets each frame to 200 ms, so you will be at 5 fps.  Run the demo with these settings to determine if a lower frame rate will solve the issue with data becoming corrupt. If this fixes the issue, you can check the frame number before sending TLVs. You could decide to only send on every 4th or 5th frame to reduce the load on UART.  If this were the case, I would still recommend sending a frame header each frame if you use the default gui, because it expects to see the frames sequentially.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Genius 3345 points
    Thanks justin. I will check and update to you. Thanks.
  • 0 in reply to LAXMI KANT TIWARI
    Genius 3345 points
    Hi Justin,
    Do I need to change cfarCfg too?
  • 0 in reply to LAXMI KANT TIWARI
    TI__Mastermind 28055 points
    Hi Laxmi,

    It is coincidence that the cfarCfg also contains a 50. You do not need to change it.

    Regards,
    Justin
  • 0 in reply to Justin Curewitz
    Genius 3345 points

    Thanks Justin. Will update you.

  • 0 in reply to LAXMI KANT TIWARI
    TI__Mastermind 28055 points
    Hi Laxmi,

    Do you still need support on this issue?

    Regards,
    Justin
  • 0 in reply to Justin Curewitz
    Genius 3345 points

    Hi Justin,

    I have found that I am having issue at my receiving end. Thanks for your help.