Isolating a DCA1000EVM Raw-ADC Capture Failure by Data Path

Missing raw data and board heating

I connected a DCA1000EVM to collect raw ADC samples from the IWR6843. Wireshark showed short control UDP datagrams between the PC and the board, but the raw capture log counted zero received packets and the board also heated up. Changing code first would have mixed configuration faults with physical faults. I preserved the observed state, then traced the sample path separately from the path that brings the devices into capture mode.

Two byte-identical duplicate files are shown once each; all 36 distinct debugging screens are placed directly in the staged narrative below. Each screen opens at full size when selected.

IWR6843ISK mounted on a DCA1000EVM with power, USB, and board-to-board connections — The IWR6843ISK, DCA1000EVM, power, USB, and inter-board connections in one view.

Separating the data path from the control path

Using TI’s raw-mode architecture, I mapped the sample path as IWR6843 ADC → LVDS → DCA1000 FPGA → DDR3L/packet path → Ethernet → PC. A different sequence selects power and operating mode, establishes FTDI, RS232, and SPI connectivity, resets and configures the devices, and starts capture. Splitting one symptom into these two paths produced concrete observation points.

Control UART and raw LVDS paths from a radar EVM through DCA1000 to a host PC — Control traffic and raw LVDS-to-Ethernet samples do not fail at the same boundary.

TI guide excerpt showing the stacked DCA1000EVM setup and S1 switch settings — An official-guide excerpt used only to cross-check operating mode and S1 switch positions, shown as source material rather than authored work.

Data path   : IWR6843 raw ADC -> LVDS -> FPGA/buffer -> Ethernet -> PC
Control path: power/mode -> FTDI/RS232/SPI -> reset/config -> capture start

Using the GUI as the first observation point

In mmWave Studio, FTDI appeared as Connected, yet the detected-device count was zero and both RS232 and SPI appeared as Disconnected. RF Power-up also produced ReadRegister failed with error -11. PC-side FTDI enumeration was therefore not equivalent to a working radar-control path.

Error        : no raw ADC stream, device count 0, ReadRegister -11
Cause scope  : mode/configuration, interconnect, power, LVDS/FPGA/buffer, Ethernet
Verification : GUI state, LED labels, connector/solder inspection, oscilloscope probes

Radar Studio startup dialog showing an RstdXml assembly-load exception 0x800711C7 — The RstdXml dependency-load failure was recorded as a separate software-environment issue before mmWave Studio operation.

mmWave Studio output reporting a missing MATLAB Runtime Engine and mclmcrrt8_5_1 DLL load failure — The full log shows a missing MATLAB runtime and DLL load failure blocking post-processing initialization.

mmWave Studio showing FTDI connected while RS232 and SPI are disconnected and zero devices are detected — The first observation separating FTDI enumeration from an operational radar-control link.

Windows Device Manager showing Silicon Labs CP2105 Enhanced COM7 and Standard COM8 — Device Manager distinguished CP2105 Enhanced COM7 from Standard COM8 and preserved the actual port enumeration state.

mmWave Studio connection tab with COM7 at 115200 baud while zero devices and disconnected RS232 and SPI are shown — Device detection remained at zero even with the COM port and baud setting visible.

RFDataCaptureCard configured with system IP 192.168.33.30, FPGA IP 192.168.33.180, config port 4096, and record port 4098 — Configuration evidence showing Raw, LVDS, Ethernet Stream, IP, port, and packet-delay settings together.

mmWave Studio RF Power-up screen showing ReadRegister failed with error -11 — RF Power-up still stopped at ReadRegister -11 after firmware paths were selected.

Full mmWave Studio log showing DCA1000 timeout, invalid lvdsMode, config-port bind, board-control, firmware-download, and ReadRegister errors — One run preserved the full failure order: invalid lvdsMode -4016, config-port 10048 bind -4051, BoardControl protocol, firmware download -1, and ReadRegister -11.

mmWave Studio output showing MATLAB Engine initialization failure and a runtime DLL load error — The host software runtime was recorded as a failure boundary independent of hardware communication.

Separating control UDP from raw data in Wireshark

I assigned 192.168.33.30 to the PC and 192.168.33.180 to the DCA1000EVM, then inspected udp.port == 4096 || udp.port == 4098. The capture repeatedly showed short 8- and 14-byte datagrams from the PC to configuration port 4096. This proves that control datagrams left the PC NIC; it does not prove that LVDS samples returned as Ethernet data packets.

Initial Wireshark capture showing only SSDP multicast packets from the PC — The first capture contained PC background SSDP rather than DCA raw traffic.

Wireshark with a UDP 4096 or 4098 filter and an empty packet list — No packet was visible in an early filter restricted to the DCA configuration and data ports.

Repeated Wireshark capture still showing SSDP multicast from 192.168.33.30 — With the filter removed, repeated host multicast traffic remained the visible activity.

Wireshark filtered to short UDP control datagrams from 192.168.33.30 to port 4096 on 192.168.33.180 — Short 8- and 14-byte configuration datagrams later appeared; they were kept separate from raw-ADC reception.

Wireshark showing no result for UDP 4096 frames longer than 200 bytes — A longer-frame condition returned no result, separating short control datagrams from data payloads.

Wireshark showing bidirectional UDP traffic on ports 4096 and 1024 between the PC and DCA1000EVM — Requests and short responses established partial reachability of the Ethernet control path.

Wireshark detail of an 8-byte datagram returned from DCA port 1024 to PC port 4096 — Source, destination, and payload were inspected for a short 8-byte response from the DCA side.

Wireshark filtering short response packets by DCA source IP and UDP ports 4098 or 4096 — Source IP and ports were combined to separate DCA responses from host background traffic.

Wireshark showing only SSDP packets under a broad UDP filter — At another capture point, even the broad UDP filter showed only SSDP, so conditions were compared across runs.

Wireshark showing ARP resolution followed by short UDP exchanges between the PC and DCA1000EVM — ARP resolution followed by bidirectional UDP preserved evidence of IP and MAC reachability.

Repeated Wireshark run showing bidirectional DCA UDP and ARP followed by SSDP traffic — Another run reproduced short UDP and ARP traffic, but no later raw-data packets were identified.

Windows Ethernet adapter configured manually as 192.168.33.30 with subnet mask 255.255.255.0 — The PC NIC was fixed at 192.168.33.30/24 to reproduce the DCA1000 subnet condition.

Windows ipconfig output confirming Ethernet IPv4 192.168.33.30 and subnet mask 255.255.255.0 — The applied adapter address was cross-checked in ipconfig rather than relying only on the GUI entry.

Long Wireshark capture showing SSDP and a Windows browser announcement — OS background packets in a long capture were classified so they would not be mistaken for DCA traffic.

Wireshark capture containing short DCA UDP together with SSDP and a Windows browser announcement — Protocol and address fields separated the DCA control response from unrelated background traffic in the same capture.

Isolating firmware programming with UniFlash

Using UniFlash on COM7, I erased the IWR6843 SFLASH and downloaded META_IMAGE1. The console retained Erase storage completed successfully, downloaded successfully to SFLASH, and Program Load completed successfully. I therefore recorded firmware programming as a successful stage. That result does not prove the later RF configuration, LVDS enable, DCA1000 packetization, or raw capture.

MATLAB hardware setup showing a failure to program the mmWave radar board during Flash Binary — Flashing failed in the setup wizard with COM7 and COM8 selected, prompting checks of mode, port ownership, reset, and USB.

UniFlash IWR6843 program page before selecting a meta-image slot — The starting state used to confirm the IWR6843 serial connection and flash-image fields.

UniFlash console confirming IWR6843 SFLASH erase, meta-image download, and program-load completion — Successful erase, download, and program load separated firmware programming from the later streaming stages.

Checking the UART CLI in Tera Term

Tera Term on COM7 displayed the mmwDemo:/> prompt, while several inputs were followed by is not recognized as a CLI command. The screen therefore preserves two separate observations: the firmware prompt was readable over the serial port, but those inputs were not accepted as valid commands. Command spelling, line ending, the running image, and CLI state remained candidates; the screen does not identify one cause by itself.

Tera Term serial-port settings showing COM7, 115200 baud, 8N1, no flow control, and the CP2105 Enhanced port — Before inspecting the CLI, the selected CP2105 Enhanced port and COM7, 115200, 8N1, no-flow-control settings were retained on screen.

Tera Term on COM7 showing the mmwDemo prompt and repeated CLI command rejection messages — UART prompt reachability and command rejection were recorded as different observations.

Tera Term showing a rejected garbled input followed by the mmwDemo prompt — An additional reproduction where the prompt remained available but the input was not parsed as a valid command.

Tera Term terminal filled with a continuous stream of B and R characters — The repeated character stream was retained as an observation consistent with baud, port, or image mismatch without assigning one cause.

Using the capture log as the stop condition

The record directory contained configuration and log files, but no raw .bin file. The log reported Number of received packets - 0, first and last packet IDs of 0, and a duration of -2 seconds. I used this direct outcome to avoid treating Ethernet-adapter visibility or control traffic as a successful raw capture.

MATLAB dca1000FileReader error reporting that no binary files were found at the specified location — The error redirected the check from the reader to whether capture output had been created at all.

MATLAB error showing that recordLocation was not recognized — A host-side script issue from mixing an example variable with an actual object property was recorded separately.

MATLAB error showing that configureRadar was not recognized — The screen captured a software boundary between the support-package example and the available MATLAB path or API.

DCA1000 raw-capture log showing zero received packets — Configuration and log files existed, but zero received packets left the raw capture unsuccessful.

Using LEDs and power as hardware observation points

Several status LEDs were illuminated simultaneously in a hardware photograph. I used their labels to choose the next measurement points, but did not infer a failed FPGA, DDR device, or LVDS interface from a single LED state. Board heating also lacked a measured location and temperature, so it was treated as a symptom rather than proof of a particular failed component.

DCA1000EVM status LEDs near the power, FPGA, DDR, and LVDS labels during inspection — An enlarged view of LED labels and switch positions used to plan the next checks.

Narrowing the hardware path

I checked the 5-V input, board power state, and when heating appeared.
I revisited DIP-switch positions, operating mode, reset, configuration, and capture-start order.
I inspected board-to-board connectors, cable contact, and solder joints, then reworked suspicious joints.
I probed accessible power and signal points with an oscilloscope.
I compared the PC’s static IP, UDP control traffic, and zero-packet capture log independently of the physical checks.

The purpose was to verify whether each stage produced the condition required by the next stage before replacing components or making broad software changes.

Recording the stop decision and open scope

Ethernet raw-ADC streaming was not restored after solder rework and repeated configuration. Control UDP, successful flashing, and a UART prompt were each observed, but I could not establish whether the FPGA buffer was receiving valid samples or identify a failed component. I stopped using this capture path and retained the observed error states, probe locations, and unanswered boundaries for a future board-level investigation.

The raw-ADC capture failure is separate from the TI SDK-based 3D People Tracking run. The latter received processed point-cloud and target data over dual UART; it is not evidence that the DCA1000 LVDS-to-Ethernet path recovered.

Debugging competency carried forward

The central lesson was not to assign a physical cause to a missing-data symptom too early. I turned flash programming, the UART CLI, UDP control, the raw packet count, power and heat, connectors and solder, and LVDS buffering into staged observation points. I also kept confirmed states, plausible causes, and unmeasured areas distinct through the stop decision. The same approach applies to radar and autonomous-sensor validation, embedded-hardware bring-up, production failure analysis, and advanced-quality investigations.