XCP PGM — Flash 프로그래밍의 구조

# XCP PGM — Flash 프로그래밍의 구조

## PGM의 위치

XCP의 4가지 기능(DAQ, STIM, CAL, PGM) 중 PGM은 가장 위험하다. Flash를 잘못 지우거나 쓰면 ECU가 부팅 불가 상태가 된다. 그래서 PGM은 SEED & KEY 보안 잠금이 대부분 걸려있다.

PGM이 필요한 상황:
- ECU 소프트웨어 최초 양산 다운로드
- 필드 업데이트 (UDS Reprogramming의 대안)
- 개발 중 빠른 반복 테스트

UDS의 ECU Reprogramming(0x34/36/37)과 역할이 겹치지만, XCP PGM은 캘리브레이션 툴과 같은 환경에서 동작하므로 개발 환경에서 더 자주 쓰인다.

## PGM 시퀀스

```
Master → PROGRAM_START         (PGM 세션 시작)
Slave  ← PROGRAM_START_OK (MAX_CTO, MAX_DTO ...)

Master → PROGRAM_CLEAR(mode, addr, len)  (섹터 소거)
Slave  ← OK

Master → PROGRAM(len, data)    (데이터 쓰기, 반복)
... (PROGRAM_NEXT로 이어쓰기 가능) ...

Master → PROGRAM_VERIFY(...)   (선택적 검증)
Slave  ← VERIFY_OK

Master → PROGRAM_RESET         (ECU 리셋, PGM 종료)
```

Flash는 섹터 단위로만 지울 수 있다. `PROGRAM_CLEAR`는 지정한 주소를 포함하는 섹터를 소거한다. 소거 전에 그 섹터에 있던 기존 데이터는 모두 사라진다.

## SECTOR 구성

A2L 또는 XCP 구현 문서에는 Flash 섹터 정보가 담겨있다:

```
SECTOR_NUMBER: 0
  Start Address: 0x00000000
  Size: 64KB
  Clear Sequence Number: 0
  Prog Sequence Number: 0

SECTOR_NUMBER: 1
  Start Address: 0x00010000
  Size: 64KB
  ...
```

`PROGRAM_CLEAR`를 호출할 때 SECTOR_NUMBER나 주소 범위를 지정하면 해당 섹터를 소거한다. 순서를 지키지 않거나 범위를 잘못 지정하면 부트로더가 날아갈 수 있다.

## CRC 검증

PGM 완료 후 내용 검증이 필요하다. XCP에는 `BUILD_CHECKSUM` 명령이 있다:

```
Master → BUILD_CHECKSUM(addr, len)
Slave  ← CHECKSUM(type, checksum)
```

Master가 원본 데이터의 체크섬과 비교해서 일치하면 플래시가 정상적으로 기록된 것이다. CRC-32나 XOR 합계 등 체크섬 타입은 Slave가 알려준다.

## PGM과 CAL의 결합

개발 환경에서는 PGM과 CAL을 한 세션에서 쓰는 경우도 있다:

1. PGM으로 기본 소프트웨어 다운로드
2. ECU 리셋 후 새 소프트웨어로 부팅
3. CAL/DAQ로 파라미터 조정 + 측정

벡터 CANape 같은 툴은 이 워크플로우를 자동화하는 스크립트 기능을 제공한다.

## 실전 주의사항

- **인터럽트 비활성화**: Flash 쓰기 중 ECU가 인터럽트를 받으면 오동작할 수 있다. PGM 진행 중에는 ECU가 가능한 최소 동작만 하도록 설계되어야 한다.
- **전원 안정성**: 플래시 쓰기 중 전원이 끊기면 ECU가 벽돌이 된다. 개발 환경에서는 전원이 안정적인 테스트 케이지나 벤치에서 PGM을 수행한다.
- **보호 비트**: 일부 MCU는 플래시 보호 비트가 있어서 프로그래밍 전에 이를 해제해야 한다. Aurix TC3x 같은 경우 UCB(User Configuration Block)가 이 역할을 한다.

다음 챕터에서는 XCP on CAN과 XCP on Ethernet을 비교해 어떤 상황에서 뭘 선택해야 하는지 다룬다.

XCP PGM — Flash 프로그래밍의 구조

// COMMENTS

ON THIS PAGE