AWR1642BOOST: Chirp Interrupt time changes at random

Hi,

Please note that there is a much newer version of the SDK. The version you are using is one year old and will no longer be supported.

In order to debug the issue you see, please check the out of the box demo. Do you see the same behavior?

We need to determine if the behavior you see is specific to the configuration you are using

Thank you
Cesar

Hi Cesar,

I've tried with the demo that comes with "mmwave_sdk_01_00_00_05" with some profiling hooks added for chirp interrupt handler.
This issue is observed for the above mentioned profile configuration i.e. with 56us.
But, when I tried with the default configuration that is loaded from mmw visualizer, there seems to be no issue, and it ran for more than 12 hours without any issue.

May be short chirp times are causing this to happen. Could you please let me know whether this kind of issue has been observed.

Thanks,
Chidvilas

Do you see any crash (an exception taken by the DSP) or unexpected final results (point-cloud) or just that your profiling hooks are showing the occasional unexpectedly low number? SDK 1.0 is known to have trouble with very small chirp times (because of a late and large processing time interrupt coming from mmwavelink when chirping starts, eating up the CPU and hence causing real-time deadline to be violated which we catch in software and do an exception assert). SDK 1.0 because of this problem was having crashes at around 25 us (and this has been addressed in future releases) but 56 us seems large enough to not cause crash.

If you don't see a crash but just your measurement is showing anomalies, then it could be the BIOS periodic interrupt that comes every 1 ms (we don't disable it during 1D processing) and if it happens to hit during the chirping period occasionally, it may be holding up the chirp interrupt long enough that your profile hooks show some jitter in the inter-chirp period (hence much lower than the nominal 56 us and maybe sometimes even higher). In later releases where we have fixed the mmwavelink issue mentioned above (and therefore we can handle very small chirp times), but we still don't disable the BIOS tick interrupt because its overhead is low enough that it does not affect the chirp processing even for small chirps.
We use BIOS timing services although not in 1D processing time, so theoretically we could disable during 1D (and reenable after 1D processing) but this is not clean as some higher level code in future that activates during idle periods in 1D processing may need timing services could get affected, but if you like you can experiment with disabling BIOS tick during 1D (you may need to read BIOS API documentation to see how to do this).

Although this problem may not be because of SDK 1.0, I would encourage you to upgrade to current release if not too much hassle, our support on very old release like 1.0 will be very limited. Thanks.

I think this issue is related to the first problem you have mentioned.

In TI's mmWave SDK demo, 1D processing takes around 12 us. It means that 1D processing of one chirp data should be finished before a new chirp data arrives.

In our use case, Chirp data processing takes around 33 us. Whenever the chirp time randomly drops to 28 us instead of configured 56 us, it hits the assertion condition and crashes.

For analyzing this issue, I've added profiling in the TI's "mmwave_sdk_01_00_00_05" demo release code (all the processing is performed using TI's algorithms). Loaded the above-mentioned profile configuration. From the profiling, it is found that after few hours the chirp time becomes 28 us for the entire new frame.

Due to time constraint upgrading to the newer SDK will be difficult for us.

Thanks,

Chidvilas