[SensorHIL] Ep 2. PC와 STM32 연결 구성

이 글의 위치

1편에서는 SensorHIL을 만들게 된 이유와 DS4 Response, Fault Injection, 실제 통신 결과를 한 흐름으로 정리했다.

이번 글에서는 1편에서 결과 위주로 압축한 개발 과정을 다시 펼쳐, PC Program과 STM32의 연결 방법과 Build/Test 환경을 정리한다.

전체 구성

PC가 DS4 Sensor 역할을 수행하도록 Program, PC COM Port, STM32 UART와 처리 결과 확인 경로를 함께 구성했다.

SensorHIL의 Physical HIL은 COM Port 두 개를 사용한다.

 

Sensor Channel은 실제 Sensor Protocol을 주고받는다.

DUT Channel은 STM32의 처리 결과와 Sensor 선택 명령을 주고받는다.

Sensor Channel

Sensor Channel의 UART 설정은 아래와 같다.

Baud rate : 9600
Data bits : 8
Parity    : None
Stop bits : 1
Flow ctrl : None

배선은 TX와 RX를 교차하고 GND를 공통으로 연결한다.

Bridge TX  → STM32 USART2 RX (PD6)
Bridge RX  ← STM32 USART2 TX (PD5)
Bridge GND ↔ STM32 GND

현재 시험에서는 STLINK-V3SET VCP를 사용했다.

 

실물 배치는 아래 그림처럼 나온다.

 

 

Q1. SensorHIL은 ST-LINK가 있어야만 동작하나요?

A1. 현재 STLINK-V3SET은 주변에서 바로 사용할 수 있어 Serial ↔ UART Bridge로 연결했다. SensorHIL은 Windows COM Port를 사용하므로, 전압과 Pinout이 맞는 FTDI, CP2102, CH340 등의 장치도 같은 역할을 수행할 수 있다.

 

SensorHIL이 실제로 사용하는 구조는 아래와 같다.

SensorHIL
→ Windows Serial Endpoint
→ Serial/UART Bridge
→ STM32 UART

DUT Observation Channel

PC가 Response를 전송했다는 사실만으로 Test를 PASS 처리할 수는 없다.

STM32가 frame을 수신했는지, CRC를 어떻게 판단했는지, 값이 얼마로 변환됐는지 확인해야 한다.

이를 위해 USART3로 별도의 status를 전송한다.

아래의 DS4와 TB200B는 이 Project에서 지원한 두 Sensor 이름이다. 처음에는 DS4만 사용했고, 이후 TB200B를 추가해도 같은 Status Format을 사용하도록 맞췄다.

TYPE=STATUS;SEQ=101;SENSOR=DS4;RESULT=OK;VALUE=100;ERROR=NONE\r\n
TYPE=STATUS;SEQ=102;SENSOR=TB200B;RESULT=ERROR;ERROR=CRC\r\n

PC에서 STM32로 Sensor 선택 명령도 보낼 수 있다.

TYPE=CONTROL;SENSOR=DS4\r\n
TYPE=CONTROL;SENSOR=TB200B\r\n

이 통신은 제품 Sensor Protocol과 분리되어 있다. Sensor Response 안에 Test용 field를 추가하면 실제 Sensor와 다른 Protocol이 되기 때문이다.

 

Q2. Sensor UART 하나로 상태까지 같이 보내면 안 되나요?

A2. 한 UART에 두 역할을 넣으면 제품 Protocol Byte에 Test Metadata가 섞이고 STM32 내부 결과를 PC가 추측하게 된다. 별도 채널을 사용하면 Sensor Channel은 실제 Wire Format을 유지하고, DUT Channel에서는 SEQ, RESULT, VALUE, ERROR를 구조화해 받을 수 있다.

PC 개발 환경

Code 작성과 Project 관리는 Visual Studio Code에서 진행했다. .vscode/settings.json에는 CMake Configure on Open과 기본 Build Directory가 설정되어 있고, CMake Tools Extension을 사용한다.

실제로 사용한 PC 환경을 일반적인 Version 단위로 정리하면 아래와 같다.

항목	사용 환경
Editor	Visual Studio Code 1.135, CMake Tools Extension
OS	Windows 11 64-bit
Language	C++20
Compiler	MSVC x64 Toolchain
Build	CMake 3.30, Ninja 1.13, Release
GUI	Qt 6.11.2 msvc2022_64, Core/Widgets

 

Windows용 실행 파일을 Compile할 때는 PC에 설치된 MSVC Compiler와 Windows SDK를 Toolchain으로 사용했다.

CMakeLists.txt에서 요구하는 최소 CMake Version은 3.24다. 위 표의 CMake 3.30은 실제 Build에 사용한 Version이며, Qt는 GUI Target을 Build할 때만 필요하다.

cmake -S . -B build_qt_msvc -G Ninja `
  -DCMAKE_BUILD_TYPE=Release `
  -DCMAKE_PREFIX_PATH=C:\Qt\6.11.2\msvc2022_64 `
  -DSENSORHIL_BUILD_GUI=ON `
  -DSENSORHIL_REQUIRE_QT=ON

cmake --build build_qt_msvc --clean-first
ctest --test-dir build_qt_msvc -C Release --output-on-failure

Qt 없이 Core, CLI, Test만 빌드하려면 SENSORHIL_BUILD_GUI=OFF를 사용한다.

 

Q3. Visual Studio를 사용하지 않았는데 MSVC가 왜 필요한가요?

A3. Visual Studio Code는 Editor이고 MSVC는 Compiler Toolchain이다. Code 작성과 Build 명령 실행은 VS Code에서 진행했지만, Windows C++ Binary와 Qt GUI를 Compile하는 과정에서는 별도로 설치된 MSVC Compiler와 Windows SDK를 사용했다.

실제 개발 및 검증 순서

아래 순서는 1편의 Emulator를 만들고 실제 Hardware에서 확인하는 동안 반복한 작업 순서이다.

작은 기능을 Build한 뒤 Loopback과 STM32 통신을 확인하고, Fault나 Test 기능을 추가할 때마다 같은 순서를 반복했다.

1. PC Clean Build를 수행한다.
2. Host CTest를 실행한다.
3. Bridge TX/RX를 직접 연결하고 Physical Loopback을 확인한다.
4. STM32 Firmware를 Clean Build하고 Flash한다.
5. Sensor UART와 DUT UART를 연결한다.
6. Fixed Test를 먼저 실행한다.
7. Fixed Test가 통과한 뒤 Scenario, Sweep, Profile을 실행한다.
8. 생성된 JSON과 HTML Report를 확인한다.

.\sensorhil_cli.exe --port COM3 --baud 9600 --loopback

.\sensorhil_cli.exe `
  --sensor-port COM3 --dut-port COM5 `
  --ds4-sim --run-tests

COM3과 COM5는 2026-08-28 시험에서 사용한 예시다.

실행할 때마다 실제 COM 번호를 다시 확인해야 한다.

Timeout과 Cable Disconnect

두 상황은 모두 STM32가 응답을 받지 못한 것처럼 보일 수 있다.

내부에서는 서로 다른 상황으로 처리한다.

Injected Timeout

• PC가 Request를 정상적으로 읽는다.
• Response byte만 보내지 않는다.
• COM Channel은 Connected 상태다.
• DUT의 ERROR=TIMEOUT은 기대 가능한 Test 결과다.

Cable Disconnect

• Windows Serial Read/Write 자체가 실패할 수 있다.
• Channel이 Error 상태가 된다.
• 실행 중 Test는 Infrastructure failure로 취소된다.
• 현재 자동 reconnect는 없다.

Q4. 둘 다 응답이 없는데 굳이 구분해야 하나요? 다 똑같은 FAIL 아닌가요?

A4. Timeout은 Firmware가 처리해야 하는 Sensor 동작이고, Cable Disconnect는 Test를 수행하는 기반 자체가 깨진 상황이다. 둘을 같은 FAIL로 처리하면 Firmware 문제인지 Test 장비 문제인지 알 수 없다. 본 프로그램의 목적은 소프트웨어적으로 발생하는 문제를 미리 준비해두자는 취지이기 때문에, 오류의 원인을 구분해야만 한다.

전기적 주의사항

UART 연결 전에는 전기 규격의 호환성을 먼저 확인한다.

• TTL UART, RS-232, RS-485는 서로 다르다.
• Logic voltage를 확인해야 한다.
• TX/RX와 Connector pinout을 확인해야 한다.
• GND를 공통으로 연결해야 한다.

Software Option을 바꾸기 전에 위 항목부터 확인하는 편이 좋다.

결론

• SensorHIL은 Sensor Channel과 DUT Observation Channel 두 개를 사용한다.
• STLINK-V3SET은 현재 Serial/UART Bridge 역할로 사용한다.
• SensorHIL은 Windows COM Port와 호환되는 Serial/UART Bridge를 사용한다.
• CubeIDE Debug Session이 없어도 Flash Firmware는 실행된다.
• Injected Timeout과 Cable Disconnect는 다른 종류의 오류다.
• Build, Host Test, Loopback, Physical HIL은 각각 확인하는 범위가 다르다.

코멘트

처음에는 Sensor UART 하나만 있으면 충분할 것이라고 생각했다.

PC에서 보낸 byte만 확인해서는 STM32가 무엇을 판단했는지 알 수 없어서 결국 Observation UART를 추가했다.

Response를 하나 만들 때마다 실제 UART로 확인하면서 Software 구조와 Hardware 구성을 같이 수정했다.

장비 이름을 기준으로 구조를 설명하면 ST-LINK가 필수인 것처럼 보이기 쉽다. 이후 장비가 바뀌더라도 Windows Serial Endpoint → Bridge → DUT UART라는 역할을 기준으로 문서를 수정할 예정이다.