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

IWR1443BOOST: MMWave demo crashes with higher fps

Vera
Prodigy 140 points
Part Number: IWR1443BOOST
Other Parts Discussed in Thread: IWR1443

Hello,

I am trying to set the fps higher then 10 fps as this is standard selected in the visualizer. But when I select 20 fps and send it to the IWR1443 I get this error in the visualizer: mmwDemo:/>Exception: ../main.c, line 1726. When I put the fps a bit lower like 17 fps I don't get the error anymore but the program does crash frequently now and doesn't give any output anymore. At 10 fps the program runs smoothly and I haven't experienced it crashing but the 10 fps is sometimes a bit to slow for the application that we are using it in. 

I have included the config file that I used. I only selected the scatter plot as output, I read in the visualizer user guide that when selected multiple scene parameters the visualizer can get a bit slow. I also made sure that I downloaded the latest project version from the resource explorer en uploaded it to my IWR1443.

Is this an known issue with the module? I haven't found a related forum post with an answer to it. Is there a way to get the data faster out?

profile (2).cfg

  • Former Member
    0 Former Member
    Hello Vera,

    This issue has been previous reported for the case where other plots are enabled. In that case, the crash is due to the UART time required to transfer the data being greater than the selected frame rate enables. e2e.ti.com/.../2325812

    Could you provide some more information about the slow data/crashes: have you only experienced it with just this chirp configuration?

    Thanks,
    Amanda
  • 0 in reply to Former Member
    Prodigy 140 points
    Hello Amanda,

    Thanks for your reply.
    I came across that forum post but it didn't have a answer for the problem. I tried to send less data over the UART but when I put the fps up to twenty in the visualizer it still crashes.
    I tried it with other configuration but when I put it above 17 or 18 fps it crashes right away and when I put it around 17 fps it works for a while and then still crashes. I also had the range profile on at some times but still crashes.
    Are there some steps that I could try to get you more data that you can work with?

    Thanks,
    Vera
  • 0 in reply to Vera
    Prodigy 140 points
    Hello,

    I am looking forward to here more on this topic.

    Thank you,
    Vera
  • Former Member
    0 Former Member in reply to Vera

    Hello Vera,

    I appreciate the details you provided and steps taken. I wanted to give you a status update so far:

    Using the chirp you attached I replicated the same issue described. (issue continued to manifest with some other chirps on both SDK1.1 or 1.2) 

    Specifically, the crashing appears to be caused by the time required for the processing chain of the OOB Demo being greater than the available idle time of the chirp.

    I've attached the data path timing diagram for reference. From the figure we can see that the processing and data out via UART must finish before the next frame or an error will be thrown. At a high level we can expect that at some point if we continue to increase the FPS there will be insufficient idle time for the processing which will not scale down. The OOB demo enables chirp configurations that are valid from a radar front end configuration point of view. However, it doesn't check whether there's sufficient processing time. In this respect, this is a known issue and expected behavior.    

    One of the things that can be done is to enable the Statistics options. Then in the Plots view select Profiling from the drop down so you can see some of the timing information as you make parameter changes. 

    Using this strategy I looked at your chirp and have attached a configuration that appears to be stable up to the 30fps with similar scene requirements. I've attached it here for your reference. Here it has static clutter removal disabled to reduce post processing time. However, depending on your application, the number of detected objects you are observing may be much greater than my test scene. This would increase the UART time and could cause the timing deadline to be missed. Other parameters would need to be adjusted to then meet the timing requirements.

    Please let me know if this help you or if there are any follow up questions.profile_30fps.cfg

    Best,

    Amanda

  • 0 in reply to Former Member
    Prodigy 140 points
    Hello Amanda,

    Thanks for your answer. This helped a lot!
    I tried it out and it seems to be stable I will do some more testing with my application and if I got more issues I will open up another thread.

    I do have an other question about the timing that you wrote about. Could you clarify some of the timing parameters I see there:
    - the interframeprocessingmargin, is this the maximum time a frame can be?
    - interframeprocessingtime: is this the time it took to process a frame?
    - transmitoutputtime: this is probably the time it took to send out the data?
    It looks like the transmitoutputtime is somethimes more than the frameprocessingtime, is this because it needs to send so much data over? So to get that lowered I can just adjust the uart data in the program to not send the stuff I don't need.

    Thanks again for your help!
    Vera
  • 0 in reply to Vera
    TI__Expert 5235 points
    The quantities you are referring are mentioned in the doxygen documentation of the demo in section called "Stats Information" along with a picture. The picture Amanda quoted is in the doxygen towards the top of the document and is titled "Top Level Data Path Timing". The top level is not trying to show the detail and generally calls all of the processing involved including sending as inter frame processing and also does not show any margin left for processing. We will clean up the documentation in a future release so that there is no confusion between the top level and the stats one.

    Regarding the transmit time on UART being higher than processing time, this is not surprising depending on your configuration and visualizer settings, you can see this is mentioned in the "Limitations" section in the doxygen documentation quoted below:
    ------------
    ...
    Limitations
    Because of UART speed limit (< 1 Mbps), the frame time is more restrictive. For example, for the azimuth and Doppler heat maps for 256 FFT range and 16 point FFT Doppler, it takes about 200 ms to transmit.
    ...
    --------

    Thanks.
  • 0 in reply to Piyush_
    TI__Expert 5235 points
    Just to correct a bit because I was referring to 1642 doxygen but I realize your post is about 1443, everything I said applies to 1443 documentation also, just that the section that I referred to as "Stats Information" in earlier post is called "Output information sent to host" instead in the 1443 demo doxygen.