• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 394 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.

Original question:

IWRL6432BOOST: Why SemaphoreP_pend is required at the end of CLI_Task in MMWAVE_L_SDK_05_01_00_04

AWRL6432BOOST: Issue in sensor start with hardcoded radar configuration.

Girish Veerendra Medisetty
Prodigy 230 points
Part Number: AWRL6432BOOST


Hi team,

Sorry I did not get answers for almost all of my questions in this e2e thread. I am reposting my question with extra details

we are using MMWAVE_L_SDK_05_01_00_04 and AWRL6432L board. we have a memory constraint to use as much as less memory for code section and needs to use CAN.

We are using CAN for configuring radar instead of CLI task and we removed all CLI function calls such as open and init functions. Sensor is not getting started.

So we debug the code in following methods on base SDK code:

1. Before CLI_init, hard coded radar configuration code to bypass CLI configuration in freertos_main thread and called mmwDemo_factoryCal and CLI_MMWStart functions. By doing this, sensor is not started.


2. On top of method 1, created another task same as CLI_Task(called sensorStart_Task) and called only mmwDemo_factoryCal and CLI_MMWStart functions in it. Sensor is started at once, went upto rangeproc_process and then further RSP process has not happened.

3. On top of method 2, We kept semaphoreP_pend after starting sensor. The RSP sequence is happening fine in debug mode with gDebugTargetCode = 1. But while running in release mode with gDebugTargetCode = 0, assertion is seen at line no:574 in motion_detect.c. which tends to mmwMssMCB->interSubFrameProcToken == 0 error for first frame. 

4. On top of method 3, We set gDebugTargetCode = 1 and ran for one frame in Debug mode and kept break point after range proc, It did not hit the break point. But if I ran for 2 frames, It is hitting break point for one time. So I believe for first frame it is not hitting the break point, but for second frame it is hitting,

Here are my questions from above experiment.
1. Why sensor should be started using task and that task should be alive(using semaphoreP_pend or while(1)), to happen mmwDemo_DpcExecute?

2. In Method 2, why it is going untill rangeproc_process and further sequence is not happening?

3. In method 3 that too in release mode, why that assertion is seen?

4. In method 4, what is happening in first frame.

Please help us here, Thanks in advance

Regards

M Girish Veerendra

  • 0
    TI__Expert 3525 points

    Hi Girish,

    Quick question, were you able to use hard coded configuration with the out of box demo (MMWAVE_L_SDK_05_01_00_04\examples\mmw_demo\motion_and_presence_detection)?

    You can modify this demo to use a hard coded configuration by changing one line in mmw_cli.c. This is done by uncommenting line 105 in order to define CLI_BYPASS. Can you check if just this modification is functional on your end?

    Best Regards,

    Kevin

  • 0 in reply to Kevin Ortiz
    Prodigy 230 points

    Hi Kevin

    Kevin Ortiz said:
    Quick question, were you able to use hard coded configuration with the out of box demo

    yes I hardcoded gMmwMssMCB structure directly instead of using CLI tableEntry functions

    Kevin Ortiz said:
    You can modify this demo to use a hard coded configuration by changing one line in mmw_cli.c. This is done by uncommenting line 105 in order to define CLI_BYPASS. Can you check if just this modification is functional on your end?

    yes, When using CLI_BYPASS, everything is working fine. but as I said to reduce code section I cannot use CLI tableEntry functions so please help me here.

  • 0
    TI__Expert 3525 points

    Hi Girish,

    Yes thank you for the clarification. One more clarifying point so I understand what is the goal, are you looking to replace CLI with CAN. That is, send configurations via CAN and start the sensor via CAN? You mention configuring radar with CAN, but seems like you are doing hard coded configuration and expecting the sensor to start immediately at runtime pretty much.

    Best Regards,

    Kevin 

  • 0 in reply to Kevin Ortiz
    Prodigy 230 points

    Hi Kevin,

    My ultimate goal is to configure radar with CAN by replacing CLI. but When I did changes, I faced above mentioned issues.

    I thought my configuration with CAN is wrong. So, I checked in default SDK by hard coding configurations and removing CLI. Still I faced the same issues. Please help me to find answers here.

    Regards

    MGV 

  • 0
    TI__Expert 3525 points

    Hi Girish,

    If you are attempting to use CAN to send the configurations, what you're actually replacing is UART, not CLI. Right? I'm not sure I understand, but if this was the case then you'd still need CLI. I'm assuming you're maybe just assigning the parameters to their respective structure variable when processing CAN messages. We cannot debug custom software, but below are my suggestions to your queries. One is still outstanding, I need to find more information on this point.

    1) I am still looking to get confirmation here. 

    2) I'm not too sure why it's not working. Are you using a modified chirp configuration? There are checks that the CLI infrastructure does to make sure the parameters are valid. An invalid chirp design could result in this not functioning correctly.

    3) I suspect this is symptom of what's going on in method 4. The code hangs and when the interrupt for the next frame comes, the assert fails as the processing for previous frame was not completed. 

    4) Probably hanging in rangeProcDPU. Can you step through and see exactly what line fails?

    Best Regards,
    Kevin 

  • 0 in reply to Kevin Ortiz
    Prodigy 230 points

    Hi Kevin,

    please find the answers here

    Kevin Ortiz said:
    I am still looking to get confirmation here. 

    I understand you are suggesting to use CLI. but there should not be a difference in behavior of pipeline with CLI and without CLI. When I hardcoded gMmwMssMCB structure and trying to start sensor, Why it is not working as expected (which I discussed in my first question). Please don't mind if I meant it to be arguing, but actually I am trying to find answer.

    Kevin Ortiz said:
    Are you using a modified chirp configuration?

    I am not using modified chirp configuration. On the base SDK, I enabled BYPASS_CLI(which is given by you in this thread) and got the values of gMmwMssMCB structure, using these values I hardcoded and did steps I mentioned in my first question. 

    Kevin Ortiz said:
    The code hangs and when the interrupt for the next frame comes, the assert fails as the processing for previous frame was not completed. 

    Yes, I understand the reason of the assertion, If it stucks at range DPU for the first frame, It should always stuck for all frames. But why it is working when we set gDebugTarget to 1? I am searching for the reason of the stuck in first frame onyl, and why it is not getting stuck in other frames?

    Kevin Ortiz said:
    Can you step through and see exactly what line fails?

    It is stopping in semaphore_pend at rangeProcObj->hwaDoneSemaHandle.


    Please let me know If you need further information.

    Regards
    MGV

  • 0
    TI__Expert 3525 points

    Hi Girish,

    I humbly apologize for the delay. The sensor needs to be started from within a task, but that task must then be suspended somehow (e.g. a semaphore) so that the DPC task can perform its operations. In the motion and presence demo, the RTOS task that performs the system initialization has the highest task. This task is immediately ended, and the CLI task has the highest priority. The DPC task is then created by the CLI task and allowed to setup the processing chain blocks. If the CLI task is not halted and the sensor start is immediately issued, then the HWA may finish its chirping before the processing is ready for data. I suspect this may be the cause of the issue. 


    Section 9 of the MotionPresenceDetectionDemo_documentation.pdf found in the docs folder of the SDK goes over the task model of the device. I think this should be able to assist in implementing the task as you are wanting. 

    Best Regards,
    Kevin