Modern Embedded Recipes · 122/152

임베디드 포스트모템 분석 — Core Dump와 Field Crash

2026년 4월 19일 · Hawk · 5분 읽기

#한 줄 요약

“Crash는 현장에서 일어나지만 분석은 사무실에서 합니다.” 그 사이를 잇는 것이 coredump (Linux) 또는 mini-dump (MCU)입니다.

#어떤 상황에서 쓰나

Field에 배포된 device가 가끔 reboot합니다. 사용자는 “그냥 멈췄어요”라고만 합니다. 재현이 안 됩니다. 현장의 상태를 사무실로 가져오는 메커니즘이 필요합니다.

Linux 기반 device는 coredump, MCU 기반 device는 mini-dump 또는 last-gasp log 패턴을 씁니다. 둘 다 본질은 같습니다. Crash 순간의 register·memory·log를 압축해 그대로 가져오는 것.

#Linux Coredump

#활성화

1
# 기본은 비활성. systemd
2
sudo systemctl enable systemd-coredump.service
3
sudo systemctl start  systemd-coredump.service
4

5
# 또는 직접
6
ulimit -c unlimited
7
echo "/var/crash/core.%e.%p.%t" | sudo tee /proc/sys/kernel/core_pattern
8

9
# 또는 단일 program
10
$ ulimit -c unlimited
11
$ ./my_program
12
Segmentation fault (core dumped)

coredumpctl list로 최근 coredump를 봅니다.

1
coredumpctl list
2
TIME           PID  UID  GID  SIG     COREFILE  EXE
3
Mon 10:23      5234 1000 1000 SIGSEGV present   /usr/bin/my_program
4

5
coredumpctl debug 5234
6
# → gdb로 진입

#gdb로 coredump 분석

1
gdb /path/to/my_program /var/crash/core.my_program.5234.1700000000
2

3
(gdb) bt
4
#0  0x00007f1234567890 in process_input (data=0x0) at input.c:42
5
#1  0x00007f1234567abc in main (argc=1, argv=...) at main.c:78
6

7
(gdb) frame 0
8
(gdb) print data
9
$1 = (char *) 0x0
10
(gdb) list
11
40    char *p = data;
12
41    while (*p) {        /* NULL deref */
13
42        process(*p++);
14
43    }

NULL pointer dereference가 즉시 보입니다. print / info locals로 변수 값도.

#Symbol과 source 매핑

1
# release build는 보통 strip됨
2
gcc -g -O2 -o my_program main.c     # debug symbol 포함
3

4
# strip된 binary는 별도 symbol file 필요
5
objcopy --only-keep-debug my_program my_program.debug
6
strip my_program
7
gdb -s my_program.debug my_program core

Production에서는 strip된 binary를 배포하고, 사무실에 unstripped + debug-info를 보관.

#MCU Mini-dump 패턴

MCU에는 OS가 없으니 coredump system이 없습니다. 직접 만듭니다.

#Backup SRAM에 저장

1
#define DUMP_MAGIC 0xC0FFEE00
2

3
typedef struct {
4
    uint32_t magic;
5
    uint32_t reset_reason;     /* RCC->CSR snapshot */
6
    uint32_t pc, lr, psr;
7
    uint32_t cfsr, hfsr, bfar, mmar;
8
    uint32_t r0_r3[4];
9
    uint32_t r12;
10
    uint32_t stack[64];        /* fault 직전 stack top */
11
    uint32_t log_tail;         /* log ring tail */
12
    uint8_t  log[2048];        /* 최근 log */
13
} __attribute__((packed)) mini_dump_t;
14

15
void hardfault_save_dump(uint32_t *sp) {
16
    mini_dump_t *d = (mini_dump_t*)BACKUP_SRAM;
17
    d->magic = DUMP_MAGIC;
18
    d->reset_reason = RCC->CSR;
19
    d->r0_r3[0] = sp[0];
20
    d->r0_r3[1] = sp[1];
21
    d->r0_r3[2] = sp[2];
22
    d->r0_r3[3] = sp[3];
23
    d->r12 = sp[4];
24
    d->lr  = sp[5];
25
    d->pc  = sp[6];
26
    d->psr = sp[7];
27
    d->cfsr = *(volatile uint32_t*)0xE000ED28;
28
    d->hfsr = *(volatile uint32_t*)0xE000ED2C;
29
    d->bfar = *(volatile uint32_t*)0xE000ED38;
30
    d->mmar = *(volatile uint32_t*)0xE000ED34;
31
    memcpy(d->stack, sp, sizeof(d->stack));
32
    memcpy(d->log, g_log_ring, sizeof(d->log));
33
    d->log_tail = g_log_tail;
34

35
    NVIC_SystemReset();
36
}

Backup SRAM, RP2040 watchdog scratch, NRF52 GPREGRET 등 reset에서 살아남는 영역에 저장.

#부팅 시 dump 확인 + 전송

1
void boot_check_dump(void) {
2
    mini_dump_t *d = (mini_dump_t*)BACKUP_SRAM;
3
    if (d->magic == DUMP_MAGIC) {
4
        printf("Previous crash detected:\n");
5
        printf("PC=0x%08lx CFSR=0x%08lx BFAR=0x%08lx\n",
6
               d->pc, d->cfsr, d->bfar);
7

8
        if (network_available()) {
9
            send_dump_to_cloud(d, sizeof(*d));
10
        } else {
11
            store_dump_to_flash(d);   /* 다음 connect 시 전송 */
12
        }
13
        d->magic = 0;
14
    }
15
}

WiFi 있는 device는 즉시 cloud로, 없으면 flash에 두고 다음 boot에 전송.

#Memfault 패턴

Memfault SDK는 production에서 사용하는 상용 솔루션입니다. 오픈소스 대안의 base 패턴.

Crash 시 register + stack + thread info를 coredump format으로 저장
Reboot 후 chunk 단위로 cloud upload
서버에서 elf와 결합해 symbolicate
동일 root cause의 crash를 grouping
대시보드에서 firmware 버전별 crash rate 추적

핵심은 대량의 device에서 동일 crash를 자동 grouping하는 것입니다. Field 100대 중 5대가 같은 PC에서 reboot하면 한 그룹으로 묶입니다.

#Last-Gasp Logging

Crash 직전 1초의 로그가 가장 중요합니다. 평소에 RAM ring buffer에 적어두고 crash 시 NVRAM에 dump.

1
#define LAST_GASP_N 128
2

3
typedef struct {
4
    uint32_t ts;
5
    uint16_t code;
6
    uint16_t arg;
7
} __attribute__((packed)) gasp_t;
8

9
static volatile gasp_t g_gasp[LAST_GASP_N];
10
static volatile uint16_t g_gasp_idx;
11

12
static inline void gasp_log(uint16_t code, uint16_t arg) {
13
    uint16_t i = g_gasp_idx++ & (LAST_GASP_N - 1);
14
    g_gasp[i].ts   = DWT->CYCCNT;
15
    g_gasp[i].code = code;
16
    g_gasp[i].arg  = arg;
17
}

Hot path에서 µs 단위로 부르고, crash dump에 ring 전체를 포함시킵니다. Host에서 ring을 풀어 마지막 128개 event를 시간 순으로 봅니다.

#RAM watchpoint 패턴 — Stack overflow 잡기

1
extern uint32_t _stack_bottom;
2
*(uint32_t*)&_stack_bottom = 0xCAFEDEAD;
3

4
void watch_stack(void) {
5
    if (*(uint32_t*)&_stack_bottom != 0xCAFEDEAD) {
6
        gasp_log(GASP_STACK_OVERFLOW, 0);
7
        hardfault_save_dump(NULL);
8
    }
9
}

타이머나 idle에서 주기적으로 호출. Overflow가 발생하는 순간은 아니지만 그 직후를 잡습니다.

#Reset Reason 분석

1
typedef enum {
2
    RESET_POWER   = 1 << 0,
3
    RESET_PIN     = 1 << 1,
4
    RESET_SW      = 1 << 2,
5
    RESET_IWDG    = 1 << 3,
6
    RESET_WWDG    = 1 << 4,
7
    RESET_LOWPWR  = 1 << 5,
8
    RESET_BOR     = 1 << 6,
9
} reset_reason_t;
10

11
reset_reason_t get_reset_reason(void) {
12
    uint32_t csr = RCC->CSR;
13
    reset_reason_t r = 0;
14
    if (csr & RCC_CSR_PORRSTF)  r |= RESET_POWER;
15
    if (csr & RCC_CSR_PINRSTF)  r |= RESET_PIN;
16
    if (csr & RCC_CSR_SFTRSTF)  r |= RESET_SW;
17
    if (csr & RCC_CSR_IWDGRSTF) r |= RESET_IWDG;
18
    if (csr & RCC_CSR_WWDGRSTF) r |= RESET_WWDG;
19
    if (csr & RCC_CSR_LPWRRSTF) r |= RESET_LOWPWR;
20
    if (csr & RCC_CSR_BORRSTF)  r |= RESET_BOR;
21
    RCC->CSR |= RCC_CSR_RMVF;    /* clear */
22
    return r;
23
}

Reason	의미
`RESET_POWER`	정상 부팅 (전원 인가)
`RESET_PIN`	사용자가 reset 버튼
`RESET_SW`	우리가 `NVIC_SystemReset`
`RESET_IWDG`	Independent watchdog → 코드 hang
`RESET_WWDG`	Window watchdog → timing 위반
`RESET_BOR`	Brown-out → 전압 dip
`RESET_LOWPWR`	Low-power mode escape failure

Cloud에서 reset reason 분포를 보면 어떤 종류 crash가 흔한지 한눈에 보입니다. IWDG 50%, BOR 30%, hardfault 20%면 전원 또는 hang 문제가 우선.

#Field Debug — 원격 진단

USB 없이 ssh도 없는 device 어떻게 debug할까. 다음 옵션이 있다.

NB-IoT / LTE-M / WiFi — 가벼운 telemetry
BLE — 1m 거리에서 mobile app으로 dump 받기
UART/SD card — 회수 후 분석
디바이스 자체에 dump-view UI

크리티컬한 device는 모든 reset마다 cloud에 reset reason과 mini-dump를 보냅니다. 한 사용자의 device에서만 발생하는 crash도 잡힙니다.

#Crash Grouping

다음 두 crash는 같은 bug입니다.

1
device-A: PC=0x08001234 CFSR=0x00008200 BFAR=0x00000004
2
device-B: PC=0x08001234 CFSR=0x00008200 BFAR=0x00000004
3
device-C: PC=0x08001236 CFSR=0x00008200 BFAR=0x00000004    ← PC가 약간 다름

PC가 정확히 일치 안 해도 같은 source line이면 같은 bug. addr2line으로 normalize한 다음 grouping.

1
addr2line -e firmware.elf 0x08001234 0x08001236
2
process_packet at packet.c:78
3
process_packet at packet.c:78

같은 line이면 같은 그룹.

#자주 보는 함정

Dump 영역을 normal RAM에 둠

1
mini_dump_t dump;   /* .bss에 위치 → 부팅 시 0으로 clear */

.bss는 부팅 직후 0으로 초기화됩니다. no-init RAM 또는 backup SRAM에 둡니다.

1
__attribute__((section(".noinit"))) mini_dump_t dump;

Stack overflow로 dump 자체가 망가짐

Fault 진입 시 NVIC가 stack에 push 못 하면 더블 fault. Dump 코드는 fault entry 전에 작은 stack frame으로 동작해야 합니다.

1
__attribute__((naked))
2
void HardFault_Handler(void) {
3
    __asm volatile (
4
        "ldr  sp, =_temp_dump_stack \n"   /* fault용 별도 stack */
5
        "b    hardfault_save_dump   \n"
6
    );
7
}

Cloud 전송 실패 시 dump 잃음

전송 실패 가능성. Flash에 재전송 큐로 두고, 다음 connect 시 다시 시도.

Production에서 PII 포함

Coredump에는 RAM 전체가 들어갈 수 있어 사용자 데이터·암호가 노출됩니다. Field에서 어느 영역만 dump할지 명시. PII 영역은 dump 전에 zero로 wipe.

Symbol file 분실

Release 빌드의 .elf를 잃으면 0x08001234가 영원히 의미 없는 숫자. 모든 release elf를 영구 보관.

#정리

Linux는 systemd-coredump → gdb로 분석.
MCU는 mini-dump를 backup SRAM에 저장 → reboot 후 cloud 전송.
Mini-dump = register + stack + 최근 log + reset reason.
Last-gasp ring buffer로 crash 직전 event를 살립니다.
Reset reason flag (RCC->CSR)로 IWDG/BOR/SW reset을 구분.
PC를 source line으로 normalize해서 같은 bug를 grouping.
Strip된 binary와 unstripped + debug symbol을 같이 보관.
Dump 영역은 .noinit 또는 backup SRAM. .bss 금지.

다음 편은 FPGA 기초입니다.

#관련 항목

Modern Embedded Recipes · 123 of 152

임베디드 로깅 시스템 설계 — 레벨·버퍼·SWO·Deferred

임베디드 환경에서 overhead를 최소화한 로깅. 레벨 분리·circular buffer·SWO/RTT·deferred 처리 패턴.

2026년 4월 19일 · recipes

같은 시리즈에서 이어 읽기

통신 프로토콜 분석 — Logic Analyzer와 Protocol Decoder

Saleae·DSLogic·oscilloscope·protocol decoder로 UART/SPI/I2C/CAN 신호를 캡처·디코딩하는 실전 패턴.

2026년 4월 19일 · recipes

같은 시리즈에서 이어 읽기

타이밍·Race 진단 — Heisenbug 잡는 법

printf로 race가 사라지는 이유와 SWO/RTT·DWT 사이클 카운터·GPIO pulse로 non-intrusive하게 race를 가시화하는 방법.

2026년 4월 19일 · recipes

같은 시리즈에서 이어 읽기

임베디드 포스트모템 분석 — Core Dump와 Field Crash

#한 줄 요약

#어떤 상황에서 쓰나

#Linux Coredump

#활성화

#gdb로 coredump 분석

#Symbol과 source 매핑

#MCU Mini-dump 패턴

#Backup SRAM에 저장

#부팅 시 dump 확인 + 전송

#Memfault 패턴

#Last-Gasp Logging

#RAM watchpoint 패턴 — Stack overflow 잡기

#Reset Reason 분석

#Field Debug — 원격 진단

#Crash Grouping

#자주 보는 함정

#정리

#관련 항목

Modern Embedded Recipes · 123 of 152

관련 글

임베디드 로깅 시스템 설계 — 레벨·버퍼·SWO·Deferred

통신 프로토콜 분석 — Logic Analyzer와 Protocol Decoder

타이밍·Race 진단 — Heisenbug 잡는 법

이 글을 참조하는 글 (4)