IWR1642: meet error when using special chirp config

Chris Meng

Mastermind 37756 points

Part Number: IWR1642

Hi,

My customer is using mmw demo in old mmwave sdk 08 and tried below cfg and met error.

cfg: profile_20170622.cfg

full error log in ccs:

Fullscreen error_log20170622.txt Download

[CortexR4_0] **********************************************
Debug: Launching the Millimeter Wave Demo
**********************************************
Debug: MMWDemoMSS Launched the Initialization Task
Debug: MMWDemoMSS mmWave Control Initialization was successful
[C674X_0] Debug: Logging UART Instance @0080f0e0 has been opened successfully
Debug: DSS Mailbox Handle @00809200
Debug: MMWDemoDSS create event handle succeeded
Debug: MMWDemoDSS mmWave Control Initialization succeeded
Debug: MMWDemoDSS ADCBUF Instance(0) @0080f0c8 has been opened successfully
Debug: MMWDemoDSS Data Path init succeeded
Debug: MMWDemoDSS initTask exit
[CortexR4_0] Debug: CLI is operational
Debug: MMWDemoMSS Received CLI sensorStart Event
Debug: BSS Event MsgId: 128 [Sub Block Id: 4100 Sub Block Length: 20]
Debug: MMWDemoMSS mmWave  config succeeded 
[C674X_0] Heap L2 : size 24576 (0x6000), free 3432 (0xd68)
Heap L3 : size 655360 (0xa0000), free 63488 (0xf800)
[CortexR4_0] Debug: BSS Event MsgId: 128 [Sub Block Id: 4107 Sub Block Length: 0]
[C674X_0] {module#8}: "dss/dss_main.c", line 201: error {id:0x10000, args:[0x80d734, 0x80d734]}
xdc.runtime.Error.raise: terminating execution

[C674X_0] {module#8}: "dss/dss_main.c", line 201: error {id:0x10000, args:[0x80d734, 0x80d734]}

Customer also changed code in dss_data_path.c as below.

from: #define SOC_AR16XX_DSS_L2_BUFF_SIZE 0x5000

to #define SOC_AR16XX_DSS_L2_BUFF_SIZE 0x6000

I checked the code related to error and it seems that the frame is not complete which causes the problem. Would you pls help to check why attached cfg cause such problem?

I also tried similar cfg in org mmw demo in sdk 1.0 and there is no such issue. As customer already worked on sdk 08 for long time and currently they have no time/resource to move to sdk 1.0, they want TI to fix this problem on sdk 08.

Thanks,

over 8 years ago

0 Vivek Dham over 8 years ago

TI__Guru 58035 points

Hello Chris,
We would recommend them to move to SDK 1.0 . The earlier they move it would help them at later point in time.

Regards,
Vivek

0 Chris Meng over 8 years ago in reply to Vivek Dham

TI__Mastermind 37756 points

Vivek,

Customer insisted on asking the root cause of this issue on 08 sdk.

I tried more test today. Pls check info below. Did you get any clue on this issue?

1. Same error if I increase the idle time and frame periodicity.

profileCfg 0 77 15 7 37 0 0 5 1 128 5500 0 0 48
frameCfg 0 1 128 0 128 200 1 0

2. New error if I change the number of adc sample from 128 to 64. No effect if I increase the frame periodicity.

profileCfg 0 77 7 7 37 0 0 5 1 64 5500 0 0 48
frameCfg 0 1 128 0 64 100 1 0 or frameCfg 0 1 128 0 64 50 1 0

{module#8}: "dss/dss_main.c", line 180: error {id:0x10000, args:[0x80d734, 0x80d734]}

This error is from MmwDemo_dssChirpIntHandler.

Thanks,

0 db_woodall over 8 years ago

TI__Mastermind 21025 points

Hi Chris,

Several issues here. First, Vivek is correct, they will eventually have to move to the current SDK, and the longer they delay the more difficult it will become. We are not supporting [pre-market] SDK 0.8, nor does that SDK support the current silicon. Most importantly, the BSS firmware continues to be fine tuned, w/calibration improvements, and debugged. If there is an issue with the firmware (i.e. causing a hang), the only way to solve this is to update the SDK.

Second, do you think the buffer size change is related to this? Has the linker placement been checked to make sure that the buffer still fits in memory and doesn't collide with anything else?

Third, the example demos cannot support all chirp configurations. If a new configuration causes a hang (such as frame not complete), then even though it is likely the problem is the chirp, it could also be that the new chirp is too demanding in one aspect or another for the demo code (which also has been significantly modified for 1.0.0.5). Typically, I've seen that frame hangs (esp. when the frame event doesn't happen) that the problem is the idle time being too small. I have also seen hangs due to do too many chirps relative to the rest of the config. This config creates the maximum number of chirps/frame, which is probably not necessary unless they are looking for very accurate velocity resolution.

There is also a new version of the chirp estimator that creates more robust configurations. I did look over the attached chirp configuration, and I didn't see any major issues. For non-MIMO configs, it doesn't make a lot of sense to have multiple identical chirpCfg statements - since they will all use the same (single) Tx antenna. The only real issue here is that you may end up with more chirps/frame than intended. It is hard to say anything further without knowing the chirp's requirements.

0 db_woodall over 8 years ago in reply to db_woodall

TI__Mastermind 21025 points

Closing the thread as it is not an issue in SDK 1.0.0.5.

Sensors

Sensors forum

IWR1642: meet error when using special chirp config