eth1이 RUNNING이면 PLC가 열린 걸까 — 모뎀 상태 읽기와 송신 시험 방법

5 분 소요

지난 글에서 QCA7005에 펌웨어를 올리고, 부팅할 때마다 자동으로 올라오게 만들었다. 그다음 ifconfig를 보니 이렇게 나왔다.

eth1      Link encap:Ethernet  HWaddr 12:8A:9D:B2:56:26
          inet6 addr: fe80::108a:9dff:feb2:5626/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:290 errors:0 dropped:4 overruns:0 frame:0
          TX packets:353 errors:0 dropped:1 overruns:0 carrier:0
          RX bytes:24012 (23.4 KiB)  TX bytes:421180 (411.3 KiB)

UP RUNNING이다. 그러면 PLC가 열린 걸까? 결론부터 말하면 아니다. 이 글은 모뎀 상태를 제대로 읽는 법과, PLC 송신을 어떻게 시험할지 정리한 것이다.

1. RUNNING이 보여주는 범위

리눅스에서 RUNNING은 인터페이스의 carrier가 켜져 있다는 표시다. 일반 이더넷이라면 케이블이 꽂혀 상대와 링크가 맺어졌다는 뜻이다. 그런데 qcaspi 드라이버는 carrier를 다른 기준으로 켜고 끈다.

/* drivers/net/ethernet/qualcomm/qca_spi.c */
if (qca->sync != QCASPI_SYNC_READY) {
	netif_carrier_off(qca->net_dev);      /* 칩과 동기화 안 됨 → RUNNING 꺼짐 */
}
...
netif_carrier_on(qca->net_dev);           /* 칩과 동기화 됨 → RUNNING 켜짐 */

기준은 MPU와 QCA7005 칩 사이의 SPI 동기화다. 차와 연결됐는지는 전혀 반영하지 않는다. 실제로 칩이 부트로더 상태여서 PLC가 아예 동작하지 않을 때도 RUNNING은 켜져 있었다.

MPU(MicroProcessorUnit) ──SPI──▶ QCA7005 ──CP선──▶ 차
     └─ 여기까지 ✅          └─ 여기는 알 수 없음
     (RUNNING이 보여주는 범위)

ifconfig에서 읽을 수 있는 것

그래도 쓸모없는 출력은 아니다.

항목	의미
`UP RUNNING`	칩과 SPI 동기화 완료
`inet6 fe80::...`	IPv6 링크 로컬 주소. 나중에 ISO 15118 통신이 이 주소로 오간다
IPv4 주소 없음	정상. 충전 통신은 IPv6만 쓴다
`TX bytes: 421180`	부팅 때 펌웨어를 올린 흔적

TX가 411KB인 게 흥미롭다. 펌웨어(399KB), PIB(9.8KB), 초기화 모듈(7KB)을 더한 크기와 맞는다. 펌웨어가 eth1을 타고 칩으로 내려갔다는 게 숫자로 남아 있다.

2. 칩에게 네트워크 상태를 직접 묻기

PLC 쪽 상태는 리눅스 인터페이스가 아니라 칩에게 물어봐야 한다. plctool의 -m 옵션이 네트워크 멤버십 정보(VS_NW_INFO)를 읽는다.

root@myir:~# plctool -i eth1 -m local
eth1 00:B0:52:00:00:01 Found 1 Network(s)

source address = 00:B0:52:00:00:01

        network->NID = B0:F2:E6:95:66:6B:03
        network->SNID = 13
        network->TEI = 1
        network->ROLE = 0x02 (CCO)
        network->CCO_DA = 00:B0:52:00:00:01
        network->CCO_TEI = 1
        network->STATIONS = 0

항목	의미
Found 1 Network	칩이 자기 논리 네트워크(AVLN)를 만들었다
NID	네트워크 식별자. 네트워크 키(NMK)에서 계산된다
SNID	프레임 헤더에 들어가는 짧은 네트워크 번호(0~15)
TEI	이 네트워크 안에서 칩 자신의 주소
ROLE = CCO	네트워크 관리자 역할
CCO_DA / CCO_TEI	관리자가 자기 자신
STATIONS = 0	들어온 상대가 없다

CCO라는 것

HomePlug 네트워크에는 관리자 노드(Central Coordinator)가 하나 있다. 비콘을 내보내고, 새로 들어오는 노드에 주소(TEI)를 나눠준다. EV 충전에서는 보통 충전기 쪽 모뎀이 관리자가 되고, 차 쪽 모뎀은 관리자가 되지 않도록 설정한다. 차가 충전기의 네트워크로 들어오는 구조다.

칩이 CCO로 동작한다는 건 EVSE용 PIB가 의도대로 적용됐다는 확인이기도 하다.

STATIONS = 0은 차가 연결되지 않았으니 당연하다. 정리하면 충전기 쪽 모뎀은 네트워크를 만들어놓고 차를 기다리는 상태다.

지금 네트워크 키는 임시값이다

이 네트워크는 PIB 파일에 들어 있던 기본 키(NMK)로 만들어졌다. 같은 PIB를 쓰는 보드는 모두 같은 키를 갖는다는 뜻이다.

실제 충전에서는 이 키를 쓰지 않는다.

차 연결 → SLAC 절차
  → 충전기 소프트웨어가 새 무작위 NMK 생성
  → CM_SLAC_MATCH 로 차에게 전달, CM_SET_KEY 로 자기 칩에도 설정
  → 이번 충전 세션만을 위한 네트워크
  → 차가 들어오면 STATIONS = 1

세션마다 키를 새로 만들기 때문에 옆 충전기나 다른 차가 끼어들 수 없다. 이 SLAC 소프트웨어는 아직 없다.

3. PLC 송신은 어떻게 시험하나

먼저 피해야 할 함정

가장 먼저 떠오르는 건 eth1으로 뭔가를 보내고 TX 카운터를 보는 것이다. 하지만 ifconfig의 TX packets는 MPU가 SPI로 칩에 넘긴 프레임 수다. 칩이 그걸 CP선에 실제로 내보냈는지는 알 수 없다. 상대가 없어도 TX 숫자는 잘 올라간다.

PLC 송신을 확인하려면 선 위의 신호를 직접 보거나, 상대가 받았다는 걸 확인해야 한다. 상대 장비가 있느냐에 따라 방법이 나뉜다.

방법 1: 상대 없이 — 오실로스코프로 비콘 보기

CCO는 상대가 없어도 일정 간격으로 비콘을 내보내는 게 일반적이다. 이게 선에 실제로 실리는지 보면, 칩에서 결합 회로를 거쳐 CP선까지 이어지는 송신 경로가 살아 있는지 알 수 있다.

측정 위치: 충전 커넥터의 CP와 PE(접지) 사이. PLC 신호는 이 두 선 사이에 실린다.

예상하는 모양

수십 ms 간격으로 반복되는 짧은 고주파 덩어리
주파수 2~30MHz, 크기 수백 mV 수준
시간축 10ms/div 정도로 반복 주기를 보고, 확대해서 덩어리 내부를 본다

여기서 중요한 건 비교다. 무언가 보였을 때 그게 정말 PLC 칩이 낸 신호인지 확인해야 한다. 마침 plctool에 칩을 리셋하는 옵션이 있었다.

"R\treset device using VS_RS_DEV",

플래시가 없는 보드라서, 리셋하면 칩은 부트로더로 돌아가고 펌웨어는 사라진다. 이걸 이용해 켜고 끄며 비교한다.

plctool -i eth1 -R local          # 칩 리셋 → 부트로더 → 비콘이 멈춰야 함
systemctl restart qca7005-fw      # 펌웨어 재적재 → 비콘이 다시 나와야 함
plctool -i eth1 -r local          # 펌웨어 버전으로 돌아왔는지 확인

칩 상태	CP–PE 사이
부트로더	신호 없음
펌웨어 동작 (CCO)	주기적인 버스트

이 차이가 보이면 송신 경로는 정상이다. 지난번에 만든 적재 서비스가 여러 번 실행해도 안전하게 짜여 있어서, 이런 시험에도 그대로 쓸 수 있다.

CP선에는 ±12V PWM이 실릴 수 있으니 프로브 접지는 PE에 두고, PWM이 나가지 않는 상태에서 보는 게 편하다.

방법 2: 상대 장비와 실제로 주고받기

진짜 송수신 시험에는 HomePlug Green PHY(또는 AV) 장치가 하나 더 필요하다. 차 쪽 PLC 모듈, QCA7000 계열 평가 보드, EV 시뮬레이터 같은 것이다. 우리 보드와 CP끼리, PE끼리 연결한다.

SC6_0 두 대를 CP끼리 직접 잇는 건 안 된다. 양쪽 모두 CP에 ±12V를 내보내는 충전기 회로라 출력끼리 맞붙는다. 게다가 둘 다 EVSE PIB라서 서로 관리자(CCO)가 되려고 한다. 상대는 차 쪽 역할을 하는 장비여야 한다.

1단계 — 양쪽에 같은 네트워크 키 설정

SLAC이 할 일을 손으로 대신하는 것이다.

plctool -i eth1 -K <16바이트 NMK> -M local

-K는 키 값, -M은 그 키를 로컬 칩에 설정하는 옵션(VS_SET_KEY)이다. 상대에도 같은 키를 넣는다.

2단계 — 상대가 들어왔는지 확인

plctool -i eth1 -m local

STATIONS가 0에서 1로 바뀌고 상대의 MAC과 TEI가 보이면, 두 모뎀이 PLC로 서로를 보고 있다는 뜻이다. 이것만으로 양방향 송수신이 확인된다.

3단계 — 링크 품질

plcrate -i eth1 local

모뎀끼리 협상한 송신·수신 PHY 속도를 보여준다. 숫자가 높을수록 선로 상태가 좋다.

4단계 — 실제 데이터 (상대가 IP 스택을 가진 경우)

ping6 -I eth1 ff02::1
ping6 -I eth1 fe80::<상대 주소>

방법 3: 진짜 차와

차와 하려면 방법 2에서 손으로 넣은 키를 SLAC이 자동으로 만들고 교환해야 한다. CP PWM 듀티 5%(“디지털 통신으로 하자”)와 SLAC 소프트웨어가 필요한 단계라, 방법 1과 2를 먼저 끝내고 넘어간다.

4. 덤으로 얻은 것

옵션 목록을 보다가 찾은 -R이 다른 문제의 실마리가 됐다.

지난 글에서 reboot로는 QCA7005가 리셋되지 않는 것으로 보인다고 적었다. 칩이 이전 상태를 들고 있으면 이전 세션의 네트워크 키가 남은 채로 새 소프트웨어가 시작될 수 있다. 그때는 Q_RST 핀을 DTS의 gpio-hog에서 풀어야 한다고 생각했다.

그런데 plctool -R로 소프트웨어에서 칩을 리셋할 수 있다면, 적재 서비스 맨 앞에 리셋 한 줄을 넣는 것으로 해결될 수도 있다. DTS를 건드리지 않아도 된다. 하드웨어 리셋과 효과가 같은지는 확인이 필요해서, 별도로 검토할 항목으로 남겨둔다.

정리

RUNNING은 칩과의 SPI 동기화일 뿐이다. 차와의 PLC 링크는 반영하지 않는다
PLC 상태는 칩에게 직접 묻는다. plctool -m의 ROLE과 STATIONS가 핵심이다
지금 칩은 CCO로 네트워크를 만들어놓고 차를 기다리는 상태다. EVSE PIB가 의도대로 들어갔다
TX 카운터로는 PLC 송신을 증명할 수 없다. 선 위의 신호를 보거나 상대가 받았는지 확인해야 한다
상대가 없으면 오실로스코프로 비콘을 보되, 칩을 리셋해서 켜고 끄며 비교한다

층	상태
SPI·드라이버·eth1	✅
펌웨어 + EVSE PIB, 부팅 시 자동 적재	✅
CCO로 네트워크 생성, 차 대기	✅
CP선 송신 확인 (방법 1)	⬜ 오실로스코프 시험 예정
상대 장비와 송수신 (방법 2)	⬜ 장비 필요
SLAC	⬜
ISO 15118	⬜

다음은 오실로스코프로 비콘이 실제로 선에 실리는지 보는 것이다.

Twitter Facebook LinkedIn

이 정훈

eth1이 RUNNING이면 PLC가 열린 걸까 — 모뎀 상태 읽기와 송신 시험 방법

1. RUNNING이 보여주는 범위

ifconfig에서 읽을 수 있는 것

2. 칩에게 네트워크 상태를 직접 묻기

CCO라는 것

지금 네트워크 키는 임시값이다

3. PLC 송신은 어떻게 시험하나

먼저 피해야 할 함정

방법 1: 상대 없이 — 오실로스코프로 비콘 보기

방법 2: 상대 장비와 실제로 주고받기

방법 3: 진짜 차와

4. 덤으로 얻은 것

정리

공유하기

댓글남기기

참고

안 붙는 줄 알았던 PLC 모뎀 — QCA7005 호스트 부팅_AI작성글

부트로더 구간까지 잡다 — U-Boot에서 LTDC 끄기

입력이라던 핀이 출력이었다 — 부트로더가 남기고 간 핀 상태

ttySTM이 4개인 이유 — 브링업 검증에서 기대값 세기