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.

CCS/AWR1642BOOST: Debug on CCS and Check If previous chirp processing has completed

Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1642

Tool/software: Code Composer Studio

 Hello everyone, I have some questions want to ask you for your help.
1. I’ve tried to implemented the an algorithm on AWR1642. I’ve added one more line of parameter in the AWR1642 configuration file. I can compile/ rebuild the mmw_mss and mmw_dss without errors. Then I connect EVM board to CCS, loading the xwr16xx_mmw_mss.xer4f and xwr16xx_mmw_dss.xer4f file to the EVM boards, everything just goes fine. After that, I transfer the configuration file via CLI to EVM board, and start sensor. Up to here, everything just goes smoothly with a Done acknowledgement.
However, when the program runs on the EVM board, it generated 2 errors like this. 
Inline image 1
Looking at the code, here is where It generated the error, function MmwDemo_dssFrameStartIntHandler (). I’m trying to figure out how to solve it, but It’s quite urgent now, so I just want to ask you early with a hope that I can quickly solve the problem.
 Inline image 2
2. Could you show me how to use some tools in CCS (break point, run into ...) to support debugging process. I search online and it seems like I need to load a “symbol file.Out" to my target configuration, but I couldn’t find it in this case.
Thank you so much,
Best regards,
Taiga.
  • Hello Taiga,
    Looks like you tried to add few snapshots, but they are not attached.
    Please let us know what 1 line change you did in the configuration file.

    Thanks,
    Raghu
  • Hello Raghu,

    I dont know why you cant see at your side, I'm still able to see it. Anw, here're these pictures:

    Picture 1: error shown in CCS. 

    - Picture 2: where the error is generated

    Thank you so much, 

    Best regards,

    Taiga

  • Hello Raghu,

    I'm sorry for lacking some information about the change in the configuration file.
    I added a new line of configuration parameters which are used in the algorithm being implemented, the format just look like other lines

    Thank you, and hope to hear from you soon.
    Best regards,
    Taiga
  • Hello Thuan,

    We would recommend you going over mmw demo document (mmw\docs\doxygen\html\index.html) for data path timing or DSP processing flow. 

    Here is the snapshot from the same doxygen document which shows data processing flow and sending object list out of system.

    So at each frame start interrupt (MmwDemo_dssFrameStartIntHandler) DSS application makes sure that it has done the processing of the last frame and calculated object list has been sent out properly then only proceed further to process next frame, else raise an exception (DebugP_assert).

    In your case after you added new CLI command in configuration file, looks like that is causing somewhere extra delay which further hinders the processing (2-D/3-D FFT) and object shipment task. Thus it's hitting an exception.

    Kindly check the code flow of new CLI command in the DSS.

    Regards,

    Jitendra

  • Hello Jitendra,

    Thank you for your advice. I'm following the processing data path to debug, too.

    Now I am able to run the program step by step, but it's only at initial state (up to open the CLI to operate), before I load the configuration file into EVM. After that, if I set some breakpoints and try to see value of some variable but it causes the program to halt, the same problem as I shown above:

    ( /* Check if previous chirp processing has completed */
    DebugP_assert(gMmwDssMCB.dataPathObj.interFrameProcToken == 0);
    gMmwDssMCB.dataPathObj.interFrameProcToken++; )

    From my understanding, it's reasonable because the break point will result the program to stop for a while until I click next step. As a result, the processing time will exceed the limited interframe time and it will pop up the issue.

    So, I want to ask you is it possible to run the program step by step during the intra-frame process and inter-frame process (after I load the configuration file into the EVM). If yes, could you kindly show me how?

    Thank you so much for your help. I'm looking forward to hearing from you
    Best regards,
    Taiga
  • Hello Jitendra,

    Could you please help me answer the question above.

    By the way could you tell me how can I interpret the following error? what "Module # 48" is and how to locate that module and  how can I determine the error ID and Args

    Thank you so much,

  • Hello Thuan,

    Apologies for the delayed response.

    To debug mmw demo application you need to do the following changes

    1. modify ti\common\mmwave_sdk.mak: remove 'DebugP_ASSERT_ENABLED' definition for 'C674_CFLAGS' and 'R4F_CFLAGS' flags.

    2. build all the libraries which are being used by mmw (MSS and DSS) application (cmd: gmake clean, gmake all), this will remove 'DebugP_assert' call from all the libraries.

    3. comment '#define DebugP_ASSERT_ENABLED 1' in ti\demo\xwr16xx\mmw\dss\dss_dataPath.c

    4. goto mmw path and do the clean and build (make clean, gmake all).

    These changes will skip the ASSERT part when you halt MSS or DSS core for debugging over JTAG so it won't go into any 'assertion failure'.

    Note- If you do step in during JTAG, DSS functionality/processing flow may break.

    Hopefully, it should help you to proceed with JTAG debugging.

    Regards,

    Jitendra

  • Dear Jitendra,

    Thank you so much for your reply. Actually for the last few days, I've tried another way to debug my above issues and i solved it. Still, I think your reply is very useful and I can use it afterward.

    Anw, is there anyway to run the program step by step during DSS processing flow?
    I notice there're some "standalone tests" in "C:\ti\mmwave_sdk_01_00_00_05\packages\ti\drivers\test\dsp_edma"
    could u show me how can i use it with my program?

    Thanks!!
    Best Regards,
    Taiga