AWR6843ISK: AWR6843ISK: AWR6843ISK +mmwave booster debug mode (breakpoints randomly moves)

Hey Mani,

Thanks for reaching out regarding these issues. I've commented on the following test cases below:

Mani D said:

Test case 1:

As suggested " memory is allocated in the linker.cmd  and with "Optimization level -off on both MSS and DSS,able to  build without any error. but when we try to send configuration Via industrial Visualizer, we are getting the following error :

Could you check the Industrial Visualizer log to see if any error code is being thrown? You can also connect to the device via TeraTerm, send over the configuration, and check for any error messages.

Mani D said:

Test Case 2( No break point set inside the code ): default Optimization level -3 on both MSS and DSS, able to  build without any error. We are able to send configuration Via industrial Visualizer,  but code get stuck like shown in the Below console

Mani D said:

Test Case 3(  break point set inside the code(ref console) ): default Optimization level -3 on both MSS and DSS, able to  build without any error. We are able to send configuration Via industrial Visualizer,  but code get stuck like shown in the Below console and throw error)

For both test case 2 and 3, are you flashing the CCS debug image as described by the following Radar Toolbox documentation? What are the S1 switch settings for your MMWAVEICBOOST and AWR6843ISK?

Regards,

Kristien

Hi kristien,

  thanks for your reply.

Kristien said:

 Could you check the Industrial Visualizer log to see if any error code is being thrown? You can also connect to the device via TeraTerm, send over the configuration, and check for any error messages?

 we have used AWR6843_CPD_w_Classification_visualizer to send configuration file(vod_6843_isk_frontMount_2row.cfg) instead of industrial visualizer and did not set any breakpoint inside the code , we are able to see the real time Point cloud data on Display .

 working case :(screenshots of CCS debug mode console output  and visualizer logs are attached for your reference)

Not working:(but when we keep the break point inside the code with above process, code breaks and  we are getting  the following error/issue and stops,The screenshots of CCS debug mode console output  and visualizer logs are attached for your reference)

Kristien said:

For both test case 2 and 3, are you flashing the CCS debug image as described by the following Radar Toolbox documentation? What are the S1 switch settings for your MMWAVEICBOOST and AWR6843ISK?

Yes,we have done all the setting As per the above linked document referred by you  and sharing the screenshot of switches for your reference.

please kindly check and provide the solution to resolve the issue.

regards,

mani

Hey Mani,

The AWR6843 CPD with Classification demo has some timing constraints that require the processing on the DSP side is finished before the next frame can be started on the ARM side. Therefore, by adding a breakpoint and halting the DSP, this causes the DSP and ARM to desynchronize and the ARM to fail after the first frame. Note: You can still debug the first frame data that was received on the DSP side and step through the entire chain to observe how data is processed, but you won't be able to observe any further frames due to the ARM error or interact with the ARM core.

I will also note that disabling the compiler optimization for the DSP will have a drastic effect on processing speed since DSP code is highly reliant upon compiler optimization. This will likely cause the application to fail after one frame due to the increased processing time violating the timing constraints on the ARM side.

Regards,

Kristien

hi kristien,

thanks for your reply.

if setting breakpoint is causing halting due to synchronization ,then Can i know ,how to log the data or print the variable data's on console without setting break point? .so i will be visualize the data without breaking.

regards,

mani

Hey Mani,

For simple variables that are utilized infrequently during DPC execution, you could print to the debug console using System_printf. For arrays, you could use fwrite to write the data to a binary and then look over the data afterwards. However, there is a chance that adding printouts or writing to a file will violate the timing constraints on the ARM side still. 

You could theoretically comment out the DPC_Objdet_Assert on line 645 which would prevent the ARM core from aborting, though this will introduce unexpected behavior and may inject incorrect data into the processing chain.

Regards,

Kristien