IWR1642BOOST: People count example does not start due to com ports issue

Thanks for getting back to me. I still have the problem and started learning Matlab to be able to debug it. Somebody's help would be great.

Thank you.

Please see attached

OK, so any hint on what I can do with the config to fix it? If you have a debug version of the comport driver/emulator happy to run it for you to get to the bottom of this.

Kim,

Any progress? Any idea where the problem may be? Could help if you gave me a bit of a run down on all the software components involved.

Justin, yes I have been able to run the out of the box demo. However there is a problem I can use the ti cloud agent in administrator mode only. As soon as I am a user keeps asking me to install it. I have reported the problem under the following link

http://e2e.ti.com/support/sensor/mmwave_sensors/f/1023/p/706889/2605953#2605953

Obviously Uniflash and code composer studio connect to the unit successfully. It is the only device connected.

Hi Justin,

I believe I have an answer. I was running the code in debug mode from Code Composer. The composer obviously takes over the emulator's com ports. This points to a fundamental problem with the development environment. How do you develop/modify an application that needs to interact with a desktop client as all your examples are?

I think your emulator needs to provide separate ports to access jtag port for debug purposes. Is there an option to do that?

Hi Adrian,

This is not the issue. I run the code in development mode constantly with the GUI, and do not have connection issues.  Have you been able to connect when running the precompiled software after loading with Uniflash?

Regards,

Justin

Justin,

The problem was with an ES1.0 board as described at the beginning of the thread I run industrial toolbox 2.3 with sdk 1.2 CCS 7. In the mean time I ordered a ES2.0 board which arrived. The com ports do connect however the application does not run. Please see two inserted screen dumps:

1. the debug output from the radar board

2. the console screen from the matlab application

The config file had the correct value but I had to choose the "Use File" option because don't know which default file is used. I had a config file in the same directory with the exe which was the current working directory.

However I encountered new problems.

1. If I don't power cycle the board from one session to the next I get the following error when loading the mss binary after connecting the target:

The main problem is that when I successfully start everything: reboot board, connect target, load software, start the visualizer and use the config file I don't get any detection. Please see screen dump

Hi Adrian,

This demo filters out all still objects, so if you point it somewhere where nothing is moving, you will not get any detection points. Furthermore, please make sure you power cycle the device before loading a new configuration to ensure that the demo functions properly. 

Regards,

Justin

Justin,

I actually move the board (rotate it) or shake my hand or move myself in front of the radar. it would probably help if you elaborated a bit on each parameter that is involved in filtering out static objects, Probably min speed, time it needs to be moving for, size etc so I can experiment with them. May be beneficial to have that in the user manual or maybe already there and I missed the explanation.

As I have the same problem with Ellie for my ES1 board I will wait for a resoulution on that one rather than continuing it in this thread. I am using industrial toolbox 2.3.0 with CCS 7 and SDK 1.2.0.(0?).5 on a completly different computer with the ES1 system. However if there is anything you want me to test to help I am more than happy to though at this stage I did break my USB connector and will have to res-solder.

Thank you for your support, much appreciated,

Adrian

Hi Adrian,

There are Asserts in the dss_main.c that are triggered when the device takes too long to process a chirp or frame. Anytime we stop at a breakpoint, the device will take too long to process the frame, and these asserts will be triggered.  Removing the asserts, or commenting them out, will not break the demo (if you are using the default configs), and will allow you to step through the program. You can find these at dss_main.c line 317 and line 288. You will also see a line number appear in the console when an assert is triggered.

Please remove these asserts and try the debug steps again.  If possible, can you send me console output from matlab when the configuration is sent?

Thank you,

Justin

Hi,

I am using the default config file I found in the Industrial Toolbox 2.5.0. If I use the default settings without selecting a fileI get the high power mode which is one of the first faults you identified. So I have selected the default file. I also watched a webminar mentioning the four values that can be used for tuning and they said that on the forum somewhere there is an explanation of how they are used. Attached is the default.cfg file I am using.

asserts,

maybe we are not using the same main_dss file. I suspect the asserts you are referring to are at lines 188 and 212 as in the following two files attacted. I have also attached a dump of the lines 280 to 320 so you can see what it is there. Instead of the asserts I suspect the system should just wait for mss to finish the process even if it means it skips some frames. Otherwise it corrupts memory or at least this is what I think.

Thank you for your support and apologies if my problems look simple for you but it is really hard when you are new to everything and nothing works. When things work you just concentrate on a small area of interest which you learn and understand and slowly solowly you expend your knowledge.

Hi Adrian,

I believe I gave you the wrong line numbers, but it looks like you found the right lines.   We have chosen to add the asserts because we do not want to run a configuration that takes too long to process - we do not want to miss a chirp, otherwise our velocity calculation will be incorrect.   In the case that you are running in debug mode and sit at a specific line, only the ADC buffer will be overwritten, so you are safe to step through the code.

I am worried that your BSS may not be running properly - understanding if the device is receiving the chirp interrupt will be helpful to me.  Here is a quick basic flow of the software:

1) BSS generates chirp data, places in ADC buffer

2) DSS reads from ADC buffer after each chirp and puts this 1D FFT data in a different buffer.

3) DSS processes all 1D FFT data after the frame is complete. This results in detection points, which the device will send to the MSS

4) MSS receives points from DSS, runs points through tracker

5) Points and tracks are sent over UART by MSS.

We are trying to find where this is flow is failing. Step 5 is not sending anything, because there is nothing to send.  These are the points I have asked you to put breakpoints at.  See if you can identify  the point will data stops flowing.

There is another thread here that seems to have a similar issue, which may provide some insight to you.

Regards,

Justin

Hi Adrian,

I have been able to reproduce your issue by changing the compiler I am using for the c6000. Please go into the DSS project in CCS and check the compiler version: Right click pplcount_dss_16xx->properties->General, then you will see the Compiler version in the bottom half of the screen.  This should be compiler version TI v7.4.16.  If it is not, you can find the download link here in the developer's guide section.

Regards,

Justin