• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 1173 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: Suggestions for recovering from DEADLINE MISSES at runtime

Erik Larsen
Expert 1095 points
Part Number: AWR1642BOOST


Hello;

Do you have any suggestions for the steps needed to recover from MMWDEMO_DSS_CHIRP_PROC_DEADLINE_MISS_EVT & MMWDEMO_DSS_FRAME_PROC_DEADLINE_MISS_EVT

I've tried various combinations of

  • Removing any related Debug Asserts
  • Stopping, re-configuring, then starting the sensor
  • MMWave_deinit, MMWave_init, and MMWave_sync

But, I will get various types of Stop errors, Config errors and other Debug Asserts in mmwave_xwr16xx.c

Is there anything I can do to recover at runtime besides warm resetting?

Thanks,

Erik

  • 0
    TI__Guru**** 150344 points
    Hi

    You need to understand why these miss events happen.

    You need to benchmark your code in order to make sure that your inter frame processing time does not extend beyond the frame idle time

    Thank you
    Cesar
  • 0 in reply to Cesar
    Expert 1095 points

    Hi Cesar,

    Thanks for the response.

    I do understand the cause of such errors.

    Ideally, our product in the field would be able to detect, record, and gracefully recover (if possible) from all known failure cases even if they should theoretically never happen.

    Are there any ways to recover from this error at runtime besides a warm reset?

    Thanks,

    Erik

  • 0 in reply to Erik Larsen
    TI__Guru**** 150344 points
    Thank you Erik,

    If I understand correctly your question refers more to the hw recovery when an exception occurs than the software management of the exception?

    In the mmWave SDK demo, the software tracks the processing deadlines with global flags and based on the values may decide to perform a local assert in the ISR.

    A different application may decide to handle the processing deadlines differently

    Thank you
    Cesar
  • 0 in reply to Erik Larsen
    TI__Mastermind 21025 points
    Hi Erik,

    The difficulty here is that the BSS has no knowledge that the MSS or DSS has missed a deadline, and so even if you don't halt the processor with an assert, other things get out of sync (such as mailbox traffic to BSS) and are not easily recovered. The best defense is a strong offense - having profiled and bulletproofed your chirp and frame code such that they cannot miss realtime. It may be necessary (if your processing can run in variable amounts of time) to profile loops and abort if they are going to do too many iterations. If this is the case, it may be helpful to sort the radar returns by strength so that you are always processing the top N detections. But I'm talking in generalities because I don't know what your application is.
  • 0 in reply to db_woodall
    Expert 1095 points
    db_woodall,

    As you already predicted, I was not able to reliably resolve the mailbox traffic issues.

    I appreciate the response, this answers my question.


    Cesar,

    You're right, this would be a HW recovery situation.

    Thanks,
    Erik