AWR1642: The timing of frame start interrupt

Hi Cesar,
    Thanks for your reply. I was debugging a customer issue in a project which is developed on AWR1642 SRR demo. I find in task SRR_DSS_mmWaveTask, their code will meet the assert chirpCount != 0. Actually since this branch is posted by the frame start interrupt in the beginning of the frame, the chirpCount should be 0 at this time. I just don't understand why we added this assert here. So as you said, is this assert added here just to work around the issue in chirp interrupt in SRR/MRR demo?
   

      if (gSrrDSSMCB.frameStartIntToken == 1)
        {
            gSrrDSSMCB.frameStartIntToken = 0;

            dataPathObj = &gSrrDSSMCB.dataPathObj[gSrrDSSMCB.subframeIndx];
           
            /* Increment event stats */
            gSrrDSSMCB.stats.frameStartEvt++;
           
            /* Check if the previous frame has been completely processed. */
            MmwDemo_dssAssert(dataPathObj->chirpCount != 0);
        }

Thanks,
Adam

Adam

The purpose of the assert is to check that the UART transfer has completed.

If a new frame has started, the range FFT will be computed and will overwrite the radar cube.

The SRR code is based on the SDK 1.0 OOB demo.

The assert was added to make sure that we don't overwrite the radar cube if the UART transmission is not completed

Thank you
Cesar

Hi Cesar,
Thanks for your reply. Through your explanation, I understand the intension of this assert. I still have a question on this assert's condition.
1. After all the chirps has been processed in a frame and UART transfer completed, the variable dataPathObj->chirpCount will be cleared to zero.
2. After the first chirp of next frame has been processed , the variable dataPathObj->chirpCount will increase to one
If we are making sure at the beginning of next frame, the UART transfer of the previous frame has completed, should we use below assert?
MmwDemo_dssAssert(dataPathObj->chirpCount == 0);

Thanks,
Adam

Adam

You are right.

I reviewed the code, and this Assert does not check for UART completion. It checks if all we have completed processing all the chirps.
So, I think this can be removed.

Regarding the AWR1843 MRR issue, we have not root caused it yet

thank you
Cesar