• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 32 subscribers
  • Views 3990 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.

RTOS/AWR1642BOOST: how to debug the CCS program of mmw demo?

user4916411
Prodigy 100 points
Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1443

Tool/software: TI-RTOS

I want to observe the Intermediate result of data stream. Under CCS development mode, I load C674X program first ，then load the CortexR4 program.

When put a breakpoint in data stream,run C674X program first ,then run the CortexR4 program and send CLI config to mmwwave device by mmWave Demo Visualizer.

Firstly ,the progaram will stop at the breakpoint ,but the CortexR4 program will exit with error.

Then ,run the C674X program sequentially,the C674x program also exists with error.

In a word,I want to debug  the program of mmw demo step by step and how to do ？

the console displays as follow：

[C674X_0] Debug: Logging UART Instance @00815560 has been opened successfully
Debug: DSS Mailbox Handle @0080f550
Debug: MMWDemoDSS create event handle succeeded
Debug: MMWDemoDSS mmWave Control Initialization succeeded
Debug: MMWDemoDSS ADCBUF Instance(0) @00815530 has been opened successfully
Debug: MMWDemoDSS Data Path init succeeded
Debug: MMWDemoDSS initTask exit
[CortexR4_0] **********************************************
Debug: Launching the Millimeter Wave Demo
**********************************************
Debug: MMWDemoMSS Launched the Initialization Task
Debug: MMWDemoMSS mmWave Control Initialization was successful
Debug: CLI is operational
Sensor has been stopped
Debug: MMWDemoMSS Received CLI sensorStart Event
[C674X_0] Heap L1 : size 16384 (0x4000), free 2816 (0xb00)
Heap L2 : size 49152 (0xc000), free 35592 (0x8b08)
Heap L3 : size 655360 (0xa0000), free 507904 (0x7c000)
[CortexR4_0] xdc.runtime.Main: "platform/mmwave_xwr16xx.c", line 1089: assertion failure
xdc.runtime.Error.raise: terminating execution
[C674X_0] {module#8}: "../dss_main.c", line 264: error {id:0x10000, args:[0x8139d4, 0x8139d4]}
xdc.runtime.Error.raise: terminating execution

  • 0
    TI__Mastermind 22155 points
    Hello,
    What is your setting in the "number of frames" of the frameCfg ? Have you set it to 0(infinite ) ?

    -Raghu
  • 0 in reply to Raghunandan Kamath
    TI__Expert 6205 points
    Hi Raghu,
    This customer want to verify his own signal process algorithm(CFAR) in CCS.
    He use an out-of-box demo in SDK without any modification for test.
    He can load C674X and R4F program successfully and the program can work successfully.

    Then, set a breakpoint in C674X's dssDataPathProcessEvents (for example: dss_main.c -> line 1526: MmwDemo_interFrameProcessing(dataPathObj);) , and setup parameter using CLI command, and start the sensor.
    The program can stop at this line, but if I continue run the program, the CCS will give an error shown below.

    [C674X_0] {module#8}: "../dss_main.c", line 264: error {id:0x10000, args:[0x8139d4, 0x8139d4]}
    xdc.runtime.Error.raise: terminating execution

    How to avoid this error and debug the signal process data path in CCS?
    Can you give some tips to debug the signal process data path?
    Thanks.

    Ragards,
    Wesley.
  • 0 in reply to Raghunandan Kamath
    Prodigy 100 points
    Yes, set it to 0(infinite). and i can debug step by step by using AWR1443.
  • 0
    TI__Guru 69960 points
    Hello,
    In mmw demo at many points application has the checks for timingly arrival of specific data that may includes chirp, frame insterrupts/counts or FFT processing events/status. If any of these don't match with pass criteria then application hits the ASSERT failure condition and execution terminates.

    In your case you might be putting breakpoints at the location which is hitting after device starts chirping (i.e. post sensorStart command) and due to above said checks execution is terminating.


    To supress these ASSERT checks you need to modify 'packages/ti/common/mmwave_sdk.mak' file to undefined 'DebugP_ASSERT_ENABLED' MACRO for C674_CFLAGS and R4F_CFLAGS compiler flags.

    Post-modification to this file, compile the mmw demo application and try with CCS.


    Regards,
    Jitendra Gupta
  • 0 in reply to Jitendra Gupta
    Expert 1095 points

    Jitendra,

    Out of curiosity, what happens to the stability of the radar subsystem and subsequent data collection complete events (e.g. chirp/frame events) when you undefine "DebugP_ASSERT_ENABLED" and pause for extended periods of time (i.e., orders of magnitude longer than a single frame).

    Is the system still stable enough to resume execution in the debugger, collect new ADC data, and process it during the chirp and frame events?

    Thanks,
    Erik

  • 0 in reply to Erik Larsen
    TI__Guru 69960 points
    Hello Erik,
    Halting device via JTAG/debugger won't impact device chirping (HW level) but in the SW it may impact the processing of DSP. Say if you halt DSS then it'll lag behind the device chirping event and when you restart execution it may start from some number of chirp of last or next few frames, i.e. DSP
    will be out of sync to frame/chirp events and processing output may or may not be as expected.
    But debugger halting won't effect ADCBuffer data filling event and chirp/frame HW interrupt.

    So step execution in debugging mode of SDK demo will impact the overall demo (MSS and DSS) execution flow.

    Runtime you can put breakpoints to check some intermediate buffers/variables/FFT-outputs.


    And futher adding to the last post of mine-

    Post modification of 'packages/ti/common/mmwave_sdk.mak' to undefine MACRO build 'drivers/osal' libray and then clean & build demo application to debugg with CCS.


    Regards,
    Jitendra
  • 0 in reply to Jitendra Gupta
    Expert 1095 points

    Thanks Jitendra,

    Could you make sure I understand this statement correctly:

    Jitendra Gupta said:
    Say if you halt DSS then it'll lag behind the device chirping event and when you restart execution it may start from some number of chirp of last or next few frames, i.e. DSP
    will be out of sync to frame/chirp events and processing output may or may not be as expected.

    Will the DSP be out of sync with the frame/chirp events, because the "obj->chirpCount" is now in an unknown state relative to the radar subsystem chirps? Because "obj->chirpCount" simply counts chirps and doesn't actually know when a frame ends, it may think a frame has completed because it counted enough chirp events, but in reality the radar subsystem is still in the middle of frame.

    Also, to undefine the DebugP_ASSERT_ENABLED in the .mak file, do we simply remove all of the lines that set this flag "--define=DebugP_ASSERT_ENABLED"?

    Regards,
    Erik

  • 0 in reply to Jitendra Gupta
    Prodigy 100 points
    hello，
    I just remove the ‘--define=DebugP_ASSERT_ENABLED’ MACRO for C674_CFLAGS and R4F_CFLAGS compiler flags. Clean and build the mmw demo,but the same error will be happen .

    i just want to debug this demo step by step and can you tell me some specific details??
  • 0 in reply to Erik Larsen
    TI__Guru 69960 points
    Erik,

    Yes, if you halt DSP then it may be out of sync for chirp/frame numbers compare to hardware chirp/frame counts. "obj->chirpCount" will lag behind HW chirp count, so when you un-halt DSP core again then based on this "obj->chirpCount" it may assume frame end but in reality on HW that chirpCnt will be part of next few frames and may be in b/w of frame.

    To undefine you can delete this "--define=DebugP_ASSERT_ENABLED" from .mak file.


    Regards,
    Jitendra