기술자료

 최근 TI에서 새롭게 출시된 C2000 계열의 강력한 듀얼코어 MCU인 TMS320F28P65x 제품군을 사용하여 산업용 EtherCAT 통신 보드를 개발하시는 분들이 부쩍 늘었습니다.

 별도의 외장 EtherCAT 통신 칩(LAN9252, AX58100 등)을 쓰지 않고도, MCU 내부의 하드웨어 ESC(EtherCAT Slave Controller)를 활용해 원칩으로 고성능 모터 제어와 고속 필드버스를 동시에 구현할 수 있다는 점이 큰 매력이기 때문입니다.

그런데 펌웨어를 작성하고 마스터(TwinCAT이나 Linux IGH 마스터)와 연결하여 정상 OP(Operational) 상태까지 진입시킨 뒤, 현장 신뢰성 시험을 위해 누구나 해보는 통신 케이블 탈착 시험(Cable Re-plug Test)을 해보면 아주 당혹스러운 현상을 만나게 됩니다.

통신 중 랜선을 뽑았다가 다시 꽂으면 링크가 복구되면서 슬레이브는 겉보기에 정상적으로 다시 OP 상태로 올라옵니다. PDO 주기 데이터도 잘 오가는 것처럼 보입니다. 그런데 마스터에서 모터 파라미터나 게인 값을 바꾸려고 SDO 쓰기(SDO Write)를 날리는 순간, 100% 타임아웃 에러가 발생하면서 통신이 먹통이 되어버립니다.

CCS 디버거를 붙여 슬레이브의 내부 상태를 들여다보면, 수신 메일박스가 잠겨 있음을 뜻하는 bReceiveMbxIsLocked 변수가 TRUE로 고정되어 도무지 풀리지 않는 상태에 빠져 있습니다.

왜 이런 기이한 현상이 발생하는지, 그리고 이를 깔끔하게 해결하려면 소스 코드의 어느 부분을 손봐야 하는지 실무 관점에서 알기 쉽게 정리해 드립니다.

1. EtherCAT 메일박스 기본 원리

본격적인 원인 분석에 앞서, EtherCAT의 메일박스 통신이 어떻게 동작하는지 잠깐 짚고 넘어가겠습니다.

EtherCAT에는 크게 두 가지 통신 방식이 있습니다.

1) PDO (Process Data Object): 모터의 현재 위치, 속도, 토크 지령처럼 매 주기마다 쉬지 않고 번개처럼 주고받는 고속 주기 데이터입니다.

2) SDO (Service Data Object): 파라미터 변경, 에러 이력 조회, 장비 정보 확인 등 필요할 때마다 주고받는 비주기 메시지 통신입니다.

이 SDO 메시지가 오가는 하드웨어 통로가 바로 Sync Manager 2(SM2)라고 불리는 '수신 메일박스'입니다.

동작 방식은 아주 단순하고 확실한 핸드셰이크 규칙을 따릅니다.

- 마스터가 슬레이브에게 보낼 SDO 데이터가 생기면, 슬레이브 내부의 SM2 메일박스에 편지를 쏙 넣습니다.

- 편지가 들어오는 순간 하드웨어 메일박스 뚜껑이 자동으로 찰칵 잠깁니다(Mailbox Full 상태).

- 슬레이브 CPU(F28P65x)는 인터럽트를 받고 메일박스로 달려가 편지를 꺼내 읽습니다.

- 슬레이브 CPU가 편지를 완전히 다 꺼내 읽었다고 확인 신호를 보내야만 메일박스 뚜껑이 다시 열립니다.(Mailbox Empty 상태).

- 메일박스이 비워진 것을 확인한 마스터는 그제야 다음 편지(다음 SDO 요청)를 보낼 수 있습니다.

정상적인 환경에서는 이 과정이 수십 마이크로초 단위로 물 흐르듯 반복됩니다. 그런데 랜선을 뽑았다가 다시 꽂는 순간, 이 메일박스 시스템에 심각한 꼬임 현상이 발생합니다.

2. 랜선을 뺐다 꽂을 때 우체통이 영구 동결되는 3가지 진짜 이유

단순한 네트워크 끊김인데 왜 슬레이브의 수신 메일박스가 풀리지 않고 영구히 잠겨버릴까요? 원인은 3가지가 복합적으로 얽혀 있습니다.

이유 1: C2000 메모리 구조와 C2000Ware SDK의 '홀수 주소(Odd Address)' 버그

C2000 DSP 코어(C28x)는 메모리 주소를 16비트(Word) 단위로 지정합니다. 반면 EtherCAT 통신 규격과 ESC 하드웨어 레지스터는 8비트(Byte) 단위로 설계되어 있습니다.

TI의 C2000Ware v26.00 이전 버전 SDK에 포함된 ESC HAL(하드웨어 추상화 계층) 드라이버 코드에는 치명적인 결함이 하나 숨어 있었습니다. 마스터가 SDO 데이터를 보낼 때 데이터 길이가 홀수 바이트이거나 메모리 주소 오프셋이 홀수일 경우, 드라이버 내부의 writeoddwords 처리 로직에서 포인터 연산 오차가 발생해 하드웨어 우체통을 정상적으로 비웠음에도 CPU 스택 변수(bReceiveMbxIsLocked)의 잠금을 해제하는 코드가 실행되지 않고 누락되는 버그였습니다.

이로 인해 홀수 길이의 파라미터나 긴 SDO 데이터가 들어오는 순간 메일박스는 그 자리에서 굳어버리게 됩니다.

이유 2: 성급한 마스터와 준비 안 된 슬레이브의 충돌 (핸드셰이크 데드락)

랜선이 다시 연결되면 마스터 스택(특히 리눅스 IGH 마스터)은 슬레이브가 살아서 돌아왔는지 확인하기 위해, 슬레이브의 객체 사전(Object Dictionary) 정보를 읽어오는 SDO Info 쿼리를 연속으로 맹렬하게 전송합니다.

하지만 슬레이브 CPU는 방금 랜선이 꽂히면서 발생한 링크 복구 및 물리 계층(PHY) 인터럽트를 처리하느라 분주합니다. 슬레이브 메인 루프(MBX_Main())가 이전 패킷 처리를 미처 끝마치기도 전에 마스터의 새로운 SDO 요청이 우체통으로 쏟아져 들어오면, ESC 하드웨어와 소프트웨어 스택은 서로 상대방이 버퍼를 비워주기만을 기다리는 전형적인 데드락(Deadlock, 교착 상태)에 빠지게 됩니다.

결국 슬레이브 스택은 "아직 이전 우체통 처리가 안 끝났다"고 판단하여 bReceiveMbxIsLocked = TRUE 상태를 영원히 유지하고, 마스터는 우체통이 열리지 않으니 타임아웃을 뿜어내는 것입니다.

이유 3: 마스터 종류에 따른 차이 (TwinCAT vs Linux IGH)

개발실에서 Beckhoff TwinCAT으로 테스트할 때는 이 문제가 잘 드러나지 않는 경우가 많습니다. TwinCAT은 이미 슬레이브의 ESI 파일(XML) 정보를 PC에 캐시(Cache)해 두고 있으므로, 통신이 재개될 때 슬레이브에게 번거로운 SDO Info 전수 조사를 일일이 묻지 않기 때문입니다.

반면 임베디드 리눅스 환경에서 많이 사용하는 IGH EtherCAT Master는 노드가 재감지되면 원칙대로 0x1000 번대 인덱스부터 모든 오브젝트를 실시간으로 스캔합니다. 이 때문에 TwinCAT에서는 멀쩡하던 보드가 리눅스 장비나 상위 제어기만 물리면 랜선 탈착 시 100% 멈추는 미스터리가 발생했던 것입니다.

3. 실무 해결 처방전 (3단계 조치)

이 문제를 현장에서 확실하게 해결하기 위해서는 다음 3단계를 차례대로 적용하셔야 합니다.

1단계: C2000Ware 드라이버 홀수 주소 패치 적용

현재 사용 중인 프로젝트의 SDK 버전을 확인하시고, 아래 2개 핵심 드라이버 파일에 대해 TI E2E 공식 패치(ethercat_odd 패치)가 반영되어 있는지 점검해야 합니다.

1) f28p65x_cpu1_hw.h

2) ethercat_subdevice_cpu1_hal.c

3) mailbox.c

구버전 C2000Ware를 사용 중이라면 최신 버전으로 업데이트하거나, 위 파일들 내부의 바이트 복사 매크로(HW_EscReadWord, HW_EscWriteWord)에서 홀수 주소 경계 정렬 처리가 누락되지 않도록 수정해야 합니다.

2단계: 상태 천이(State Transition) 시 메일박스 강제 플러시 코드 추가

통신 케이블이 뽑혔다가 다시 꽂히면 슬레이브는 필연적으로 상태 머신(AL State Machine)을 거치게 됩니다(OP 상태에서 SAFEOP 또는 PREOP으로 하강 후 재상승).

슬레이브 스택의 상태 변경 콜백 함수(AL_ControlInd 또는 상태 천이 핸들러)에 "통신 상태가 정상이 아닐 때는 미처리된 메일박스 플래그를 강제로 초기화한다"는 방어 코드를 단 2줄만 넣어주면 데드락을 원천 차단할 수 있습니다.

이 코드가 들어가면, 설령 마스터의 성급한 쿼리로 인해 우체통 플래그가 꼬였더라도 케이블 재접속 시점에 상태가 초기화되면서 메일박스가 깔끔하게 리셋되어 정상 통신으로 즉시 복귀합니다.

3단계: Linux IGH 마스터 옵션 최적화

상위 제어기로 Linux IGH 마스터를 운용하신다면, 케이블 재연결 시마다 수백 개의 SDO Info를 슬레이브에게 무차별 질의하지 않도록 마스터 드라이버 설정에서 SDO Info 자동 검색 옵션을 끄고, 슬레이브의 고정 ESI 캐시 정보를 참조하도록 최적화하는 것을 권장합니다.

4. 요약 및 마무리

산업용 통신 보드를 개발할 때 정상 상태에서 데이터가 잘 오가는 것을 확인하는 것은 전체 개발의 50%에 불과합니다. 

진짜 양산 품질과 기술력의 차이는 현장의 극심한 서지 노이즈, 진동으로 인한 랜선 순단, 작업자의 케이블 오결선 등 예외 상황이 발생했을 때 장비가 스스로 정상 상태로 복구되는가에서 결정됩니다.

특히 TMS320F28P65x처럼 16비트 DSP 아키텍처에 8비트 통신 하드웨어가 내장된 특수한 환경에서는, 소프트웨어 드라이버의 바이트 정렬 문제와 버퍼 락 메커니즘을 꼼꼼하게 살피는 것이 필수적입니다.

혹시 지금 F28P65x나 F2838x로 EtherCAT 슬레이브를 개발하시면서 비슷한 메일박스 동결 현상으로 고생하고 계셨다면, 위의 3단계 처방을 꼭 프로젝트에 적용해 보시기 바랍니다.

더 궁금하신 점이나 구현 중 막히는 부분이 있으시다면 언제든 댓글로 남겨주시면 함께 고민해 드리겠습니다. 감사합니다.

원문링크 : https://e2e.ti.com/thread/1678151