S32K144 실습 — 쿡북에서 CAN까지 2주

앞 편이 표준을 글로 다뤘다면, 이 편은 그것을 실제 자동차 MCU 보드 위에서 만진다. 대상은 NXP S32K144EVB-Q100, 교재는 NXP 애플리케이션 노트 AN5413 "S32K1xx Series Cookbook" 이다.

목표는 예제를 돌리는 것이 아니라 면접에서 말할 수 있는 결과물과 숫자를 남기는 것이다.

---

실제로 이렇게 물어본다

"보드로 뭘 해보셨어요?"
"인터럽트 직접 써 보셨나요? 폴링이랑 뭐가 달랐습니까?"
"CAN 통신 해 본 적 있어요? 안 되면 뭐부터 확인합니까?"
"디버깅은 어떻게 하셨어요?"
"레지스터를 직접 만져 본 적 있습니까, 아니면 라이브러리만 쓰셨습니까?"

마지막 질문이 핵심이다. 자동차 임베디드는 HAL 아래를 아는 사람을 뽑는다. 쿡북이 정확히 그 층이다.

---

0. 이 보드는 취미 보드와 급이 다르다

"왜 이 보드를 골랐나요?" 에 답이 나온다 — 취미로 산 게 아니라 양산 차량 ECU에 들어가는 계열이라서다. 이 한마디가 다른 지원자와 갈리는 지점이다.

내 칩의 정확한 사양은 각인으로 읽는다

같은 S32K144라도 속도·RAM·온도가 부품번호로 갈린다. 칩 위 각인을 이렇게 끊어 읽는다.

F S32 K 1 4 4 [속도] [옵션] T0 [온도] [패키지] [포장]
              └ H  80MHz          └ V  -40~105℃   └ LH  64핀
                U  112MHz           M  -40~125℃     LL  100핀
                N  80MHz, 3.3V 전용  W  -40~150℃
                M  64MHz — 단종된 등급

옵션  F = CAN FD + FlexIO      A = + Security
      N = RAM 축소 (K144는 64KB 가 아니라 48KB)

유통 사이트에서 64MHz로 적힌 물건을 보게 되는 이유가 여기 있다 — M 등급은 데이터시트가 "더 이상 표준으로 제공하지 않는다"고 명시한 단종 부품이다. 지금 파는 것은 80MHz(H)와 112MHz(U)다.

RAM도 마찬가지다. 옵션 문자가 N이면 48KB다. 스택·힙을 아슬아슬하게 잡았다가 다른 보드에서 안 도는 일이 여기서 생긴다.

---

S32K144 와 S32K3 계열은 무엇이 다른가

책상에 144 말고 344 같은 보드가 함께 있다면, 둘은 세대가 다르다.

락스텝이 이 표의 핵심이다. 같은 코드를 두 코어가 동시에 실행하고 결과를 비교해 다르면 고장으로 처리한다. ASIL D 를 요구하는 기능에서 하드웨어가 스스로를 감시하는 방식이고, S32K1 에는 없는 구조다.

어느 것으로 공부할 것인가

S32K144   쿡북(AN5413)이 이 보드 기준이다 · 레지스터를 직접 만지는 학습에 최적
          자료가 많고 예제가 짧다 → 기본기를 세우기 좋다

S32K344   최신 ECU 에 가깝다 · 이더넷·보안·락스텝을 실제로 만져 볼 수 있다
          대신 설정 규모가 커서 RTD(드라이버) 기반 개발이 사실상 전제다
          베어메탈로 처음부터 짜기에는 부담이 크다

순서를 권한다면 144 로 기본기, 344 로 최신 흐름이다. 면접에서도 이 순서로 말하면 설득력이 있다 — "레지스터 수준을 144 로 익히고, 344 로 이더넷과 보안이 들어온 최근 구조를 봤습니다" 가 되기 때문이다.

면접에서 쓸 한 줄

차량 전자 구조가 분산 ECU 에서 존·도메인 중앙화로 가면서, MCU 에 요구되는 것이 연산량·이더넷·보안·기능안전으로 옮겨 갔다. S32K1 과 S32K3 의 차이가 그 변화를 그대로 보여준다.

1. 도구는 셋이면 된다

S32 Design Studio     무료 · 코드 크기 제한 없음 · Eclipse 기반 (GCC)
AN5413 + 예제 zip      쿡북 본문과 프로젝트 일체. S32DS 에서 File - Import 로 통째로 읽힌다
RTD (선택)             AUTOSAR 4.4 / R21-11 드라이버. 3주차에 쓴다

디버거는 보드에 OpenSDA가 올라가 있어 USB 케이블 하나면 된다. 별도 J-Link가 필요 없다.

보드 자체를 설명해 주는 자료

쿡북은 코드를 다루지 부품 배치를 다루지 않는다. 보드에 뭐가 붙어 있는지는 아래에서 확인한다.

핀 배치에서 자주 쓰는 것만 미리 적어 둔다.

CAN       PTE5 = CAN0_TX          PTE4 = CAN0_RX
LIN       PTD7 = LPUART2_TX       PTD6 = LPUART2_RX
LED       PTD15 빨강 (FTM0_CH0)   PTD16 초록 (FTM0_CH1)   PTD0 파랑 (FTM0_CH2)
포텐셔미터  PTC14 = ADC0_SE12
입력 캡처   PTE8 = FTM0_CH6        (보드 J2 헤더 8번 핀)
SBC       LPSPI1 — PTB14 SCK · PTB15 SIN · PTB16 SOUT · PTB17 PCS3
USB       J7 (micro-B)            전원 정상이면 D2·D3 초록

위 값은 보드 Operating Instructions 원문과 쿡북 예제 코드에서 확인한 것이다. 블로그 글마다 조금씩 다르게 적혀 있어, 안 맞으면 이 두 문서를 기준으로 삼으면 된다.

---

2. 시작 전에 알아 둘 함정 — 여기서 하루씩 날아간다

CAN이 안 나가는 첫 번째 이유는 코드가 아니라 전원이다. 보드는 기본 설정이 J107 2-3 단락 = USB 전원이고, 이 상태에서는 CAN 트랜시버(UJA1169 SBC)가 살지 않는다. 외부 12V를 연결하고 J107을 1-2로 옮겨야 한다. USB는 그대로 꽂아 두면 디버깅이 계속된다. USB 전원이 정상이면 보드의 D2·D3 LED가 초록으로 켜진다 — 전원 문제인지 아닌지 먼저 이걸로 가른다. 트랜시버 없이 코드만 확인하려면 CAN0_TX(PTE5) ↔ CAN0_RX(PTE4)를 직접 점퍼하거나 FlexCAN 루프백 모드를 쓴다.

SPI 예제가 CAN 예제의 준비 운동이다. SBC는 SPI로 상태를 읽고 설정하는 칩이다. 쿡북 SPI 예제는 SBC의 Device ID 레지스터(0x7E)를 읽어 0xFDEF가 나오는지 확인한다. 이 값이 안 나오면 CAN을 짜기 전에 배선부터 잡아야 한다.

구형 보드는 트랜시버가 다르다. 보드 뒷면 실크가 SCH-28810이면 초기형이라 트랜시버가 MC33903이고 SPI 명령 자체가 다르다. CAN FD 속도도 제한된다.

워치독이 리셋 직후부터 돌고 있다. 쿡북의 모든 예제가 WDOG_disable()로 시작하는 이유다. 취미 보드에서는 없던 습관이고, 자동차 MCU라서 그렇다. 실제 제품에서는 끄는 게 아니라 관리한다 — 앞 편의 워치독 급여 패턴이 여기에 붙는다.

void WDOG_disable(void) {
    WDOG->CNT   = 0xD928C520;   /* 언락 시퀀스 — 매직 값이 맞아야 설정이 열린다 */
    WDOG->TOVAL = 0x0000FFFF;
    WDOG->CS    = 0x00002100;
}

부팅 클럭은 80MHz가 아니다. 리셋 직후에는 내부 FIRC로 돈다. 쿡북 2.2 예제가 SOSC_init_8MHz() → SPLL_init_160MHz() → NormalRUNmode_80MHz() 순서로 갈아타는 과정을 보여준다. 클럭을 바꾸는 순서와 이유를 설명할 수 있으면 그 자체가 면접 답변이다.

모드별 상한은 이렇다 (쿡북 원문 표).

RUN (기본 FIRC)      CORE 48MHz
RUN (SPLL)           CORE 80MHz   BUS 40MHz
HSRUN (SPLL)         CORE 112MHz  BUS 56MHz
VLPR (저전력)         CORE 4MHz

112MHz를 쓰려면 HSRUN 모드로 들어가야 한다. 그냥 PLL만 올린다고 되는 게 아니라 전압·플래시 대기 상태까지 함께 바뀌는 모드 전환이다.

데이터시트가 붙여 둔 조건 둘이 실무에서 바로 걸린다.

온도    HSRUN 은 주변온도 -40~105℃ 까지다. RUN 은 150℃ 까지 간다
        그래서 125℃ 부품(온도 코드 M)과 112MHz 등급(U)은 조합되지 않는다

동시성   CSEc(보안 모듈)나 EEPROM 쓰기·소거는 HSRUN 에서 하면 에러 플래그가 선다
        그 작업을 하려면 RUN(80MHz) 으로 내려왔다가 다시 올라가야 한다

"제일 빠른 모드로 두면 되지 않나"에 대한 답이 이것이다 — 속도를 올리면 온도 여유와 플래시 쓰기를 내준다. 트레이드오프를 숫자로 말할 수 있으면 데이터시트를 읽는 사람으로 보인다.

---

3. 1주차 — 쿡북 순서대로, 다만 '확인'을 붙인다

예제를 돌리기만 하면 아무것도 남지 않는다. 각 예제마다 한 가지를 부러뜨려 보고 기록한다.

하루 한 개면 열흘, 이틀에 세 개면 일주일이다.

---

4. 2주차 — 초음파 거리계

회로에서 먼저 조심할 것

원통 두 개 중 하나가 소리를 쏘고 다른 하나가 반사파를 받는다. 차량용 초음파 센서는 하나의 압전 소자가 송신과 수신을 겸하는 구조가 많지만, 시간을 재서 거리로 바꾸는 원리는 같다.

HC-SR04는 5V 부품이고 Echo 핀이 5V로 나온다. 보드 I/O 전압 설정을 확인하고, 3.3V로 쓰고 있다면 저항 두 개로 분압해서 넣는다(예: 10kΩ + 20kΩ). 이 확인 없이 직결하는 것이 초보의 첫 실수다.

쿡북 설정을 그대로 쓰면 안 되는 이유

쿡북 FTM 예제는 8MHz를 128분주해 62,500Hz로 센다. 한 틱이 16µs다. 초음파는 1cm가 약 58µs이므로 해상도가 0.27cm로 거칠고, 무엇보다 계산이 지저분해진다.

프리스케일 /8  →  8MHz / 8 = 1MHz  →  1틱 = 1µs   ← 거리계는 이쪽
16비트 카운터  →  65,536µs = 65.5ms 만에 한 바퀴 (HC-SR04 최대 에코 ~38ms, 안전)

코드

핀은 쿡북과 같다 — PTE8 = FTM0 채널 6 (ALT2), 보드의 J2 8번 핀이다.

/* 포트 설정 — 쿡북 2.5 예제와 동일 */
PCC->PCCn[PCC_PORTE_INDEX] |= PCC_PCCn_CGC_MASK;
PORTE->PCR[8] |= PORT_PCR_MUX(2);        /* ALT2 = FTM0_CH6 (입력 캡처) */

/* 캡처 결과 — ISR 과 메인이 함께 보므로 volatile */
static volatile uint16_t cap_prev, cap_curr;
static volatile uint8_t  echo_ready;

void FTM0_Ch6_IRQHandler(void) {
    if (FTM0->CONTROLS[6].CnSC & FTM_CnSC_CHF_MASK) {
        FTM0->CONTROLS[6].CnSC &= ~FTM_CnSC_CHF_MASK;   /* 플래그 클리어 */
        cap_prev = cap_curr;
        cap_curr = (uint16_t)FTM0->CONTROLS[6].CnV;     /* 하드웨어가 박아 둔 시각 */
        echo_ready = 1;
    }
}

/* 거리 계산 — 부동소수점 없이 */
uint16_t distance_cm(void) {
    uint16_t delta = cap_curr - cap_prev;   /* 16비트 unsigned 뺄셈이 오버플로를 알아서 처리 */
    return (uint16_t)(delta / 58u);         /* 1틱 = 1µs, 1cm ≈ 58µs 왕복 */
}

cap_curr - cap_prev가 오버플로에서도 맞는 이유는 좋은 꼬리질문거리다. 부호 없는 정수 뺄셈은 2의 보수로 순환하므로, 카운터가 한 바퀴 돌아도 차이값은 옳다 — 단 한 주기(65.5ms)를 넘지 않는 한에서다.

여기서 끝내지 말 것

타임아웃      에코가 안 오면 무한 대기 금지 → 40ms 지나면 '측정 실패'로 처리
필터          중앙값 3개 또는 이동평균 — 초음파는 튄다
주기          10~20Hz 이상 쏘면 이전 반향이 섞인다 (crosstalk)

이 셋을 다뤘다고 말하면 "센서를 실제로 써 본 사람" 으로 들린다.

---

5. 거리값을 CAN으로 — 표준을 얹는 자리

이제 앞 편에서 본 E2E 개념을 직접 넣는다. 8바이트 안에 값·순번·CRC를 담는다.

/* 10ms 주기 송신 프레임 */
typedef struct {
    uint16_t distance_cm;   /* 측정값 */
    uint8_t  status;        /* 0=정상 1=측정실패 2=센서고장 */
    uint8_t  counter;       /* 매 송신 +1, 0..14 순환 → 정지·유실 감지용 */
    uint8_t  crc;           /* 앞 4바이트에 대한 CRC8 */
} UsFrame;                  /* 나머지 3바이트는 예약 */

/* 수신 노드 */
if (crc8(&f, 4) != f.crc)                     enter_safe_state(E2E_CRC);
else if (f.counter == prev)                    enter_safe_state(E2E_STUCK);
else if (((prev + 1u) % 15u) != f.counter)     log_fault(E2E_LOST);
else if (now - last_rx_ms > 50u)               enter_safe_state(E2E_TIMEOUT);

보드가 하나뿐이어도 검증할 수 있다. FlexCAN 루프백 모드를 켜면 자기가 보낸 프레임을 자기가 받는다. 다만 이때는 송신 ID와 수신 메시지 버퍼 필터 ID를 같게 맞춰야 한다 — 쿡북 예제는 송신 0x555 / 수신 0x556으로 서로 다르게 잡혀 있어서 그대로 두면 아무것도 안 받는다.

전선을 실제로 태우고 싶으면 노드가 둘 필요하다. 두 번째 노드는 USB-CAN 어댑터로 대신할 수 있고, 그러면 PC에서 프레임을 눈으로 본다.

이 그림에서 루프백이 검증하지 못하는 것이 그대로 보인다 — 두 가닥의 차동 신호, 양 끝의 120Ω 종단, 그리고 여러 노드가 동시에 말할 때의 중재다.

---

6. 측정 — 여기가 면접에서 값이 나가는 부분

"동작했습니다"는 흔하고, "이렇게 바꾸니 얼마가 됐습니다" 는 드물다. 두 가지 방법이면 충분하다.

사이클을 직접 센다 (Cortex-M4 내장 DWT)

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL  |= DWT_CTRL_CYCCNTENA_Msk;

uint32_t t0 = DWT->CYCCNT;
do_work();
uint32_t cycles = DWT->CYCCNT - t0;      /* 80MHz면 1사이클 = 12.5ns */

밖에서 본다 (GPIO 토글 + 로직 분석기)

값싼 24MHz 제품으로도 SPI·I²C·UART 해석이 되고, GPIO 토글 폭을 재는 데는 충분하다.

void task(void) {
    PTD->PSOR = LED_MASK;   /* 작업 시작 — 핀 HIGH */
    do_work();
    PTD->PCOR = LED_MASK;   /* 끝 — LOW */
}

파형의 HIGH 비율이 그대로 CPU 점유율이다. 인터럽트 지연(latency) 도 이 방법으로 잰다.

기록은 이렇게 남긴다. 이 표 한 장이 포트폴리오다.

---

7. 일부러 고장 내 보기 — HardFault

이걸 해 본 지원자는 드물다. "디버깅 어떻게 하세요" 질문의 답을 만들어 준다.

/* 일부러 정렬되지 않은 접근 / 잘못된 포인터 */
volatile uint32_t *bad = (uint32_t *)0x00000003;
uint32_t x = *bad;               /* → HardFault */

핸들러에서 원인을 읽는다.

void HardFault_Handler(void) {
    volatile uint32_t cfsr  = SCB->CFSR;    /* 0xE000ED28 — 어떤 종류의 폴트인가 */
    volatile uint32_t hfsr  = SCB->HFSR;    /* 강제 승격 여부 */
    volatile uint32_t bfar  = SCB->BFAR;    /* 문제가 된 주소 */
    for (;;) { }                            /* 디버거로 멈춰 값을 본다 */
}

CFSR 의 UNALIGNED 비트가 서 있다  → 정렬되지 않은 접근
BFAR 에 0x00000003 이 보인다      → 그 주소를 만진 코드를 역추적

여기에 스택 프레임에서 원래 PC를 꺼내는 법까지 하면 이야기가 완성된다 — 예외 진입 시 스택에 R0-R3, R12, LR, PC, xPSR이 쌓여 있으므로, 그 PC를 맵 파일과 대조하면 범인이 나온다.

---

8. AUTOSAR를 가장 싸게 만져 보는 법 — RTD

NXP가 RTD(Real-Time Drivers) 를 무료로 준다. AUTOSAR 4.4 규격의 상위 인터페이스와 비-AUTOSAR 저수준 인터페이스를 함께 제공하는 드라이버 묶음이다.

S32DS 에서 RTD 설치 → Dio · Can 드라이버를 설정 화면에서 구성 → 코드 생성
생성된 Dio_Cfg.c 를 열어 본다 → 설정이 어떻게 C 배열로 바뀌는지 눈으로 확인

목표는 AUTOSAR로 제품을 만드는 게 아니다. 면접에서 "MCAL이 뭔지 압니다" 와 "MCAL 드라이버를 설정해서 생성된 코드를 열어 봤습니다" 는 완전히 다르게 들린다. 반나절이면 후자가 된다.

---

9. 면접에서 말하는 법

약한 답
  "S32K144로 초음파 센서 거리 측정 해봤습니다."

강한 답
  "S32K144 보드로 주차 센서 노드를 흉내 내 봤습니다.
   FTM 입력 캡처로 에코 폭을 재는데, 처음엔 폴링으로 짰더니 40ms 동안
   CPU가 묶여서 다른 일을 못 했습니다. 인터럽트로 바꾸고 GPIO 토글을
   로직 분석기로 재니 점유가 눈에 띄게 떨어졌습니다.
   거리값은 10ms 주기로 CAN에 실었고, 프레임에 순번과 CRC를 넣어
   수신 쪽에서 값이 멈추거나 유실되는 경우를 구분하게 했습니다.
   CAN이 처음에 안 나가서 한참 봤는데, 코드가 아니라 보드 SBC에
   12V가 안 들어가 있던 게 원인이었습니다."

길이 차이가 아니라 숫자·증상·원인이 들어 있느냐의 차이다. 마지막 문장 같은 실패담은 감점이 아니라 가점이다 — 하드웨어를 실제로 만진 사람만 할 수 있는 이야기다.

---

꼬리질문 대비

"입력 캡처 대신 인터럽트로 에코 폭을 재면 안 되나요?"
  → 된다. 다만 ISR 진입 지연만큼 오차가 생긴다.
    입력 캡처는 하드웨어가 에지 순간의 타이머 값을 박아 두므로 지연이 오차에 안 들어간다.

"프리스케일을 더 낮춰 분해능을 올리면 좋은 것 아닌가요?"
  → 16비트 카운터가 더 빨리 한 바퀴 돈다. /1로 하면 8.2ms 만에 순환해
    38ms 에코를 못 잰다. 분해능과 측정 범위의 트레이드오프다.

"CAN 주기를 10ms로 잡은 근거는?"
  → 주차 속도에서 요구되는 갱신 주기와 버스 부하의 절충. 근거를 대는 게 중요하다.

"루프백으로 검증한 건 실제 통신이 아니지 않나요?"
  → 맞다. 프로토콜 계층은 검증되지만 물리 계층은 빠진다.
    종단저항·차동 신호·트랜시버는 실제 노드 둘로 확인해야 한다.

---

한 줄 요약

• S32K144는 AEC-Q100 · ASIL B 지원 · CAN FD 내장의 양산급 자동차 MCU다 — 보드 선택 자체가 답변 재료
• 교재는 AN5413 쿡북, 도구는 무료 S32DS, 디버거는 보드 내장 OpenSDA
• CAN이 안 되면 J107 + 외부 12V부터 본다. SPI로 SBC ID 0xFDEF 확인이 그 다음
• 초음파는 PTE8 = FTM0 CH6 입력 캡처, 프리스케일 /8로 1µs 틱을 만들고 /58로 cm 환산
• CAN 프레임에 counter + CRC를 넣으면 표준(E2E)을 코드로 설명할 수 있다
• 남길 것은 동작이 아니라 숫자 — DWT 사이클 카운트와 GPIO 토글 파형
• 일부러 HardFault를 내고 CFSR·BFAR로 추적한 경험은 디버깅 질문의 완성된 답이 된다

앞 편 — 자동차 임베디드 표준 에서 여기 나온 AUTOSAR·ISO 26262·E2E의 배경을 다룬다. 회사 맥락은 공고 기술 스택 과 자율주차 편에 있다.

출처 — S32K1xx Data Sheet Rev.15 (2026-03-05, NXP) · AN5413: S32K1xx Series Cookbook (NXP) · S32K144-Q100 평가보드 (NXP) · S32K1 제품군 브로슈어 · S32K1xx Series Safety Manual · Real-Time Drivers (RTD) · FlexCAN 루프백 예제