CCS/IWR6843ISK: 68xx People Counting demo GUI

Hi,

now the run ends with

Undefined variable "matlab" or class "matlab.webcam.internal.Utility.enumerateWebcams".

Error in webcamlist (line 25)


Error in setup>popupWebcam_CreateFcn (line 612)


Error in gui_mainfcn (line 95)


Error in setup (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)setup('popupWebcam_CreateFcn',hObject,eventdata,guidata(hObject))


hObject =

  UIControl (editUART) with properties:

              Style: 'edit'
             String: 'COM8'
    BackgroundColor: [1 1 1]
           Callback: [function_handle]
              Value: 0
           Position: [0.3046 0.7262 0.2831 0.2857]
              Units: 'normalized'

  Use GET to show all properties

Opening configuration file mmw_pplcount_demo_default.cfg ...
trackingCfg specifies -6.981317e-01.
GUI specifies 0. 90 will be used for azimuth in cfg.
Sending configuration from mmw_pplcount_demo_default.cfg file to IWR16xx ...

   Serial Port Object : Serial-COM8

   Communication Settings
      Port:               COM8
      BaudRate:           115200
      Terminator:         'LF'

   Communication State
      Status:             open
      RecordStatus:       off

   Read/Write State
      TransferStatus:     idle
      BytesAvailable:     0
      ValuesReceived:     0
      ValuesSent:         0


flushCfg
dfeDataOutputMode 1
channelCfg 15 5 0
adcCfg 2 1
adcbufCfg 0 1 1 1
profileCfg 0 60.6 30 10 62 0 0 53 1 128 2500 0 0 30
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 4
frameCfg 0 1 128 0 50 1 0
lowPower 0 1
guiMonitor 1 1 0 0
cfarCfg 6 4 4 4 4 16 16 4 4 50 62 0
doaCfg 600 1875 30 1 1 0
SceneryParam -6 6 0.5 6
GatingParam 4 3 2 0
StateParam 10 5 100 100 5
AllocationParam 250 250 0.25 10 1 2
AccelerationParam 1 1 1
trackingCfg 1 2 250 20 52 82 50 90
sensorStart
Error 0x16 at ../src/termios.c(512): The device does not recognize the command.Error 0x16 at ../src/termios.c(512): The device does not recognize the command.Error 0x16 at ../src/termios.c(512):

repeating the error for a while and then terminating. Any ideas what's happening?

Best Regards,

Marko

Hi Marko,

Termios.c is the generic library for serial communication. Please ensure that all of your drivers are up to date, as this error is due to the serial port on your PC not behaving properly.

Regards,
Justin

Hi Justin,

I had an opportunity to make a fresh install on an another computer. So, all drivers should be up to date on the computer end. The results are still the same.

Best regards,

Marko

Hi,

it seems that there is something wrong with the serial connection. With debug mode, I get

DEBUGSSM_0: Error connecting to the target: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed. The cause may be one or more of: no XDS110 is connected, invalid firmware update, invalid XDS110 serial number, or faulty USB cable. The firmware and serial number may be updated using the xdsdfu utility found in the .../ccs_base/common/uscif/xds110 directory of your installation. View the ReadMe.txt file there for instructions. (Emulation package 8.0.903.4)
C674X_0: GEL: File: C:\Users\marko\workspace_v8\PC_mss_68xx\Debug\PC_mss_68xx.xer4f Does not match the target type, not loaded.
IcePick_M_0: Error: (Error -261 @ 0xFFFFFEFB) Invalid response was received from the XDS110. (Emulation package 8.0.903.4)
CS_DAP_0: Error: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 8.0.903.4)
Cortex_R4_0: Error: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 8.0.903.4)
CS_DAP_0: Unable to determine target status after 20 attempts
CS_DAP_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
Cortex_R4_0: Unable to determine target status after 20 attempts
Cortex_R4_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Any ideas how to proceed?

Best regards,

Marko Leppänen

Hi Marko,

A few steps to try:

1. If you haven't done so already, restart Code Composer Studio and attempt to connect again.
2. Ensure USB is connected to XDS110 USB (lower micro usb slot on carrier card), Ensure switches are in correct position (see People Counting User's guide), and ensure the SOP pins are in functional mode.
3. Please try to update the XDS firmware. 
   1. Go to this location: C:\ti\ccsv8\ccs_base\common\uscif\xds110
   2. XDS110SupportReadMe.pdf has the instructions to reload the firmware
   3. Reload firmware and try to run debug mode again

After updating the XDS110 firmware, please let me know if you continue to encounter issues.

Regards,

Justin

Hi,

I restarted the CSS studio, and rechecked the jumper and DIPs, and everything should be in order.

I also updated the firmware without any issues.

PS C:\ti\ccsv8\ccs_base\common\uscif\xds110> .\xdsdfu.exe -m

USB Device Firmware Upgrade Utility

Copyright (c) 2008-2018 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported XDS110 devices...

<<<< Device 0 >>>>

VID: 0x0451    PID: 0xbef3

Device Name:   XDS110 Embed with CMSIS-DAP

Version:       2.3.0.16

Manufacturer:  Texas Instruments

Serial Num:    R0081038

Mode:          Runtime

Configuration: Standard

Switching device into DFU mode.

PS C:\ti\ccsv8\ccs_base\common\uscif\xds110> .\xdsdfu.exe -f .\firmware.bin -r

USB Device Firmware Upgrade Utility

Copyright (c) 2008-2018 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported XDS110 devices...

Downloading .\firmware.bin to device...

However, the original problem persists with the serial connection.

Best regards,

Marko

Hi Marko,

Can you check your power supply? You should be using 5V 3A. It is possible for the OOB demo to run with lower power draw than the people counting demo. In this case you might see that the OOB demo works, while the People Counting demo does not work.

Regards,
Justin

Hi Marko,

Can you reconfirm that the OOB demo is working? I want to ensure the board has not been damaged in the course of the debug process.

Regards,
Justin

Hi,

we use a quite precise laboratory power supply with 0-30V range, putting out 3A at maximum. According to the power supply, the board draws at 5.0 Volts 0.51 amps when both images of the pplcounting demo are running in the debug mode. When I power cycle the board, the current is @5.0V 0.45 amps to 0.48 amps in idle.

The OOB demo still works, drawing 0.52 amps at 5.0V.

Best regards,
Marko

Hi,

now the story is getting really weird. To make sure that the power supply isn't the issue, we tried another one. On this supply, I wasn't able to start the DSS in the debugger at all, as the Code Composer studio was complaining about the processor being held in a reset state. The MSS started all right. I thought that this might be a problem with the current supply, although I got similar readings (about 0.5 amps at 5 volts) as before on this power supply too.

I got back to the original power supply and flashed the OOB demo again. It froze after running for a minute or so. This was behavior I had never encountered before. I reflashed the board and noticed that the board had started to make a faint knocking noise. Now, for the second time the OOB demo started to run as expected and did not freeze, so I flashed the pplcount demo. Now it worked too. The GUI gets to the second view with the people counter and the point cloud visualization. The power supply now gives about 0.7 amps while the software is running and I can get presumably right looking results on the GUI. The board still makes the same faint noise.

Absolutely no software changes were made during this, except the flashing of the board with different binaries (OOB demo and the debug firmware), which I have done numerous times before this. Can it be that there has been some small electrical problem on the board that now got (at least temporarily) fixed? A cold joint perhaps?

Best regards,

Marko

Hi Marko,

First I want to address the knocking sound - our EVMs will make a fainting beeping sound when actively chirping - could this be the noise you are hearing?

As for the power supply, what is the current limit you have set on the supplies you were using? Typically, current draw looks something like this for a device running People Counting:

So you can see that peak current will be about 750 mA.  Please check the first power supply to ensure that you were not limiting the current.

Regards,

Justin

Hi,

I wouldn't describe the sound as a beep, unless a really muffled one. It's really low volume, but I'll try to record it.

Both power supplies are rated up to three amps, hi quality laboratory workbench power supplies. 750 mA consumption is about the right now. The ammeter on the original power supply shows now 0.7 amps during operation. Before this sound appeared, both power supplies showed a bit over half an ampere.

Best regards,
Marko

Hi Marko,

To confirm, both demos are working now. This happened after the OOB demo failed. You then re-flashed the board with OOB, which worked, and People Counting, which worked. You have made no changes to the physical setup, or the software you used to flash the device.

Thanks,
Justin

Hi Justin,

yes, you are correct. So, to summarize:

First, only thing that was working was the OOB demo. Pplcounting was still not working due communication errors. After that, I tried the other power, and with that one, either of the demos did not work. Then I returned back to my own workbench, and tried both demos, and they both worked. All the time, the same computer was in use and, naturally, the same software. The only physical change was detaching the device in order to carry it to the other workbench and back.

Best Regards,

Marko