AWR1843: ASSERT ERROR || frame processing deadline

Hi,

Does the assert happen before the first chirp available interrupt happens? If it does the assert is probably related to the configuration.

Can you please provide more details about the assert?

thank you

Cesar

Hello Cesar,

The Assert happens as a frame start interrupt token is triggered before finishing the first frame processing.

Yes it seems to happen before the first chirp interrupt.

The configurations are the typical advanced frame configurations from the MRR project.

Regards

Mohamed

Hi,

I am sorry but I am still not clear if any processing happens. Could you please share with us the log?

Has the first frame processing started? It should not have started if the Assert happens before the first chirp interrupt.

Are you able to connect CCS and step through the code?

Thank you

Cesar

Hello,

The log:

[C674X_0] Debug: MMWDemoDSS create event handle succeeded
Debug: DSS Mailbox Handle 7ff6d8
Debug: CRC Channel 7ff870 has been opened successfully
Debug: Launched the mmwaveLink Management Task
Debug: BSS Mailbox Handle 7ff8e8
Debug: Power on request successfully passed to the BSS
Debug: Finished get radarSS bootup status to BSS
RF H/W Version : 02.00
RF F/W Version : 02.00.00.01.17.10.05
RF F/W Patch Version : 01.02.00.03.18.10.24
mmWaveLink Version: 01.02.00.01
[Cortex_R4_0] Error: unsupport Mailbox message id=-18022140
Error: unsupport Mailbox message id=-18022137
Error: unsupport Mailbox message id=-18022138
[C674X_0] Set LDO Bypass
Debug: MMWave has been configured for MRR.
Debug: Finished set channel configurations to BSS
Debug: Finished setAdcOutConfig to BSS
Debug: Finished setLowPowerMode
Debug: Finished rlRfSetDeviceCfg
Debug: Set HSI clock successfully
Debug: RF start successfully
Debug: Init time calibration status [0x800007fe]
Debug: Finished rlSetProfileConfig
Debug: Finished rlSetProfileConfig
Debug: Finished rlSetChirpConfig
[Cortex_R4_0] Error: unsupport Mailbox message id=-18022138
[C674X_0] Debug: Finished rlSetChirpConfig
Debug: Finished rlSetChirpConfig
Debug: Finished rlSetChirpConfig
Debug: Finished rlSetChirpConfig
Debug: Finished rlSetBpmCommonConfig
Debug: Finished rlSetAdvFrameConfig
ASSERT ERROR: line num 349: file E:/Saeed/......

Please see line 349 here:

Here are some run time values for some important variables after the assert:

gMrrDSSMCB.stats.frameStartIntCounter:1 
gMrrDSSMCB.stats.frameStartEvt :1 
gMrrDSSMCB.stats.chirpEvt : 0 
gMrrDSSMCB.stats.chirpIntCounter : 4 
gMrrDSSMCB.chirpProcToken: 1 '\x01'

regards,

Mohamed

Hi,

Thank you for the log.

The assert at line 349 usually happens when the processing for current frame has not completed before the next frame is starting.

This may happen if you are running code that is not optimized for speed. There are optimization compiler options that should be set to highest level to avoid this problem.

In your case, on thing that is strange is the "gMrrDSSMCB.stats.chirpIntCounter : 4" Usually this value should be the number of chirps in the frame because the counter is incremented for every chirp interrupt.

Are you using 4 chirps in the frame.

Another concern are the mailbox errors reported in your log. Do you know where they are coming from?

It is possible that there is some corruption earlier in the code

thank you

Cesar

Hello Cesar,

Cesar said:

 There are optimization compiler options that should be set to highest level to avoid this problem.

What are these compiler options ?

The mailbox error is resolved now but it is not relevant to the issue.

Cesar said:

 Are you using 4 chirps in the frame.

I am using 256 chirps like in the MRR project, sometimes this counter shows 4 and sometimes 265.

Note:

gMrrDSSMCB.stats.chirpEvt : 0  means that processing for the first chirp has not even started.

This means that the second frame has started before even the first chirp was available.

In other words, gMrrDSSMCB.stats.frameStartEvt is flaged before gMrrDSSMCB.chirpProcToken.

Regards,

Mohamed

Hi,

Here is some information about changing the optimization level of a file.

In CCS,

1) Right click on a file name and select "Properties"

2) Select "Optimization level": off, 0,1,2,3 (3 is the highest)

3) Select "Apply and Close"

4) Rebuild the project

In your case, this may not help since I think that this Assert is generated because the interrupts are not correct.

Did you try to place a breakpoint on the fft chirp processing to see if that function is reached?

\labs\lab0007_medium_range_radar\src\dss\dss_data_path.c

In MmwDemo_interChirpProcessing(), DSP_fft16x16()

When setting a breakpoint you may need to reduce the optimization level. Click on the code line, then right click and select "Hardware breakpoint"

Thank you

Cesar

Hi Cesar,

Thanks for the clarification.

No it never reachs the MmwDemo_interChirpProcessing() function.

I increment   the variable  gMrrDSSMCB.stats.chirpEvt before processing the frame and it is always zero. Also never reachs the breakpoint there.

It seems that the chirp available interrupt is too late or the frame start signal is too fast.

Regards,

Mohamed

Could you please describes the steps you have taken to implement this code?

I think there are some issues with the interrupt management

Have you tried to run the 1642 code provided in "labs\lab0006_nonos_oob_16xx" on the awr1843?

If you have not I recommend you run it and check the interrupts using CCS.

Are you familiar with debugging code using CCS? There may be need to step through the code

In order to be able to set breakpoints you will need to change the optimization level of the file where you want to set he breakpoint. We discussed this in a previous post

thank you

cesar

Thank you

Cesar

Hello Cesar,

Here are the steps from DSS:

1- Initialize the SOC configurations.

2- Setup the default mailbox configuration.

3- Set the DSS Link State to 1.

4- Create Event to handle mmwave callback and system datapath events

5- MmwaveLink_initLink (RL_AR_DEVICETYPE_18XX, RL_PLATFORM_DSS, &MmwaDemo_asyncEventHandler))

6- Initialize entire data path object to a known state.

7- Initialize the ADC Buffer.

8- Register interrupts

9- Datapath configuration for both subframes

10- Open , LDO , chirp ,profile and advanced frame configuration same like MRR.

11- start .

MSS is only used to log the data through UART.

Thank you,

I was trying to understand if you started with the AWR1642 nonOS demo and ported it to SDK 3.x first.

In the previous post you mentioned that the code never reaches the MmwDemo_interChirpProcessing() function. And the stats showed that several chir Int occured.

gMrrDSSMCB.stats.frameStartIntCounter:1 
gMrrDSSMCB.stats.frameStartEvt :1 
gMrrDSSMCB.stats.chirpEvt : 0 
gMrrDSSMCB.stats.chirpIntCounter : 4 
gMrrDSSMCB.chirpProcToken: 1 '\x01'

Could you set a breakpoint inside the interrupt handler and step through the code to see if the code enters the MmwDemo_interChirpProcessing() function?

After enabling the interrupts the correct order of interrupts would be

1) Frame Interrupt

2) Chirp_1 Interrupt

3) Chirp_2 Interrupt

....

Thank you

Cesar