DCA1000EVM: Long time reliability

Hi Expert,

We have been running DCA1000 with AWR1243BOOST to capture data but consistently have some reliability issues.

As the DCA remains powered on for periods of time exceeding 3 hours periodically receiving LVDS data, it consistently becomes unresponsive, as if it were internally in an incorrect state. When the DCA is in its normal state, issued commands return valid response messages and appear to take the appropriate actions. We have conducted a series of experiments, attempting to find a usage scenario and configuration which allows the DCA to remain in its good state after being powered on. 

When the DCA is in its bad state it becomes completely unresponsive to issued DCA commands (e.g. no confirmation response). Additionally, in its good state, an ARP ping (using nmap) is able to detect that the DCA host is up, however when the DCA is in its unresponsive state this ping test fails. It appears as if the unit has completely died. 

A simple power cycle is able to recover the DCA into a good state, however it is neither desired nor practical to have this behavior as it limits the scope of applications for which we can use the device. 

The DCA dip switch configuration is: LVDS_CAPT, ETH_STREAM, 1243_MODE, RAW_MODE, SW_CONFIG

Bit config: 16BIT_ON, 12BIT_OFF, 14BIT_OFF

FPGA_CFG2 (from 1-4): OFF, ON, OFF, ON

We have been conducting our tests with 8MB LVDS frames (from an AWR1243BOOST) at frame rates of 2 FPS and 5 FPS. We configured packet delays to both 15 us and 25 us. When the DCA is left to capture indefinitely it consistently becomes unresponsive after 3-5 hours. We also have conducted numerous experiments with running the DCA for fixed periods of time with some rest in between. Before we begin streaming LVDS data we always issue a DCA start command. We have also tried issuing the Stop command after the LVDS stream has finished as well as omitting it. When a Stop command is issued, the first packet number after a Start is always 1 (i.e. no packet number overflow on small fixed captures).

Some of the time interval and frame rate combinations we have tried include (not-exhaustive):

We really would appreciate any insight or help we could get into determining the cause of this unresponsive behavior and how we can overcome it without a power cycle.

Thank you!