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.

IWR6843AOP: Stop sensor

Part Number: IWR6843AOP
Other Parts Discussed in Thread: IWR6843, IWRL6432

Hi,

I have two questions regarding the sensorStop command. I'm using a custom board based on the IWR6843AOP with modified OOB demo firmware to incorporate Rx/Tx communication over the CAN-FD interface. I have successfully modified CLI_task() to process configuration commands received over CAN. This is working well, similar to CLI, except:

  • When the sensorStop command is processed, there is an error "HWI Stackoverflow" at this line "if (stackOverflow == TRUE)" in MmwDemo_sensorStopEpilog, and the sensor does not respond to further commands. When I bypass this using "if (FALSE)", everything seems to work well; the sensor stops sending data, and I'm able to start it again (e.g., using sensorStart 0). In this case, sensorStopEpilog writes:

Task Stack Usage (Note: CLI and sensor Management Task not reported) ========== Task Name Size Used Free Init 2048 1996 52 Mmwave Control 3072 2368 704 ObjDet DPM 4096 2564 1532 HWI Stack (same as System Stack) Usage ============ Size Used Free 1200 0 1200

My second question is related to stopping the sensor RF itself. I would expect some decrease in power consumption when stopping a sensor; however, it remains approximately the same. Does "sensorStop" also stop the RF part, or is there a way to achieve this?

Thank you,

Adam

  • Hello,

    We will get back to you next week, apologies for the delay.

    Best Regards,

    Pedrhom

  • Hi Pedrhom

    Is there any update on this matter? I can confirm that I have successfully started and stopped the sensor over CAN while using mentioned bypass. Additionally, I am able to change the configuration while the sensor is running. However, sometimes the sensor freezes—it communicates but sends no data. I believe this may be due to an improper configuration command, but more testing is needed.

    Thanks,

    Adam

  • Hello Adam, 

    I'm very sorry about the delayed response here. Is the stack overflow error resolved then? It seems it could possibly be related to the changes you made in the CLI task. It's possible that you might need to increase the CLI task stack size. 

    However, sometimes the sensor freezes—it communicates but sends no data. I believe this may be due to an improper configuration command

    If you have modified one of the example configuration files then this could be possible. Can you share the configuration that causes the sensor to freeze? 

    Best Regards,

    Josh

  • Hi Josh,

    when I use mentioned bypass, it works well. I can try to increase stack size. Regarding the causes the sensor to freeze, I believe it was due to inproper configuration commands. 

    Could you plese answer my second question?:

    My second question is related to stopping the sensor RF itself. I would expect some decrease in power consumption when stopping a sensor; however, it remains approximately the same. Does "sensorStop" also stop the RF part, or is there a way to achieve this?

    Thank you,

    Adam

  • Hi Adam,

    Understood. 

    My second question is related to stopping the sensor RF itself. I would expect some decrease in power consumption when stopping a sensor; however, it remains approximately the same. Does "sensorStop" also stop the RF part, or is there a way to achieve this?

    The sensorStop command will only stop the repeated frames/chirps triggered from the RF front end however it does not power down/clock-gate any systems so there is no associated power saving. 

    If you are interested in reducing the power consumption in the IWR6843 demo we actually have an example in the Radar Toolbox which implements software optimizations on top of the out-of-box demo and adds "low power modes" in which certain peripherals/processors are shut down/clock-gated when not in use. Here is a link to the user guide for this example. 

    Best Regards,

    Josh

  • Hi Josh,

    I had assumed these low power modes were exclusive to the 3rd generation—thanks for the update. Have you conducted any tests to quantify the savings in power consumption? Could you share some average figures on what can be achieved with these low power modes?

    Thank you,

    Adam

  • Hi Adam, 

    Sorry for the delayed response. The 3rd gen devices ("L" family of devices) such as IWRL6432 have been designed in a manner which optimizes power consumption and includes hardware hooks to enable low power modes (deep sleep). This example that I linked for low power on 6843 only includes SW optimizations to reduce power consumption. The average power consumption that you can achieve with this example will be significantly lower than what is possible with the out-of-box demo but it will still not come close to what can be achieved with IWRL6432.

    Also I want to apologize as I thought this application note (https://www.ti.com/lit/swra689) was also linked in the user guide that I shared. The example code that I shared implements the changes described in this application note. Please refer to this for specific numbers on what can be expected in terms of power consumption reduction. 

    Best Regards,

    Josh