IWR6843ISK-ODS: lab0020-pplcount_Overhead sensor stop with cfg change

Smart Fountain

Intellectual 320 points

Part Number: IWR6843ISK-ODS

Hi,

I tested pplcount demo with the cfg attached which was low CFAR thresholds.

The version of the tool box is 3.4.0.

It could be started, but it was stopped when many points/objects appeared.

I tried to find the reason with CCS, but I could not find it.

The console text and capture of the Debug window are also attached.

Q1. What is the reason of sensor stop ? I will send other information if you need for analysis.

Q2. Can the issue solved with software ? Or is it needed larger memory or higher CPU ?

Note: The intention of the configuration change are following.

- bandwidth shall be < 0.5 GHz in our environment.

- would like to detect people almost static (ex. sitting on chair).

- would like to output many points for detect almost static people.

Best regards,

Fountain

3806.mmw_pplcount_demo_default.cfg

Fullscreen Console.txt Download

[C674X_0] Debug: MMWDemoDSS Data Path stop succeeded stop1,frames:4859 
[Cortex_R4_0] CFAR Config sent successfully
CFAR Config sent successfully
Debug: System Heap (TCM): Size: 98304, Used = 55736, Free = 42568 bytes
Debug: System Heap (TCM): Size: 98304, Used = 55736, Free = 42568 bytes
Debug: (GtrackModuleInstance *)0x8009d30
Debug: System Heap (TCM): Size: 98304, Used = 55736, Free = 42568 bytes
Debug: MMWDemoMSS Received CLI sensorStart Event
MMWDemoMSS config success!
Debug: System Heap (TCM): Size: 98304, Used = 55736, Free = 42568 bytes
Debug: MMWDemoMSS mmWave  config succeeded 
[C674X_0] Heap L1 : size 16384 (0x4000), free 4096 (0x1000)
Heap L2 : size 49152 (0xc000), free 34888 (0x8848)
Memory allocation successful
Heap L3 : size 786432 (0xc0000), free 370688 (0x5a800)
{module#8}: "../dss_main.c", line 2088: error {id:0x10000, args:[0x81a444, 0x81a444]}
xdc.runtime.Error.raise: terminating execution
[Cortex_R4_0] Error: Unsupported Mailbox message id=-18022141

over 6 years ago

0 Justin Curewitz over 6 years ago

TI__Mastermind 28055 points

Hi Fountain,

Memory is fully allocated when the configuration was received. If the demo crashed after this, it probably isn't a memory issue. When running the demo with the default config, do you have the same error? How you changed anything else besides the config?

Regards,

Justin

0 Smart Fountain over 6 years ago in reply to Justin Curewitz

Intellectual 320 points

Hi Justin,

The issue wasn't happened in the case of the frame period changed from 100ms to 150ms.

It is supposed that the frame processing was not finished in the case of period 100ms because it was very short time (1.5ms) from the end of a frame and the beginning of the next frame.
Do you think the guess can be happened ?

If yes, I will take the 150ms period. I have two related questions.

1.
Do you have any figures of the minimum frame processing time ?

2.
Is there any negative impact (especially about tracking algorithm) by increasing the frame period from 100ms to 150 ? The maximum speed in our use-case is at most 1-2m/s.

Best Regards,

Fountain

0 Justin Curewitz over 6 years ago in reply to Smart Fountain

TI__Mastermind 28055 points

Hi Fountain,

1. Generally, I would recommend 20 ms between end of the active frame and beginning of the next frame - however, this is not always necessary. I recommend some experimentation with your config. You may also want to run the demo in debug mode to determine exactly where it is crashing. If the crash is in DSS, there is an issue with processing time. If the crash is in MSS, you may find that UART is taking too long to send. In this case, you may be able to use a different interface in your system.

2. Tracker performs better with more updates. However, for slow objects like the ones you intend to track, you can achieve good performance with lower frame rates. Please ensure you change the tracking cfg to use the correct frame period: trackingCfg 1 2 250 20 52 82 50 90 - the bold 50 would need to be 150 to match your frametime.

Regards,

Justin

0 Smart Fountain over 6 years ago in reply to Justin Curewitz

Intellectual 320 points

Hi Justin,

Thank you for your comments.

1. It seems the crush is in DSS. It was shown that "../dss_main.c", line 2088: error ". The line is assertion for dataPathObj->chirpCount == 0.

I'm not sure but it is supposed that the processing time was not enough to increment the chirpCount.

Anyway, it has not been occurred crush for a few days with 150ms frame rate, I will take it.

2. I have changed trackingCfg as your advice. Thanks.

Best regards,

Fountain.

Sensors

Sensors forum

IWR6843ISK-ODS: lab0020-pplcount_Overhead sensor stop with cfg change