This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DCA1000EVM: Timeout after ~4.5h of operation

Part Number: DCA1000EVM
Other Parts Discussed in Thread: IWR6843ISK

Description

After approx 4h26m the device becomes completely unresponsive. No error code beyond timeout on udp received packages is observable. The status LEDs don't signal an error state either.

The error was observed using the DCA100EVM_CLI while recording LVDS data, but also while sitting idle.

After I first ran into this issue, I did a reimplementation of the DCA100EVM_CLI to get a understanding of the communication and possibly observe the udp communication in detail. The reimplementation runs into exactly the same issue, so I can rule out the DCA100EVM_CLI as source of the problem.

Steps to reproduce

  • Connect DCA1000EVM to PC and power on.
  • wait for 4.5h
  • query system status or start data transmission to observe

What doesn't work

  • resetting the FPGA using the 'reset_fpga' has no effect on the apparent freeze
  • 'reset_ar_device' has no effect either

Possible solution

Currently the only solution I found is disconnecting and reconnecting the DCA from power. I found, that the GPIO_PHY_RESET pin is pulled down during FPGA startup, but not after 'fpga_reset' using the cli, so I assume this command doesn't issue a complete reset of the DCA1000EVM.

Is there an undocumented command code for completely resetting the DCA1000EVM or can this lockup be prevented by any other means except turning it off and on again?

  • Hi, there:

    Give me sometime to duplicate this problem.  Do you mean just connect DCA1000/EVM to PC and power on, after 4.5 hours, DCA1000 will stop responding to  any DCA1000 CLI command?  Can you check whether OOB demo binary still alive on the EVM after 4.5 hours?

    Best,

    Zigang

  • Hi,

    Thanks for your reply. The OOB binary demo is still alive, when the DCA locks up. However, the DCA1000 freezes whether the IWR6843ISK is connected or not.

    Regards,

    Christian

  • I did another test yesterday and noticed, that the DATA_TRAN_PRG LED stopped blinking and stayed on, when a data transmission was active while waiting for the device lockup. Though, I can't tell, if this is consistent.

  • HI, Christian:

    All the command should be documented under C:\ti\mmwave_studio_02_01_01_00\mmWaveStudio\ReferenceCode\DCA1000\Docs.  Let me know whether these documents are helpful.

    Best,

    Zigang

  • Hi Zigang,

    the documented commands didn't help.

    However, I noticed some changes in the required current during operation, as it's measured by the power supply:

    power on at 11:45:

    • initial power on, reset_ar + reset_fpga 462mA
      setup + start iwr 468.2mA
      config_fpga 468.7 mA
      config_record | 469
      start_record | 483...484 mA

    14:07 still recording: 500mA
    15:48 still recording: 505mA
    16:23 system locked up470mA
    16:23:

    • powercylle 476mA
      reset_fpga 476mA
      config_fpga 476mA
      config_record 476mA
      start_record 489mA

    As I understand, the observed increase in power consumption during operation might be caused by a raise in temperature on the device. The drop in electrical current to 470mA indicates, that some internal routine, that is active after initialization, stopped.

    Regards,

    Christian

  • HI, Christian:

    I tried on my side,  I connected and powered on the system, then leave it there for 5 hours, and then come back to run the capture routine.  And it works for me.  My procedure is as follows:

    1) DCA1000EVM_CLI_Control.exe reset_ar_device datacard_config.json

    2) DCA1000EVM_CLI_Control.exe fpga datacard_config.json

    3) DCA1000EVM_CLI_Control.exe record datacard_config.json

    4) configure radar device 

    5) DCA1000EVM_CLI_Control.exe start_record datacard_config.json

    6) sending "sensorStart" to radar device

    7) DCA1000EVM_CLI_Control.exe stop_record datacard_config.json

    Can you check any difference on your side?

    Best,

    Zigang

  • Hi Zigang,

    I cannot see any significant difference in your procedure. I get an unresponsive DCA1000EVM consistently 16400 to 16750 seconds after powering on. The timing deviation shouldn't be caused by measurement error, as I detirmined the time of unresponsiveness by checking the power supply log.

    Power supply log

    Maybe we use different software versions/settings?

    My Firmware versions are: 

    • DCA1000EVM: 2.8 [Recording]
    • IWR6843ISK: mmWave: xWR68xx MMW Demo 03.05.00.04

    The DCA1000EVM is setup as follows:

    S1: 

    1. Pin 1 (Left)
    2. Pin 7 (Right, FPGA_CFG2)
    3. Pin 3 (Left)
    4. Pin 5 (Right, FPGA_CFG0)

    SW1: 16BIT_ON (14BIT_OFF, 12BIT_OFF)

    SW2: 

    1. LVDS_CAPTURE
    2. ETH_STREAM
    3. AR1642_MODE
    4. RAW_MODE
    5. CONFIG_VIA_SW
    6. FPGA_ethernet_settings
    7. off
    8. off

    As I understand, the switch setting SW2.5 (Config_VIA_SW) leads to the switch settings SW1 and SW2.[1...4] being ignored.

    The datacard_config.json is set as follows:

    {
      "DCA1000Config": {
        "dataLoggingMode": "multi",
        "dataTransferMode": "LVDSCapture",
        "dataCaptureMode": "ethernetStream",
    	"lvdsMode": 2,
    	"dataFormatMode": 3,
        "packetDelay_us": 25,
    	"ethernetConfig": {
    		"DCA1000IPAddress": "192.168.33.180",
    		"DCA1000ConfigPort": 4096,
    		"DCA1000DataPort": 4098
    	},
    	"ethernetConfigUpdate": {
    		"systemIPAddress": "192.168.33.30",
    		"DCA1000IPAddress": "192.168.33.180",
    		"DCA1000MACAddress": "10.00.00.e9.82.49",
    		"DCA1000ConfigPort": 4096,
    		"DCA1000DataPort": 4098
    	},
    	"captureConfig": {
    		"fileBasePath": "C:\\mySavedData",
    		"filePrefix": "datacard_record",
    		"maxRecFileSize_MB": 1024,
    		"sequenceNumberEnable": 1,
    		"captureStopMode": "infinite",
    		"bytesToCapture": 1025,
    		"durationToCapture_ms": 1000,
    		"framesToCapture": 5
    	},
    	"dataFormatConfig": {
    		"MSBToggle": 0,
    		"reorderEnable": 1,
    		"laneFmtMap": 0,
    		"dataPortConfig": [
    			{
    				"portIdx": 0,
    				"dataType": "complex"
    			},
    			{
    				"portIdx": 1,
    				"dataType": "complex"
    			},
    			{
    				"portIdx": 2,
    				"dataType": "complex"
    			},
    			{
    				"portIdx": 3,
    				"dataType": "complex"
    				},
    			{
    				"portIdx": 4,
    				"dataType": "complex"
    			}
    		]
    	}
    }
    }
    

    Regards,

    Christain

    Edit: Completed/corrected details on time delay.

  • Here is a picture of my setup using CLI utility.

    Best,

    Zigang

  • Since I have not received any update for two weeks, I am closing this thread.

    Best,

    Zigang