PIC32 CAN 펌웨어 업데이트(부트로더) 로드맵
핵심 구조는 부트로더(고정) + 애플리케이션(교체 대상) 분리입니다. 부트로더가 CAN으로 새 이미지를 받아 Flash에 쓰고, 검증 후 앱으로 점프합니다.
Phase 0. 사전 결정 (1~2일)
칩 확인: PIC32MX / MZ / MK 등에 따라 Flash 구조가 많이 다릅니다. 특히 MZ는 Dual Boot Flash와 Bank Swap을 지원해서 안전한 A/B 업데이트가 가능하고, MX는 단일 뱅크라 부트로더가 자기 영역을 보호하는 구조로 가야 합니다.
CAN 종류: CAN 2.0B(페이로드 8바이트)인지 CAN FD인지. FD면 전송이 훨씬 빠릅니다.
프로토콜 수준: 처음엔 단순 커스텀 프로토콜로 시작하고, 이후 UDS(ISO 14229) 스타일로 확장하는 걸 추천합니다.
참고 자료: Microchip AN1388(PIC32 UART 부트로더)은 구조 참고용으로 좋고, MPLAB Harmony 3 Bootloader 라이브러리/예제도 확인해보세요(지원 디바이스는 확인 필요).
Phase 1. 메모리 맵 & 부트로더 골격 (3~5일)
Flash 분할: Boot Flash(또는 Program Flash 앞부분)에 부트로더, 나머지에 앱을 배치합니다.
앱 링커 스크립트 수정: 앱 시작 주소와 길이를 바꾸고, 벡터/EBASE 설정이 부트로더와 충돌하지 않게 합니다.
부트 진입 조건: 리셋 직후 (a) 앱 유효성 검사(매직 넘버·CRC), (b) RAM/Flash 플래그(앱이 "업데이트 요청"을 남기고 리셋), (c) 핀 입력, (d) 일정 시간 CAN 요청 대기 중 하나 이상을 사용합니다.
앱 점프: 스택/인터럽트 상태를 정리하고 앱 Reset 주소로 분기합니다.
검증: 앱↔부트로더 왕복 전환이 되는지 먼저 확인합니다. CAN은 아직 붙이지 않아도 됩니다.
Phase 2. CAN 드라이버 & 전송 계층 (3~5일)
부트로더 전용 폴링 방식 CAN 드라이버를 작성합니다. 인터럽트를 쓰면 벡터 충돌 문제가 생기기 쉽습니다.
전용 CAN ID를 할당합니다(예: 요청/응답 분리, 노드 ID 포함).
8바이트 제한 때문에 ISO-TP(ISO 15765-2) 같은 세그멘테이션/흐름 제어가 필요합니다. 처음엔 시퀀스 번호 + ACK 방식으로 간단히 만들어도 됩니다.
타임아웃, 재전송, 버스오프 복구를 처리합니다.
Phase 3. Flash 프로그래밍 (3~5일)
NVM 컨트롤러 사용: 언락 시퀀스 → Erase(Page) → Program(Word/Row) 순서입니다. 칩별 Page/Row 크기와 정렬 제약을 데이터시트로 확인하세요.
쓰기/지우기 동안 CPU가 멈추거나 인터럽트를 막아야 합니다(부트로더에선 인터럽트 미사용이 편함).
명령 세트 예시(UDS 대응): 세션 진입(0x10), 보안 접근(0x27), Erase 루틴(0x31), RequestDownload(0x34), TransferData(0x36), TransferExit(0x37), 검증 루틴(0x31), ECU Reset(0x11).
블록 단위로 수신 → 버퍼 → Flash Write → 다음 블록 요청 순으로 진행합니다.
Phase 4. 호스트 툴 (3~5일)
Python + python-can으로 시작합니다(PCAN / Kvaser / SocketCAN 어댑터).
.hex(Intel HEX)를 파싱해 주소별 바이너리 블록으로 변환하고, 프로토콜 순서대로 전송하며 진행률과 에러를 처리합니다.
이미지 헤더(버전, 길이, CRC32)를 붙여 부트로더가 검증하게 합니다.
Phase 5. 안정성 & 보안 (1~2주)
무결성: 전체 이미지 CRC32를 확인하고, 통과해야 "유효 플래그"를 마지막에 기록합니다. 이렇게 하면 도중에 전원이 꺼져도 부트로더로 복귀할 수 있습니다.
부트로더 보호: Boot Flash 쓰기 보호나 Code Protect 설정을 합니다.
WDT: 앱이 멈춘 경우의 복구 경로를 확보합니다.
보안(선택): 시드-키 인증, 이미지 서명(ECDSA)이나 AES 암호화.
롤백(MZ 한정): Dual Boot Flash + Bank Swap으로 A/B 구조를 만듭니다.
Phase 6. 테스트 (지속)
정상 업데이트, 중간에 CAN 케이블 분리, 전원 차단, 잘못된 CRC, 버스 부하 상황, 앱 크기 경계값, 반복 업데이트(100회+) 시나리오를 돌려봅니다.
추천 진행 순서
① 앱↔부트로더 점프 → ② CAN 수신 확인 → ③ Flash Erase/Write 단독 테스트 → ④ 호스트 연동 → ⑤ CRC·보호·롤백 순서로, 각 단계가 독립적으로 검증되게 쌓아가세요. 한꺼번에 붙이면 디버깅이 매우 어렵습니다.
사용하는 PIC32 정확한 부품 번호(예: PIC32MK, PIC32MZ 계열 등)와 CAN 2.0/FD 중 무엇인지 알려주시면, Flash 구조와 메모리 맵에 맞춰 더 구체적으로 설계해드릴게요.
