AWRL6432: Unable to Restart Sensor

Hello,

As you may have noticed, our Low Power Visualizer in the SDK has the ability to restart the device. The visualizer does this by issuing a restart command through the XDS110, no via the sensorStop command, which does not work for the low power architecture devices because there is not enough time to read in the CLI commands before the device goes into a low power state. 

Please see this thread for more information about how to solve this problem.

IWRL6432BOOST: How the app do Device reset when sending again another cfg file?

Regards,
Luke

Hello Luke,
Thanks for the information.

However, The restart issue that we are facing is when we are not using the Low Power mode. i.e. "lowPowerCfg" set to 0.

1. As per my understanding from the referred thread, when lowPowerCfg is 0, we can stop the sensor by using sensorStop and start the sensor by issuing sensorStart commands.

2. I am trying to achieve something similar in the given order below.
step1 : start the sensor
step2 : When frame number is 20, stop the sensor using the stop command/function
step3 : give a delay of 10 secs,
step4 : restart the sensor using start command/function.

I am able to see step 1,2,3 and working but not step 4.

3. Please note, I have removed the CLI completely, loaded the default configuration(hardcoded it), deleted the power management task, created the tasks "dpc_task"(priority 5) and "transmit output tasks"(priority 3) once only (rather than creating it everytime inside a seprerate task for Sensor Start).

I have created two functions which enable sensorstart and sensorstop separately and i am trying to achieve the repeated sensor start and stop using these two functions.

Please let us know how can i achieve this sensor start stop sequence multiple times, with dpc and transmit output tasks being created only once.

Thanks and Regards 

Bodhit Gupta

Hello Bodhit,

I understand what your goal is clearly now. Have you looked into the source code of motion_detect.c in motion_and_presence_detection_demo? Within this source file is the code that gets called when a sensorStop is received (normally over CLI). You could start with this segment of code.

// Imp Note: Sensor Stop command is honoured only when Low Power Cfg is disabled
if(sensorStop == 1)
{
    int32_t err;
    // Stop and Close the front end
    MMWave_stop(gMmwMssMCB.ctrlHandle,&err);
    MMWave_close(gMmwMssMCB.ctrlHandle,&err);
    // Delete the exisitng profile as we receive a new configuration
    MMWave_delProfile(gMmwMssMCB.ctrlHandle,gMmwMssMCB.mmwCtrlCfg.frameCfg[0].profileHandle[0],&err);
    // Free up all the edma channels and close the EDMA interface 
    mmwDemo_freeDmaChannels(gEdmaHandle[0]);
    Drivers_edmaClose();
    EDMA_deinit();
    // Demo Stopped
    rangeProcHWAObj* temp = gMmwMssMCB.rangeProcDpuHandle;
    temp->inProgress = false;
    gMmwMssMCB.oneTimeConfigDone = 0;
    // Re-init the EDMA interface for next configuration
    EDMA_init();
    Drivers_edmaOpen();
    gMmwMssMCB.stats.frameStartIntCounter = 0;
    sensorStop = 0;
    isSensorStarted = 0;

    // Delete the DPC, TLV as we will create them again in next configuration
    vTaskDelete(gDpcTask);
    vTaskDelete(NULL);
}

Note, as you may be aware of, this code is assuming a certain structuring of tasks. It is up to you to make sure, if you are developing a custom set of tasks, that you are properly killing and restarting tasks with the sensorStop & sensorStart code. I am not sure of the behavior when you issue a sensorStop but do not fully delete and restart the dpc_task as it seems you'd wish to do.

Regards,
Luke

Hi Luke, 

Thanks for the quick response.

I am using the above snippet itself, wrapped in a function, (except the line 26 and 27) for stopping the sensor after executing 20 frames. I can observe the sensor getting stopped also since the point cloud disappears. 

Since my goal is to create the tasks "dpc task" and "transmit output task" only once, i do not delete these tasks ever.

After 20 frames of execution and a delay of 10 secs, i call the same function again that i used to start the sensor first time. But the start doesn't happen(no point cloud) as the execution seems to be stuck somewhere.

When i pause the execution in CCS, it is found to be stuck at line number 2192, as shown in the screenshot below.

Can you please help me here by explaining the following points

1 .What possibly could be causing the execution to get stuck here and not letting me start the sensor and how can i fix it

2. If i am not using the low power mode, is it safe to remove the "Power management task" creation totally ?

3. If i am not reading the ADC data from a file can i eliminate the task creation for the same too ?

Thanks and Regards

Bodhit Gupta

Hi Bodhit, 

I am actively investigating and preparing a response for you. Allow me a little more time to get the response to you.

- Luke

Hi Luke,
My most sincere apologies for the delayed response.

Please find the answer to your questions below.

 1. Why do you not want to delete and recreate the tasks as our code demonstrates?

Ans. The reason behind this is that there are multiple sequences of sensor start and sensor stop without the Configuration in between,
The creation and deletion of tasks everytime causes additional overheads which needs to be avoided as a Customer requirement.

Could you please let us know how to achieve the sensor start - stop sequences with only 3 tasks;
i,e main, dpc task and tlv task and these tasks being created only once.

2.  I've found that if you set the lowPowerCfg to 0 in the .cfg file, you can comment out the creation of the powerTask, and the program still functions. Do you have a good reason for wanting to do this?

Ans. Currently we don't intend to use the low power mode. Hence the removal.

Thanks and Regards

Bodhit Gupta

Hi Bodhit, 

I am sorry I am not fully understanding your use-case. You want to stop the sensor but not change the config between stops? But you do not want to enter a low power mode. Do you want the state of the radar or processing to change at all between stops, or do you just want the radar to stop chirping?

If you paint the picture a little more clearly then I can best advise you on how to achieve it in code.

If you want to go ahead with trying an implementation, I recommend first doing away with the CLI task by implementing a hard-coded configuration. Of course, you have to make sure you treat any cross-task semaphores with care when you are doing away with a task. Then create a modified version of the low-power task which does not actually switch the device into a low power state but calculates the amount of time the task should take to sleep (i.e., sensorStart), and then uses a semaphore to pause the execution of the other tasks until the waiting period is done. 

Regards,
Luke

Hi Luke,

We want  successive sensor starts and stops by issuing a command/ or calling a function without change in Config.
When the sensor stop command is issued the RF should stop chirping so should the processing. When a sensorstart
command is issued again, the chirping should resume followed by processing of data.

We have tried the implementation suggested by you by -
1. removing CLI,
2. hardcoding the Configuration,
3. creating a newTask only once with priority 1 (lower than dpc and transmit tasks). This task contains the sensor stop, delay and sensorstart functions called in condition check if numFrames is equal to 20 , enclosed in an infinite while loop.

4. We created a gloabl variable, SENSORSTATE, which is set to 0 when sensor stops and 1 when sensor starts.

5. We are halting the DPC by using this SENSORSTATE variable and a pend.

6. This pend is posted right after the sensor start command is issued in the new task.

Observation: The sensor starts, code runs fine for 20 frames, sensor stops, but the control never comes to DPC again as it seems to be stuck in here -

Can you please let me know what changes need to be made to ensure that the execution reaches DPC again after MmwDemo_startSensor() is successfully executed.

Thanks and Regards 

Bodhit Gupta


 

Hi Bodhit,

Can you please step through the code and see where the hard fault exception is coming from? It seems like the DPC might not be starting/stopping cleanly and is throwing the exception there. 

Regards,
Luke

Hi Luke, 

Thanks  for the response.

In the new Task, i changed the SENSORSTATE to 0 and gave a delay of 1 sec(screenshot 1) so that the control goes to the semaphore pend in dpc_task(screenshot 2).

Screenshot 1

Screenshot 2

As soon as this breakpoint(line 3743) at pend is hit in dpc task, I do a step over.

My expectation is that the execution should go back to newTask but instead it goes into hard fault exception (right after the step over after pend in dpc task.)

Please help me understand why does the flow go to hard fault exception and how do I cleanly start and stop the DPC.

Thanks and Regards

Bodhit

Hello Bodhit, 

Can you please show me how you are creating temp_semahandle. Are you using SemaphoreP_constructBinary or xSemaphoreCreateBinaryStatic to create the temp_semahand?

If you are defining temp_semahandle in a different file, are you using extern TaskHandle_t temp_semahandle to make the temp_semahandle visible in the file you are pending in? 

Regards,
Luke

Hi Luke,

Thankyou for the response.

I had "temp_semahandle" declared only as a semaphore object but once I  use SemaphoreP_constructBinary  for the same, the execution reaches the new Task again without any hard fault exception now. i am able to do a stop followed by a start and a post to dpc execute.

After restarting the sensor again, followed by a post to dpc_task, I put breakpoints in dpcexecute to check if i am able to access DPC.

I am able to put breakpoints in dpcexecute but  as soon as i step over and reach the call to doppler_process(), the execution gets paused again.(screenshot1)

Screenshot1

When i check in the ccs to find where the execution is getting paused, i find it to be in the while(1) loop in the newTask that we created.(screenshot2)

Screenhot2

I am not able to understand this inspite of keeping the priority of the new Task to be lowest(1) and even same as transmit task(3).

Please help me understand why this is happening and how can it be fixed.

Best Regards,

Bodhit Gupta

Hi Bodhit, 

I am going to be passing this thread off to another expert on our team. They should be getting back to you soon. 

Regards,
Luke

Hi Bodhit,

Are you still working through this on the SDK 5.1? If so, could you follow up once you are on 5.3? I don't want us to have to do this work twice.

BODHIT Gupta said:

The reason behind this is that there are multiple sequences of sensor start and sensor stop without the Configuration in between,
The creation and deletion of tasks everytime causes additional overheads which needs to be avoided as a Customer requirement.

I would also like to know more about this requirement. Did you run your code with the task deletion and creation successfully first? I would like to know if you were able to do this and then you determined that loading the configuration was taking too long.

Thanks,

Clinton

Hello Clinton,

To avoid any rework I have already migrated and reproduced this issue in SDK 5.3. The observations shared here are from SDK5.3 itself.

About the requirement, the Goal here for me is to not have any task creation or deletion, multiple times(on every restart).

Though we were initially able to restart the sensor by deleting and recreating the dpc and tlv tasks(placed within a sensorstart task), We didn't go ahead with this approach further.

Please let me know if you have any more queries and guide me out how to achieve the sensor start -stop - start sequence multiple times.

Best Regards,

Bodhit Gupta

Hi Bodhit,

This is going to take some analysis as it deviates from how the demo is architected. We'll follow up with feedback.

Thanks,

Clinton