DCA1000EVM 원시 ADC 수집 장애를 경로별로 좁힌 디버깅

원시 데이터 미수신과 보드 발열

IWR6843의 원시 ADC 데이터를 PC로 받기 위해 DCA1000EVM을 연결했다. Wireshark에서는 PC와 보드 사이의 짧은 제어 UDP가 보였지만 raw capture log의 수신 packet은 0이었고, 보드 발열도 함께 나타났다. 이때 코드부터 바꾸면 설정 문제와 하드웨어 문제를 섞어 볼 가능성이 컸다. 먼저 실제 장비 상태를 남기고, 데이터가 지나가는 경로와 장치를 시작시키는 경로를 따로 따라갔다.

이 글에는 제공된 화면 가운데 내용이 완전히 같은 복사본 2장을 한 번씩만 표시하고, 서로 다른 디버깅 화면 36장을 단계별 본문에 모두 배치했다. 각 화면은 누르면 원본 크기로 확대된다.

DCA1000EVM 위에 IWR6843ISK를 연결하고 전원, USB와 보드 간 케이블을 연결한 실험 구성 — IWR6843ISK, DCA1000EVM, 전원·USB·보드 간 연결을 한 화면에서 확인한 구성.

데이터 경로와 제어 경로를 따로 봤다

TI 문서의 raw mode를 기준으로 데이터 경로는 IWR6843 ADC → LVDS → DCA1000 FPGA → DDR3L/packet path → Ethernet → PC로 놓았다. 한편 장치가 이 경로를 열기까지는 전원 선택, switch와 동작 모드, FTDI·RS232·SPI 연결, reset, FPGA configuration과 capture start 순서가 필요하다. 데이터가 안 보인다는 한 증상을 두 경로로 나누니 확인할 지점이 명확해졌다.

Radar EVM의 제어 UART와 원시 LVDS 데이터가 DCA1000과 PC로 이어지는 경로 — 설정이 오가는 제어 경로와 원시 샘플이 이동하는 LVDS·Ethernet 경로는 같은 문제가 아니다.

DCA1000EVM mode의 보드 결합 상태와 S1 switch 설정을 설명하는 TI guide 발췌 화면 — 동작 mode와 S1 switch 위치를 대조한 공식 guide 발췌 화면. 설계 결과물이 아니라 설정 확인 근거로만 사용했다.

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

GUI 상태를 첫 관측점으로 삼았다

mmWave Studio 화면에서는 FTDI가 Connected였지만 장치 검출 수는 0이었고 RS232와 SPI는 Disconnected로 표시됐다. RF Power-up 단계에서 ReadRegister failed with error -11도 확인했다. 즉 PC가 FTDI 장치를 보는 상태와 레이더 제어 통신이 성립한 상태를 같은 것으로 판단할 수 없었다.

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 시작 시 RstdXml assembly load exception 0x800711C7이 표시된 화면 — mmWave Studio 실행 전 단계에서 RstdXml dependency load 실패를 별도 software environment 문제로 기록했다.

mmWave Studio output에서 MATLAB Runtime Engine 미설치와 mclmcrrt8_5_1 DLL load 실패가 출력된 화면 — MATLAB runtime 미설치와 DLL load 실패가 post-processing initialization을 막은 전체 log.

mmWave Studio에서 FTDI는 연결됐지만 RS232와 SPI는 끊기고 device가 0개로 표시된 화면 — FTDI enumeration과 radar control 연결을 같은 성공 상태로 보지 않은 첫 관측.

Windows 장치 관리자에서 Silicon Labs CP2105 Enhanced COM7과 Standard COM8을 확인한 화면 — CP2105의 Enhanced COM7과 Standard COM8을 장치 관리자에서 구분해 실제 포트 열거 상태를 확인했다.

mmWave Studio connection tab에서 COM7과 115200 baud를 선택했지만 device 0개와 RS232 SPI disconnected가 나타난 화면 — COM port와 baud 설정을 화면에 남긴 상태에서도 device detection은 0이었다.

RFDataCaptureCard에서 system IP 192.168.33.30 FPGA IP 192.168.33.180 config port 4096 record port 4098을 설정한 화면 — Raw·LVDS·Ethernet Stream mode와 IP·port·packet delay를 한 화면에서 확인한 설정 근거.

mmWave Studio RF Power-up에서 ReadRegister failed error -11이 발생한 화면 — firmware path를 지정한 뒤에도 RF Power-up이 ReadRegister -11에서 중단된 상태.

mmWave Studio 전체 log에 DCA1000 timeout, invalid lvdsMode, config port bind, board control, firmware download, ReadRegister 오류가 연속 출력된 화면 — 하나의 실행에서 invalid lvdsMode -4016, config port 10048 bind -4051, BoardControl protocol, firmware download -1, ReadRegister -11이 이어진 전체 실패 순서다.

mmWave Studio output에 MATLAB Engine 초기화 실패와 runtime DLL load error가 출력된 화면 — 하드웨어 통신과 별개로 host software runtime도 독립적인 실패 지점임을 확인했다.

Wireshark로 제어 UDP와 원시 데이터를 구분했다

PC의 고정 IP는 192.168.33.30, DCA1000EVM은 192.168.33.180으로 두고 udp.port == 4096 || udp.port == 4098 필터로 패킷을 확인했다. 화면에는 PC에서 보드의 configuration port 4096으로 향하는 길이 8·14 byte의 짧은 UDP가 반복해서 나타났다. 이는 제어 패킷이 NIC를 나갔다는 증거이지, LVDS raw sample이 Ethernet data packet으로 돌아왔다는 증거는 아니다.

Wireshark 첫 capture에서 PC의 SSDP multicast packet만 보인 화면 — 첫 관측에서는 DCA raw traffic이 아니라 PC background SSDP만 잡혔다.

UDP 4096 또는 4098 filter를 적용했지만 packet list가 비어 있는 Wireshark 화면 — DCA configuration·data port만 남긴 초기 filter에서 packet이 보이지 않은 상태.

반복 capture에서도 192.168.33.30의 SSDP multicast만 나타난 Wireshark 화면 — filter를 풀면 반복적으로 보이던 것은 host의 multicast traffic이었다.

192.168.33.30에서 192.168.33.180 UDP 4096으로 향하는 짧은 제어 packet을 필터링한 Wireshark 화면 — 이후 8·14 byte의 configuration UDP는 관측됐다. 이는 raw ADC payload 수신과 구분했다.

UDP 4096과 frame length 200 초과 조건에서 결과가 비어 있는 Wireshark 화면 — 길이가 큰 frame 조건에서는 결과가 없어, 짧은 제어 packet과 data payload를 나눠 봤다.

PC와 DCA1000EVM 사이 UDP 4096과 1024 packet이 양방향으로 나타난 Wireshark 화면 — 요청과 짧은 응답 packet이 함께 보여 Ethernet 제어 경로의 일부 도달성을 확인했다.

192.168.33.180의 UDP 1024에서 PC UDP 4096으로 돌아온 8 byte data를 확대한 Wireshark 화면 — DCA 측에서 돌아온 짧은 8 byte response의 source·destination과 payload를 확인했다.

DCA IP source와 UDP 4098 또는 4096 조건으로 짧은 응답 packet을 모은 Wireshark 화면 — source IP와 port를 함께 제한해 host background traffic과 DCA response를 분리했다.

UDP 전체 filter에서 SSDP packet만 보이는 Wireshark 화면 — 다른 capture 시점에서는 broad UDP filter에도 SSDP만 보여 조건별 재현성을 비교했다.

ARP resolution 뒤 PC와 DCA1000EVM 사이 짧은 UDP packet이 오간 Wireshark 화면 — ARP 응답과 양방향 UDP가 이어져 IP·MAC reachability가 성립한 구간을 남겼다.

DCA1000EVM과 PC 사이 양방향 UDP와 ARP 이후 SSDP가 함께 이어진 Wireshark 재현 화면 — 다른 시점의 재현에서도 짧은 UDP와 ARP는 보였지만 이후 raw data packet은 확인되지 않았다.

Windows Ethernet adapter에 192.168.33.30과 subnet mask 255.255.255.0을 수동 입력한 화면 — PC NIC를 192.168.33.30/24로 고정해 DCA1000 subnet 조건을 재현했다.

Windows ipconfig 결과에서 Ethernet IPv4 192.168.33.30과 subnet mask 255.255.255.0을 확인한 화면 — GUI 입력값뿐 아니라 ipconfig 출력으로 실제 adapter 주소 적용을 다시 확인했다.

장시간 capture에서 SSDP와 Windows browser announcement가 함께 보인 Wireshark 화면 — 장시간 capture에 섞인 OS background packet을 DCA traffic으로 오판하지 않도록 분류했다.

짧은 DCA UDP와 SSDP 및 Windows browser announcement가 한 capture에 함께 있는 Wireshark 화면 — 동일 capture 안에서도 DCA 제어 response와 무관한 background traffic을 protocol·주소로 나눴다.

UniFlash로 펌웨어 기록 단계를 분리했다

UniFlash에서는 COM7의 IWR6843 대상으로 SFLASH erase와 META_IMAGE1 download를 수행했다. console에 Erase storage completed successfully, downloaded successfully to SFLASH, Program Load completed successfully가 남았다. 따라서 펌웨어 기록 단계는 성공한 관측으로 분리했다. 다만 flash 성공은 이후의 RF 설정, LVDS 출력 enable, DCA1000 packetization과 raw capture 성공을 보장하지 않는다.

MATLAB hardware setup의 Flash Binary 단계에서 mmWave radar board program 실패가 표시된 화면 — COM7·COM8을 고른 setup wizard에서는 flash가 실패해 mode·port 점유·reset·USB를 다시 확인했다.

UniFlash IWR6843 program page에서 meta image slot을 선택하기 전 화면 — IWR6843 serial connection과 flash image 입력 위치를 확인한 시작 상태.

UniFlash에서 IWR6843 SFLASH erase와 META IMAGE download 및 Program Load 완료 메시지를 확인한 화면 — erase·download·Program Load success를 확인해 firmware 기록 단계와 이후 streaming 단계를 분리했다.

Tera Term으로 UART CLI 응답을 확인했다

Tera Term의 COM7에는 mmwDemo:/> prompt가 나타났지만 여러 입력 뒤에 is not recognized as a CLI command가 반복됐다. 이는 serial port에서 firmware prompt를 읽을 수 있었다는 관측과, 해당 입력이 유효한 CLI command로 처리되지 않았다는 관측을 동시에 남긴다. command spelling·line ending·실행 image와 CLI state를 후보로 두되, 이 화면만으로 하나의 원인을 확정하지 않았다.

Tera Term serial port 설정에서 COM7, 115200 baud, 8N1, no flow control와 CP2105 Enhanced port를 확인한 화면 — CLI 관측 전에 COM7·115200·8N1·flow control 없음과 CP2105 Enhanced port 선택을 화면으로 남겼다.

Tera Term COM7에서 mmwDemo prompt와 여러 CLI command 인식 실패가 반복된 화면 — UART prompt 도달과 command 거부를 서로 다른 관측 상태로 기록했다.

Tera Term에서 깨진 입력 뒤 CLI command 인식 실패와 mmwDemo prompt가 나타난 화면 — prompt가 유지되는 가운데 입력 문자열이 정상 command로 해석되지 않은 추가 재현.

Tera Term terminal에 B와 R 문자가 연속 출력된 serial stream 화면 — 반복 문자 stream을 baud·port·실행 image 불일치 가능성의 관측으로 남겼으며 원인을 단정하지 않았다.

Capture log로 종료 조건을 확인했다

record directory에는 configuration과 log file이 생성됐지만 raw .bin은 보이지 않았다. log에는 Number of received packets - 0, first·last packet ID 0, duration -2 sec가 기록됐다. 이 값을 최종 판정 근거로 삼아 “Ethernet adapter가 보인다”나 “제어 packet이 있다”를 raw ADC 수집 성공으로 올려 쓰지 않았다.

MATLAB dca1000FileReader가 지정 위치에서 bin file을 찾지 못한 error 화면 — reader 문제가 아니라 먼저 capture output 자체가 생성됐는지 확인해야 했던 지점.

MATLAB에서 recordLocation 변수를 인식하지 못한 error 화면 — example variable과 실제 object property를 섞은 host-side script 문제를 별도로 기록했다.

MATLAB에서 configureRadar 함수를 인식하지 못한 error 화면 — 지원 package example과 현재 MATLAB path·API가 맞지 않은 software boundary를 확인했다.

DCA1000 raw capture log에서 수신 packet 수가 0으로 기록된 화면 — configuration과 log file은 생겼지만 received packets가 0이어서 raw capture 성공으로 판정하지 않았다.

LED와 전원 상태를 하드웨어 관측점으로 삼았다

보드 사진에서는 여러 상태 LED가 동시에 켜진 순간을 확인했다. LED 한 장면만으로 FPGA, DDR 또는 LVDS 고장을 확정하지 않고, 설정·시작 순서가 맞지 않아 나타난 표시일 가능성도 남겨 두었다. 발열 역시 위치와 온도를 정량화한 값이 없었으므로 고장 부품을 지목하는 근거로 사용하지 않았다.

DCA1000EVM의 전원, FPGA, DDR와 LVDS 관련 상태 LED가 켜진 점검 장면 — LED label과 switch 상태를 확대해 다음 측정 지점을 정한 장면.

전원부터 물리 경로까지 좁혔다

5 V 입력과 보드 전원 상태, 발열 발생 시점을 먼저 확인했다.
DIP switch, 동작 mode, reset·configuration·capture 시작 순서를 다시 맞췄다.
보드 간 connector, cable 접촉과 solder joint를 살펴보고 의심 구간을 납땜 보수했다.
오실로스코프로 접근 가능한 전원·신호 지점의 파형을 확인했다.
PC 측 고정 IP, UDP 제어 트래픽과 0-packet capture log를 하드웨어 확인 결과와 별도로 비교했다.

이 순서는 부품을 먼저 교체하거나 소프트웨어를 무작정 수정하는 대신, 각 단계의 입력과 출력에서 다음 경계로 신호가 넘어가는지를 확인하기 위한 것이었다.

복구하지 못한 결과도 종료 조건으로 남겼다

납땜 보수와 반복 설정 뒤에도 Ethernet 원시 ADC streaming은 복구되지 않았다. 제어 UDP, flash 성공, UART prompt는 각각 확인했지만 FPGA 내부 buffer가 정상으로 샘플을 받았는지, 특정 부품이 고장 났는지는 확정하지 못했다. 따라서 DCA1000 수집 경로 사용을 중단하고, 관측한 오류 상태·점검 위치·미확정 범위를 후속 장비 점검 항목으로 남겼다.

원시 ADC capture 실패와 TI SDK 기반 3D People Tracking 실행은 서로 다른 경로다. 후자는 dual-UART로 처리된 point cloud와 target 정보를 받은 사례이며, DCA1000의 LVDS-to-Ethernet 복구 결과로 해석하지 않았다.

직무에 가져가는 디버깅 역량

이 경험에서 얻은 핵심은 실패 현상에 곧바로 원인 이름을 붙이지 않는 방법이다. flash, UART CLI, UDP control, raw packet count, 전원·발열, connector·solder, LVDS·buffer를 단계별 관측점으로 만들었다. 또한 “확인됨”, “가능성 있음”, “아직 측정하지 못함”을 나눠 종료 판단까지 남겼다. 이 방식은 레이더·자율주행 센서 검증, 임베디드 HW bring-up, 생산·양산 불량 분석과 선행품질에서 재현 조건과 원인 범위를 좁힐 때 그대로 활용할 수 있다.