ROM, RAM, Flash, EEPROM, NVM의 완벽한 차이
들어가며
RAM, ROM에 대해 정확히 알고계시나요?
두개가 뭐가 다르냐고 묻는다면 휘발성, 비휘발성이라고만 대답하고 있진않은가요?
그럼 "Flash랑은 뭐가 다르냐"는 질문에는요?
그럼 "EEPROM은 ROM에 EEP가 붙은건가요?" 라는 질문에는요?
"NvM도 비휘발성이지 않나요 ?" 라는 질문에는요?
여기서 한번에 알아가는거예요
그래서 뭉치로 관련된 것을 모두 모아봤어요
할때 한번에 알아가자고요~
“껐다 켜도 남아 있으면 ROM, 끄면 사라지면 RAM”
예를 들어볼게요 .
당신의 차가 시동을 끈 후 다시 켜졌어요.
ECU 부팅 과정:
0초: 전원 ON
└─ ROM에서 부트로더 코드 실행
1초: 부트로더 실행
└─ "어디서 메인 프로그램 로드할까?"
2초: Flash에서 프로그램 로드
└─ 메인 프로그램을 RAM으로 복사
3초: RAM에서 프로그램 실행
└─ "엔진 컨트롤 시작!"
운전 중:
- RPM, 온도, 센서값 → RAM (빠른 읽기/쓰기)
- 연비 데이터 → EEPROM (오래 보존)
- 에러 코드 → Flash (전원 끈 후에도 유지)
100시간 운전 후:
- 차를 끄면 전원 OFF
- RAM은 모두 사라짐 (휘발성)
- EEPROM, Flash는 유지됨 (비휘발성)
10,000km 후:
- 진단기 스캔
- Flash에 저장된 DTC (오류 코드) 확인 ✓
- RAM의 임시 데이터는 이미 사라짐
"어? 이전에 있던 오류 코드가 아직도 있어?"
→ 그건 Flash에 저장되어 있었기 때문!메모리는 ECU의 핵심인데요
이 글에서는 ROM, RAM, Flash, EEPROM, NVM의
정확한 정의, 특징, 차이, 그리고 자동차에서 어떻게 쓰이는지 명확하게 알아가는 시간을 가져봅시다
-> 3분 요약
바쁜 당신을 위한 핵심:
🏃 RAM = 빠른 읽기/쓰기, 전원 끄면 삭제 (휘발성)
📦 ROM = 부팅 코드, 절대 바꾸지 않음 (읽기 전용)
💾 Flash = 프로그램 저장, 전원 꺼도 유지 (비휘발성)
🔐 EEPROM = 데이터 저장, 느리지만 오래 보존
🗄️ NVM = EEPROM + Flash 통합 관리 (AUTOSAR)RAM은 빠르지만 임시, Flash/EEPROM은 느리지만 오래 보존된다
🏃 RAM (Random Access Memory)이란?
정의
RAM = 프로그램 실행 중 임시 데이터를 저장하는 메모리
특징:
- 매우 빠른 읽기/쓰기 (나노초 단위)
- 전원 끄면 모든 데이터 삭제 (휘발성)
- 용량 제한 (ECU는 보통 512KB ~ 2MB)
- 비쌈 (가격 저가)
- 전원이 필요 (수시로 리프레시)RAM의 구조
메모리 맵:
┌─────────────────────────┐ 0xFFFFFFFF
│ System Area │ (높은 주소)
├─────────────────────────┤
│ Stack │
│ (함수 지역변수) │
│ ↓ (커짐) │
├─────────────────────────┤
│ Heap │
│ (동적 할당) │
│ ↑ (커짐) │
├─────────────────────────┤
│ BSS (초기화 안 됨) │
│ static int data[1024]; │
├─────────────────────────┤
│ Data (초기화된 전역) │
│ static int x = 100; │
├─────────────────────────┤
│ Code (프로그램 코드) │
│ 이미 Flash에서 로드됨 │
└─────────────────────────┘ 0x00000000
(낮은 주소)
총 RAM 사용량:
Code + Data + BSS + Heap + Stack
= ECU 전체 메모리 사용RAM의 실제 사용
// 엔진 컨트롤 프로그램
int globalRPM = 3000; // Data (초기화된 전역)
// RAM의 Data 영역
static int rpmHistory[100]; // BSS (초기화 안 됨)
// RAM의 BSS 영역
void EngineControl_Main() {
int localRPM = 0; // Stack (로컬)
// 함수 호출할 때마다 생성
// 런타임에 메모리 할당
int* data = malloc(sizeof(int) * 1000);
// Heap (동적 할당)
// 계산 수행 (RAM에서 매우 빠름!)
localRPM = CalculateRPM();
globalRPM = localRPM;
rpmHistory[0] = localRPM;
// 메모리 해제
free(data);
}
특징:
- 모든 임시 데이터는 RAM
- 함수 호출 시 Stack에서 처리
- 동적 할당은 Heap에서 처리
- 매우 빠른 접근
- 함수 종료하면 Stack 데이터는 삭제RAM의 장단점
✅ 장점:
1️⃣ 매우 빠름
└─ CPU가 직접 접근
└─ 캐시도 효율적
2️⃣ 읽기/쓰기 자유
└─ 임시 데이터 처리 최적
3️⃣ 구조 단순
└─ 구현 간단
❌ 단점:
1️⃣ 전원 끄면 삭제
└─ 데이터 보존 불가
2️⃣ 용량 제한
└─ ECU는 작으니까
3️⃣ 전원 필수
└─ 계속 리프레시 필요
📦 ROM (Read Only Memory)이란?
정의
ROM = 부팅 코드가 저장된 읽기 전용 메모리
특징:
- 읽기만 가능 (쓰기 불가)
- 전원 끝나도 데이터 유지 (비휘발성)
- 부트로더 코드 저장
- 절대 수정되지 않음
- 제조 시점에만 한 번 쓸 수 있음ROM의 역할
ECU 부팅 순서:
전원 ON
↓
CPU 리셋
↓
ROM에서 부트로더 코드 실행 ← ROM의 역할!
↓
"어디서 메인 프로그램 로드할까?"
↓
Flash에서 메인 프로그램 로드
↓
메인 프로그램 실행 (Flash에서 RAM으로 복사)
↓
시스템 정상 작동
ROM의 부트로더 코드:
┌────────────────────┐
│ Boot Loader Code │
│ │
│ 1. 하드웨어 초기화 │
│ 2. 메모리 확인 │
│ 3. Flash 확인 │
│ 4. 프로그램 로드 │
│ 5. 점프 │
└────────────────────┘
이 코드는 절대 바뀌지 않음!
제조사가 ECU 만들 때 한 번만 쓰고 끝!ROM의 실제 내용
ROM (일반적으로 8~16KB):
┌──────────────────────────┐
│ Reset Vector │ ← CPU가 처음 실행할 주소
├──────────────────────────┤
│ Interrupt Vectors │ ← 인터럽트 핸들러 주소
├──────────────────────────┤
│ System Initialization │ ← 스택, 메모리 초기화
│ Code │
├──────────────────────────┤
│ Bootloader Main Routine │ ← Flash에서 로드
├──────────────────────────┤
│ Checksum Verification │ ← Flash 오류 확인
├──────────────────────────┤
│ Program Jump │ ← 메인 프로그램으로 점프
└──────────────────────────┘
특징:
- 고정적 (절대 바뀌지 않음)
- 매우 작음 (8~16KB)
- 매우 중요 (없으면 ECU 작동 불가)
💾 Flash (플래시 메모리)란?
정의
Flash = 프로그램 코드와 데이터를 저장하는 비휘발성 메모리
특징:
- 프로그램 코드 저장
- 전원 끝나도 유지 (비휘발성)
- 읽기 빠름 (RAM과 비슷)
- 쓰기 느림 (블록 단위)
- 프로그래밍 재작성 가능 (수백만 번)
- 용량 크지 않음 (ECU는 보통 256KB ~ 2MB)Flash의 구조
일반적인 자동차 ECU Flash:
총 1MB Flash:
┌────────────────────────────┐ 0x10000000
│ Bootloader │ 64KB
│ (프로그램 다운로드 코드) │
├────────────────────────────┤ 0x1000F000
│ Main Application │ 896KB
│ (엔진 제어, 변속 등) │
├────────────────────────────┤ 0x1000E0000
│ Calibration Data │ 32KB
│ (센서 정정값, 설정) │
├────────────────────────────┤ 0x1000F000
│ Application Data │ 8KB
│ (DTC, 주행 거리 등) │
└────────────────────────────┘ 0x10100000
용도별:
1️⃣ Bootloader (64KB)
└─ 프로그램 다운로드 메커니즘
2️⃣ Main Application (896KB)
└─ 실제 엔진 제어 프로그램
3️⃣ Calibration (32KB)
└─ 센서 정정값, 엔진맵 등
4️⃣ Application Data (8KB)
└─ DTC, 주행 거리, 설정값Flash 쓰기 과정
Flash 쓰기는 느림 (블록 단위):
Flash 프로그래밍:
1️⃣ 쓸 주소 결정
└─ 0x10010000 (Main Application 시작)
2️⃣ 블록 삭제 (Erase)
└─ 전체 64KB 블록을 0xFF로 채우기
└─ 시간: 100~500ms
3️⃣ 데이터 쓰기 (Program)
└─ 새 데이터를 블록에 씀
└─ 시간: 한 바이트당 수 마이크로초
4️⃣ 검증 (Verify)
└─ 쓰인 데이터가 맞나?
└─ 체크섬 검증
5️⃣ 완료!
└─ 새 프로그램 로드 완료
총 시간: 1~5초 (블록 크기에 따라)
비교:
RAM 쓰기: 나노초 (0.000001ms)
Flash 쓰기: 밀리초 (1ms)
차이: 1000배!Flash의 실제 사용
현대 쏘나타의 Flash 구성 예시:
Bootloader (64KB):
├─ 부팅 코드
├─ 프로그램 다운로드 루틴
└─ 플래시 드라이버
Main Application (896KB):
├─ EngineControl.c
├─ TransmissionControl.c
├─ BrakeControl.c
├─ DiagnosticServer.c
└─ ... (모든 SWC)
Calibration Data (32KB):
├─ Engine Map (RPM vs Torque)
├─ Transmission Shift Points
├─ Fuel Injection Timing
└─ Sensor Correction Values
Application Data (8KB):
├─ Odometer (주행 거리) - 1000km
├─ DTC (오류 코드) - P0117 (O2 센서)
├─ Service Interval - 10,000km
└─ System Configuration
전원 끈 후?
→ Flash의 모든 데이터 유지!
→ 다시 시동 켜면 같은 데이터 복원!
🔐 EEPROM (Electrically Erasable Programmable ROM)이란?
정의
EEPROM = 작은 데이터를 자주 읽고 쓸 수 있는 비휘발성 메모리
특징:
- 바이트 단위로 쓰기 가능 (Flash는 블록)
- 전원 끝나도 유지 (비휘발성)
- 읽기 빠름
- 쓰기는 느림 (블록이 필요 없으니 Flash보다는 빠름)
- 전기적으로 삭제 가능 (Electrically Erasable)
- 수명 제한 (100만 회 쓰기)
- 용량 작음 (ECU는 보통 4KB ~ 64KB)EEPROM vs Flash
| 특징 | EEPROM | Flash |
|------|--------|-------|
| 읽기 | 빠름 | 빠름 |
| 쓰기 | 느림 | 매우 느림 |
| 삭제 | 바이트 단위 | 블록 단위 |
| 비휘발성 | ✅ | ✅ |
| 쓰기 수명 | 100만 | 1000만 |
| 용도 | 작은 데이터 | 프로그램 |
| 가격 | 비쌈 | 저가 |
선택 기준:
- 자주 바뀌는 데이터? → EEPROM
- 큰 데이터? → Flash
- 변하지 않는 데이터? → Flash (저가)EEPROM의 실제 사용
// 연비 데이터 저장 (자주 업데이트)
EEPROM 구조 (4KB):
┌─────────────────────┐
│ Trip Odometer │ 4 bytes
│ Trip Fuel Used │ 4 bytes
│ Trip Fuel Economy │ 4 bytes
├─────────────────────┤
│ Total Odometer │ 4 bytes
│ Total Fuel Used │ 4 bytes
├─────────────────────┤
│ Maintenance Data │ 8 bytes
│ Last Service Date │ 8 bytes
├─────────────────────┤
│ Error History │ 256 bytes
│ (최근 100개 DTC) │
├─────────────────────┤
│ User Settings │ 512 bytes
│ (좌석 위치, 등) │
└─────────────────────┘
업데이트 빈도:
Trip Odometer: 매 1km마다 (매우 빈번!)
Total Odometer: 매 10km마다
Maintenance Data: 매달
User Settings: 사용자 요청 시
왜 EEPROM?
→ 자주 업데이트되므로 Flash보다는 빠르고,
→ 수명이 충분함 (100만 회 >> 매년 3만 회)
→ 비용 절감 가능EEPROM 쓰기 과정
EEPROM 쓰기 (바이트 단위):
1️⃣ 쓸 주소 결정
└─ 0x20000100 (Trip Odometer)
2️⃣ 현재 값 읽기
└─ 1000km 읽음
3️⃣ 새 값 계산
└─ 1000 + 1 = 1001km
4️⃣ EEPROM에 쓰기 (바이트 단위!)
└─ 1001을 EEPROM에 씀
└─ Flash처럼 블록 전체 삭제 안 함
└─ 시간: 밀리초 (블록보다 빠름)
5️⃣ 완료!
특징:
- 블록 단위 삭제 불필요
- 바이트만 골라서 쓰기
- Flash보다 유연함
🗄️ NVM (Non-Volatile Memory) & AUTOSAR NvM이란?
정의
NVM = Flash와 EEPROM을 통합 관리하는 소프트웨어 레이어
특징:
- Flash와 EEPROM을 하나로 관리
- 데이터 캐싱 (RAM에서)
- 비휘발성 메모리 추상화
- 일관성 보장
- 에러 처리
- 쓰기 수명 관리NVM의 필요성
문제 상황:
개발자가 직접 Flash/EEPROM 관리:
void SaveOdometer(uint32 odometer) {
// Flash 주소 직접 관리
WriteToFlash(0x20010000, &odometer, 4);
// EEPROM 주소 직접 관리
WriteToEEPROM(0x40000100, &odometer, 4);
// 에러 처리?
// 캐싱?
// 일관성?
// ... 복잡함! 😭
}
결과:
❌ 메모리 주소를 개발자가 직접 관리
❌ 에러 처리 중복
❌ 다른 파일과 주소 충돌 위험
❌ 캐싱 전략 없음
❌ 유지보수 어려움NVM의 해결책
AUTOSAR NvM 레이어 도입:
┌─────────────────────────────────┐
│ Application (개발자 코드) │
│ │
│ Rte_Call_NvM_WriteBlock(...) │
│ Rte_Call_NvM_ReadBlock(...) │
└────────────┬────────────────────┘
│
┌────────────▼────────────────────┐
│ NvM (AUTOSAR 메모리 관리) │
│ │
│ - 메모리 주소 관리 │
│ - 캐싱 (RAM) │
│ - 에러 처리 │
│ - 일관성 보장 │
│ - CRC 검증 │
└────────────┬────────────────────┘
│
┌────────────▼────────────────────┐
│ Memory Abstraction (드라이버) │
│ │
│ Fls (Flash Driver) │
│ Ea (EEPROM Abstraction) │
└────────────┬────────────────────┘
│
┌────────────▼────────────────────┐
│ 실제 메모리 │
│ │
│ Flash (프로그램) │
│ EEPROM (설정) │
└─────────────────────────────────┘NvM의 구조
AUTOSAR NvM 아키텍처:
┌───────────────────────────────────┐
│ NvM (Non-Volatile Memory) │
│ │
│ Block 0: Odometer │
│ Block 1: Service Interval │
│ Block 2: DTC History │
│ Block 3: Calibration Data │
│ ... (여러 블록) │
└───────────────────────────────────┘
각 Block의 특징:
┌──────────────────┐
│ Block Config │
├──────────────────┤
│ ID │ 블록 번호
│ Address │ Flash/EEPROM 주소
│ Length │ 크기
│ Device │ Flash 또는 EEPROM
│ CRC │ 오류 검사 방법
│ Redundancy │ 중복 저장 여부
└──────────────────┘AUTOSAR NvM 코드 예시
// AUTOSAR NvM 설정 (ARXML)
<AUTOSAR>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>NvM_Config</SHORT-NAME>
<ELEMENTS>
<!-- Block 0: Odometer -->
<NVM-BLOCK>
<SHORT-NAME>OdometerBlock</SHORT-NAME>
<BLOCK-ID>0</BLOCK-ID>
<BLOCK-LENGTH>4</BLOCK-LENGTH>
<BLOCK-ADDRESS>0x20010000</BLOCK-ADDRESS>
<DEVICE>Flash</DEVICE>
<CRC-TYPE>CRC32</CRC-TYPE>
</NVM-BLOCK>
<!-- Block 1: Service Interval -->
<NVM-BLOCK>
<SHORT-NAME>ServiceIntervalBlock</SHORT-NAME>
<BLOCK-ID>1</BLOCK-ID>
<BLOCK-LENGTH>4</BLOCK-LENGTH>
<BLOCK-ADDRESS>0x40000000</BLOCK-ADDRESS>
<DEVICE>EEPROM</DEVICE>
<CRC-TYPE>CRC16</CRC-TYPE>
</NVM-BLOCK>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>
// 개발자 코드 (간단함!)
void SaveOdometer(uint32 odometer) {
// NvM에 데이터 요청
Rte_Call_NvM_WriteBlock(
0, // Block 0
&odometer // 데이터
);
// 끝! NvM이 모든 것 처리
}
void ReadOdometer(uint32* odometer) {
// NvM에서 데이터 읽음
Rte_Call_NvM_ReadBlock(
0, // Block 0
odometer // 데이터 저장 위치
);
// 끝! NvM이 모든 것 처리
}
NvM의 역할:
1️⃣ 주소 관리
└─ 개발자는 Block ID만 사용
└─ 실제 주소는 NvM이 관리
2️⃣ 캐싱
└─ 데이터는 먼저 RAM 캐시에 들어감
└─ 나중에 배치로 Flash/EEPROM에 씀
3️⃣ 에러 처리
└─ CRC 검증
└─ 검증 실패하면 기본값 복원
4️⃣ 일관성 보장
└─ 여러 프로세스가 동시에 접근 시 충돌 방지
결과: 개발자는 간단하게 사용!📊 메모리 완벽 비교
| 특징 | RAM | ROM | Flash | EEPROM | NvM |
|------|-----|------|----------|--------|-----|
| 용량 | 중 | 작음 | 큼 | 작음 | 가변 |
| 휘발성| ✅ | ❌ | ❌ | ❌ | ❌ |
| 용도 | 임시 | 부팅 | 프로그램 | 설정 | 통합 |
| 생명 | 임시 | 영구 | 반영구 | 반영구 | 반영구 |
| 가격 | 저가 | 저가 | 저가 | 중가 | 소프트웨어 |
선택 기준:
- 빠르고 임시? → RAM
- 부팅? → ROM
- 큰 프로그램? → Flash
- 작은 설정? → EEPROM
- 체계적 관리? → NvM (AUTOSAR)🔌 실무 시나리오
시나리오 1: ECU 정상 부팅
타임라인:
0ms: 전원 ON
CPU 리셋
↓
ROM에서 부트로더 실행 ← ROM의 역할
100ms: 부트로더 완료
Flash에서 메인 프로그램 로드
프로그램을 RAM으로 복사 ← Flash 사용
↓
메인 프로그램 실행 (RAM에서) ← RAM의 역할
150ms: 시스템 정상 작동
├─ 임시 데이터 → RAM (빠름)
├─ 오류 로그 → EEPROM (오래 보존)
└─ 설정값 → NvM (자동 관리)
특징:
- ROM: 부팅만 담당 (작고 중요)
- Flash: 프로그램 저장 (크고 고정)
- RAM: 실행 중 데이터 처리 (빠름)
- EEPROM/NvM: 설정값 보존 (영구)시나리오 2: 오류 발생 후 전원 OFF/ON
상황: 주행 중 O2 센서 오류 발생
오류 발생 (전원 ON 상태):
1️⃣ O2 센서 값 이상 감지
└─ globalErrorCode = P0117 (RAM에 저장)
2️⃣ 오류 로그 기록
└─ DiagnosticServer_WriteErrorLog()
└─ EEPROM/NvM에 저장 (비휘발성)
3️⃣ 오류 표시
└─ 대시보드에 경고등 표시
전원 OFF (3시간 후):
1️⃣ RAM의 모든 데이터 삭제
└─ globalErrorCode = 0 (사라짐)
2️⃣ Flash, EEPROM의 데이터 유지
└─ DTC P0117 유지 (EEPROM에 저장)
3️⃣ NvM에서 오류 히스토리 유지
└─ "2024-12-19 10:30 - P0117 발생"
다시 전원 ON:
1️⃣ 부팅 → ROM → Flash → RAM
└─ 임시 데이터는 초기화
2️⃣ NvM 초기화
└─ EEPROM에서 오류 히스토리 로드
└─ 이전 오류 코드 복원
3️⃣ 진단기 스캔
└─ "이전에 P0117이 발생했네요?"
└─ → EEPROM에서 읽은 데이터!
결론:
- 현재 오류 (임시): RAM에서 사라짐
- 과거 오류 (히스토리): EEPROM에서 유지시나리오 3: 프로그램 업데이트
상황: 새로운 엔진 제어 코드 다운로드
프로그래밍 전:
Flash 구조:
├─ Bootloader (64KB) - 변함없음
├─ Main App v1.0 (896KB)
├─ Calibration (32KB) - 변함없음
└─ App Data (8KB) - 변함없음
프로그래밍 과정:
1️⃣ 진단기 연결
└─ Bootloader 실행
2️⃣ 새 프로그램 다운로드
└─ 네트워크로 새 Main App v2.0 전송
3️⃣ Main App 영역 삭제 + 쓰기
└─ 블록 삭제: 896KB 전부 0xFF로 채우기 (시간 소요)
└─ 프로그램 쓰기: v2.0 프로그램 씀
└─ 검증: CRC 확인
4️⃣ 재부팅
└─ ROM → Bootloader → v2.0 실행
프로그래밍 후:
Flash 구조:
├─ Bootloader (64KB) - 변함없음
├─ Main App v2.0 (896KB) ← 새로 업데이트!
├─ Calibration (32KB) - 변함없음
└─ App Data (8KB) - 변함없음 (오류 코드는 유지!)
특징:
- ROM: 절대 변함없음 (부트로더)
- Flash의 Main App: 업데이트됨 (느림)
- Calibration, App Data: 유지됨 (중요!)
- 오류 히스토리도 유지 (진단에 도움)💡 실무 팁
메모리 관리 Best Practice
1️⃣ 메모리 선택 가이드
빠른 데이터 처리?
└─ RAM (CPU 직접 접근)
부팅 코드?
└─ ROM (절대 변함없음)
프로그램 코드?
└─ Flash (업데이트 가능)
자주 바뀌는 설정?
└─ EEPROM (바이트 단위 쓰기)
체계적 관리 필요?
└─ NvM (AUTOSAR)
2️⃣ 성능 최적화
// ❌ 나쁜 예: Flash에 자주 쓰기
for (int i = 0; i < 1000; i++) {
WriteToFlash(address, &data[i], 4); // 매번 느림!
}
// ✅ 좋은 예: 배치 처리
void* buffer = malloc(1000 * 4);
memcpy(buffer, data, 1000 * 4);
WriteToFlash(address, buffer, 1000 * 4); // 한 번만!
3️⃣ 데이터 무결성
// CRC 검증
uint32 stored_crc = ReadFromFlash(crc_address);
uint32 calculated_crc = CalculateCRC(data, length);
if (stored_crc != calculated_crc) {
// 데이터 손상!
RestoreDefaultValue(); // 기본값 복원
}
4️⃣ 쓰기 수명 고려
// EEPROM 쓰기 수명: 100만 회
// 매일 10회 → 27만 년 (무관)
// 매초 10회 → 3년 (주의!)
if (critical_operation) {
// EEPROM 대신 NvM 사용
// 또는 쓰기 최소화
}🎯 면접 예상 질문
Q1: "RAM과 Flash의 가장 큰 차이는?"
A: "RAM은 매우 빠르지만 전원을 끄면 모든 데이터가 삭제됩니다.
Flash는 느리지만 전원을 꺼도 데이터가 유지됩니다.
ECU는 RAM에서 프로그램을 실행하고,
Flash에서는 코드와 설정을 보관합니다."
Q2: "ROM은 왜 필요한가요?"
A: "ROM에는 부트로더 코드가 저장되어 있어서,
전원을 켜면 가장 먼저 ROM의 코드를 실행해 시스템을 초기화합니다.
ROM은 절대 변하지 않으므로 안정성이 매우 높습니다."
Q3: "EEPROM과 Flash의 차이는?"
A: "Flash는 블록 단위로만 삭제할 수 있어서 큰 프로그램 저장에 최적화되고,
EEPROM은 바이트 단위로 쓸 수 있어서 작은 설정값을 자주 업데이트하기에 좋습니다.
가격은 Flash가 더 저렴합니다."
Q4: "NvM은 뭐죠?"
A: "AUTOSAR의 Non-Volatile Memory Manager로,
Flash와 EEPROM을 하나의 인터페이스로 통합 관리합니다.
개발자는 Block ID로만 접근하고,
NvM이 실제 주소, 캐싱, 에러 처리를 모두 담당합니다."
Q5: "ECU의 메모리가 가득 차면?"
A: "RAM이 가득 차면 스택 오버플로우로 시스템 충돌이 발생합니다.
Flash가 가득 차면 새 프로그램을 다운로드할 수 없습니다.
따라서 메모리 풀 검사(Watchdog)와 정기적인 모니터링이 필수입니다."📌 핵심 정리
| 항목 | RAM | ROM | Flash | EEPROM | NvM |
|---|---|---|---|---|---|
| 역할 | 실행 | 부팅 | 저장 | 설정 | 관리 |
| 속도 | ⚡⚡⚡ | ⚡⚡ | ⚡⚡ | ⚡ | ⚡ |
| 휘발성 | ✅ | ❌ | ❌ | ❌ | ❌ |
| 용량 | 512KB | 8~16KB | 256KB~2MB | 4~64KB | 가변 |
| 수명 | 무제한 | 무제한 | 1000만 회 | 100만 회 | 관리됨 |
| 용도 | 데이터 | 부팅 | 코드 | 데이터 | 통합 |
마치며
다시 한번 정리 해볼게요
“껐다 켜도 남아 있으면 ROM, 끄면 사라지면 RAM”
ROM : 전원 꺼도 유지되는 메모리의 “통칭”입니다.
사실 ROM은 물리적인 한 종류가 아니죠
“비휘발성 메모리”를 그냥 묶어서 부르는 말이라는 것을 기억해야합니다
실제로는 Flash / EEPROM이 ROM 역할을 함
📌 ROM = 개념 이름
Flash vs EEPROM vs ROM를 자동차 SW 개발자 관점 요약해보자면
Flash = 코드
EEPROM = 값
ROM = 둘 다 포함하는 개념
[ RAM ]
↑ ↓ (Read / Write)
[ NvM ]
↓
[ Fee / Ea ]
↓
[ Flash / EEPROM ]애플리케이션은 절대 Flash / EEPROM 직접 안 관여합니다
NvM이 다 중간에서 관리합니다
NVM의 “매니저”
- RAM ↔ 비휘발성 메모리 연결
- Block 단위 관리
- CRC, default, write retry, redundancy 처리
- 진단/안전 요구사항 여기서 만족
NvM_ReadBlock(NVM_BLOCK_SEAT_POS, &SeatPosition);
NvM_WriteBlock(NVM_BLOCK_SEAT_POS, &SeatPosition);- 왜 NvM을 쓰냐? (ISO 26262 관점)
NvM이 해주는 것들:
- CRC 체크 → 데이터 무결성
- Default 값 복구 → 깨졌을 때 안전 상태
- Write retry
- Block 상태 관리 (Valid / Invalid)
- Redundant block (이중화)
그래서 안전 요구사항은 NvM으로 걸림
“EEPROM 직접 쓰지 말 것”
“Application은 NvM만 사용하고,
NvM이 Fee/Ea를 통해 Flash나 EEPROM에 저장한다.”
'임베디드 기초' 카테고리의 다른 글
| 채터링(Chattering) 완벽 정리: 원인, 문제점, 디바운싱 실무 가이드 (0) | 2026.01.07 |
|---|---|
| 포인터와 배열 - 입문자가 반드시 알아야 할 관계 (0) | 2025.12.29 |
| 실무자가 반드시 알아야 할 Static, Extern, Global 변수의 완벽한 차이 (3) | 2025.12.19 |
| 개발자가 반드시 알아야 할 Compile, Linking, Build, Rebuild, GenerateAll의 완벽한 차이 (0) | 2025.12.19 |
| 🔗 링크(Link)란 무엇인가? (0) | 2025.12.14 |
