• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 532 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.

Original question:

IWR6843ISK-ODS: IWR6843 ODS ES 2.0 sensor sending bad packets often

IWR6843ISK-ODS: Sensor not sending complete packet

radha
Intellectual 905 points
Part Number: IWR6843ISK-ODS

Hi all,

I'm working on 3D demo from ITB 4.2.

I'm trying to parse the raw data from the sensor and I see that sometimes I don't receive all the TLV types. The header information is correct. The numtlv in header sends value 3 but while parsing I don't all three types. Sometimes after tlv type 6 i see the next header packet. Is this because of the baudrate? 

I have lowered the baud rate to 921600 and my frame rate is 70ms.

Thanks,

radha.

  • 0
    TI__Mastermind 28055 points

    Hi Radha,

    We had found a bug in the 3D people counting demo that caused the numTLVs to not match the number of sent TLVs. This has been resolved, and will be included in the upcoming TIREX release - next week.

    If you are curious about the bug, I can comment here.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 905 points

    Hi Justin,

    Thanks for the information. I'm waiting for the new release with all these fixes. Hope it will be available soon.

    And yes I'm interested to know about the bug. 

    Thanks,

    radha.

  • 0 in reply to radha
    TI__Mastermind 28055 points

    Hi Radha,

    So there was an issue with synchronization between the tracker and the output function.  There is a short task sleep between the uart sends - during this time, the tracker could run. The following events caused a UART crash:

    1. Output function begins, and there is no detected tracks (so we don't have a TLV for the targets or target indexes)
    2. Between uart_writes, the tracker runs
      1. A track is allocated
      2. Global numTargets variable (in gMmwMssMCB) is set to non-zero value
    3. When we get to the target TLV send, we check the numTargets variable - if it is non-zero, we send the TLV
    4. There is tlv data, and the pointer isn't properly initialized. 
    5. Uart_write can't work with the uninitialized pointer, causing the UART peripheral to crash

    This has been fixed by changing the if statement check to check that the size of the target TLV (and target index TLV) is non-zero.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 905 points

    Thanks Justin. That really helps to understand the situation. Waiting for the upcoming release.

    radha.