• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 29 subscribers
  • Views 1069 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.

AWR1642BOOST: MMWave_execute() assertion when stopping, flushing, re-configuring, and starting the sensor many times

Erik Larsen
Expert 1095 points
Part Number: AWR1642BOOST

Hello;

I'm bringing up an issue I've brought up before on this forum, which has been previously locked:

https://e2e.ti.com/support/sensor/mmwave_sensors/f/1023/t/652626

After migrating to SDK v1.2, this issue seems to happen more frequently when Stopping the sensor, flushing and updating the config, then starting the sensor. Doing this process many times, usually within a minute will cause an assertion with the MMWave_execute() task. I cannot figure out why this is happening, and why it's happening more frequently with the new SDK v1.2. It has stumped me for a while now.

Any advice for debugging, or why this might be happening would be great. Here's the exact debug session of the issue:

Thanks,

Erik

  • 0
    TI__Guru*** 149044 points

    Hi

    I have heard reports in the past that CLI interface through UART was not very robust.

    I think that the behavior is caused by the UART communication.

    I am not sure the mmWave SDK demo was designed to support this use case.

    Will discuss with the mmWave SDK team if they plan to support such use case in the future

    Thank you

    Cesar

  • 0 in reply to Cesar
    Expert 1095 points

    Thanks Cesar,

    This is good to know. I will work on moving that functionality out of the CLI and see what happens. 

    Do you have suggestions where stopping, re-configuring, and starting the sensor can reliably take place? What is wrong with the CLI Task that's causing issues? I don't want to move these functions to a different task and simply recreate the issue.

    Regards,

    Erik

  • 0 in reply to Erik Larsen
    TI__Guru*** 149044 points
    Ideally, this should be done in the code running on the target.

    Let me check if our testing team has a similar test case.

    thank you
    Cesar
  • 0 in reply to Cesar
    TI__Guru*** 149044 points
    Hi,

    I am still waiting on a response from our testing team.

    Were you able to perform any new tests?

    Thank you
    Cesar
  • 0 in reply to Cesar
    TI__Guru*** 149044 points
    Hi,

    I just got the response from the test team.

    Currently we are not performing similar testing.

    We will plan to add this use case to our test plan.

    I would like to close this thread

    If you have additional test results, could you please start a new thread?

    thank you
    Cesar
  • 0 in reply to Cesar
    Expert 1095 points
    Cesar,

    I've moved the stopping, re configuring, and starting to a new task. I'm still evaluating the reliability, but it seems stable so far.

    However, I can't explain why, as it's a Task with identical priority/initialization as the CLI Task.

    I'll open a new thread if problems come up. Thank you for the advice.

    Regards,
    Erik