코딩탐사선

x86 Assembly - 데이터 이동, 산술연산, 논리연산

leecrossun — Sun, 26 Oct 2025 16:26:17 +0900

어셈블러는 어셈블리어를 기계어로 치환해주는 프로그램이다

이와 반대로 리버스 엔지니어링으로 개발된 역어셈블러는 기계어를 어셈블리어로 역치환해준다

일반적으로, 아키텍처별로 문법이 상이하다

아키텍처가 같더라도 어셈블러 내 정의에 따라 문법이 다를 수도 있다

대표적인 아키텍처인 Intel사의 x86 기준으로 NASM(Netwide Assembler)의 문법을 간단히 정리해보자

외운다기 보다는 이후 실습을 하면서 자연스럽게 체화를 하면 된다

비교적 익숙한 C언어를 어셈블리어로 변환해주는 사이트가 있다

아래 사이트를 활용하면, 어셈블러 문법을 C언어와 비교해가며 이해하는 데 도움이 된다

https://gcc.godbolt.org/

Compiler Explorer

gcc.godbolt.org

명령어 종류

NASM의 대략적인 명령어 종류는 다음과 같다

데이터 이동	mov, lea
산술 연산	inc, dec, add, sub, mul, imul
논리 연산	and, or, xor, not
비교	cmp, test
분기	jmp, je, jg
스택	push, pop
프로시져	call, ret, leave
시스템 콜	syscall

피연산자

피연산자 종류에는 상수, 레지스터 그리고 메모리 주소가 있다

즉시값(Immediate value) : 코드 자체에 직접 포함된 고정된 상수값 (0x1242, 0xffff 등)
레지스터 : 레지스터 (rax, rbx 등) 안에 들어있는 값
메모리 주소 : 메모리 주소값, 레지스터에 저장된 메모리 주소값,
(C언어 포인터 느낌이다. 레지스터 -> 메모리 -> 참조값)

메모리 주소의 경우에는 [ ] (대괄호) 안에 넣어서 표현한다

그리고 대괄호 앞에 참조 메모리의 크기를 지정하는 PTR이 올 수 있다

필수 사항은 아니지만 오류 방지차원에서 명확한 크기를 명시하는 편이 좋다

mov [rdi], eax  ; (X) 오류 발생 가능: 몇 바이트를 가져올 것인지 크기 지정이 명확하지 않음
mov DWORD PTR [rdi], eax  ; (O) 명확한 크기 지정 (0x8048000 위치의 메모리를 4byte 참조)

데이터 이동

데이터 이동 연산은 크게 두가지로 나뉜다

직접 값을 복사하여 이동시키는 방식(mov) 과 메모리 주소를 가져오는 방식(lea) 이 있다

대부분의 명령어 연산 문법은 [명령어] [목적지 피연산자] [소스 피연산자] 구조를 이룬다

데이터 이동 연산도 위 구조를 따른다

mov

mov연산은 메모리에 직접 접근하여 담긴 값 자체를 복사하여 이동시킨다

int val = arr[1]

C언어로 표현하면 위와 같다

위 코드는 배열의 첫번째 메모리에 직접 접근해서 해당 값을 int 변수에 저장한다

어셈블리어의 mov연산의 원리도 동일하다

mov rbx, &arr; rbx = arr의 주소
mov rcx, 2; 배열의 인덱스
mov rax, [rbx + rcx * 4]; arr[2]에 직접 접근하여 갑을 rax에 할당한다

lea

lea연산은 메모리에 접근하지 않고 메모리 주소를 가져오는 방식이다

즉, 유효주소 EA(Effective Address)를 저장하는 것이다

C언어의 포인터 개념이라고 생각하면 된다

int *ptr = &arr[1];

어셈블리어로 표현하면 다음과 같다

mov rbx, &arr; rbx = arr의 주소
mov rcx, 1; 배열의 인덱스
lea rax, [rbx + rcx * 4]; arr[1]의 주소를 rax에 대입한다

산술연산

add(덧셈), sub(뺄셈) 연산도 기본 연산 구조 [명령어] [목적지 피연산자] [소스 피연산자]를 그대로 따른다

add eax, 1; eax값에 1을 더한다
sub ecx, edx; ecx에서 dex를 뺀다

곱셈은 조금 다르다

우선, 피연산자를 레지스터에 저장하고 곱셈을 수행할 때 해당 값을 꺼내서 사용한다

(주로 AL, AX, EAX, RAX 레지스터를 사용한다)

피연산자의 크기에 따라 연산 결과의 크기가 다르므로, 결과값이 저장되는 레지스터가 다르다

(e.g., EAX * ESI (32bit * 32bit) 연산은 결과값이 최대 64bit이므로 상위 32bit, 하위 32bit 나누어야 한다)

그리고, 부호가 없는 mul 연산과 부호가 있는 imul 연산으로 나뉜다

mul

8bit 연산

AL 레지스터의 값과 src 피연산자의 값 곱하기
두 숫자의 연산 결과는 최대 16비트 이기때문에, AX (16비트) 레지스터에 보관

section .data
    num1 db 5
    num2 db 3

section .text
    global _start

_start:
    mov al, [num1]  ; AL 레지스터에 첫 번째 피연산자(5)를 로드
    mul byte [num2] ; AL과 num2(3)를 곱함. 결과 15(0x0F)가 AX에 저장

    ; 프로그램 종료
    mov eax, 1
    xor ebx, ebx
    int 0x80

16bit 연산

AX 레지스터의 값과 src 피연산자의 값 곱하기
곱한 결과의 상위 16비트는 DX 레지스터, 하위 16비트는 AX 레지스터에 보관

mov ax, 0x2000
mov bx, 0x0100
mul bx          ; DX:AX = AX * BX = 0x200000. DX=0x0002, AX=0x0000

32bit 연산

AX 레지스터의 값과, src 피연산자의 값 곱하기
곱한 결과의 상위 32비트는 EDX 레지스터, 하위 32비트는 EAX 레지스터에 보관

mov eax, 1000
mov ebx, 50
mul ebx         ; EDX:EAX = EAX * EBX. EAX = 50000, EDX = 0

64bit 연산

RAX 레지스터의 값과 src 피연산자의 값을 곱하기
곱한 결과의 상위 64비트는 RDX 레지스터, 하위 64비트는 RAX 레지스터에 보관

section .data
    num1 dq 20000000000      ; 64비트 정수, 십진수 20,000,000,000
    num2 dq 3                ; 64비트 정수, 십진수 3

section .text
    global _start

_start:
    ; 첫 번째 피연산자를 rax에 로드
    mov rax, [num1]      ; rax = 20,000,000,000

    ; 두 번째 피연산자를 rbx에 로드
    mov rbx, [num2]      ; rbx = 3

    ; rax와 rbx의 값을 곱함 (unsigned)
    ; 결과는 rdx(상위 64비트):rax(하위 64비트)에 저장
    mul rbx              ; rdx:rax = 60,000,000,000

    ; 프로그램 종료 (Linux)
    mov rax, 60          ; sys_exit 호출
    mov rdi, 0           ; 종료 코드
    syscall

imul (signed 연산)

imul은 부호가 있는 signed 정수에 대한 곱셈을 수행한다

mul과는 다르게 피연산자가 최대 3개까지 올 수 있다

imul <source>; mul 연산과 유사하게 동작
imul <destination>, <source>; 두 피연산자를 곱한 결과를 첫번째 연산자에 저장
imul <destination>, <source>, <immediate>; 두번째, 세번째 피연산자를 곱한 결과를 첫번째 피연산자에 저장

mov ax, 10  ; AX 레지스터에 10을 저장한다
mov bx, 5   ; BX 레지스터에 5를 저장한다
imul ax, bx, 7  ; AX는 BX * 7의 결과를 저장한다
                ; AX에는 5 * 7 = 35 (0023h)가 저장된다

만약 연산 결과가 목적지 피연산자의 크기를 초과한다면 CF(Carry Flag)와 OF(Overflow Flag)를 1로 설정한다

(이상 없을 시에는 0)

INC, DEC

inc와 dec는 피연산자의 값을 1씩 증가/감소 시키는 연산자이다

mov ax, 10;
inc ax; ax레지스터의 값이 1 증가한다 (11)

mov bx, 10;
dec bx; bx레지스터의 값이 1 감소한다 (9)

논리연산

논리연산자에는 and, or, xor, not 이 있다

각각 bit 논리연산을 수행한다

연산자	결과값	용도
and	두 bit가 모두 1이면 1, 아니면 0	비트마스킹
or	두 bit중 하나라도 1이 있으면 1 둘다 0이면 0	특정 비트 set
xor	두 bit가 다르면 1 두 bit가 같으면 0	비트 토글 및 암호화
not	비트반전	Complement 연산

section .data
    val1 db 0xFF  ; 이진수로 1111 1111
    val2 db 0x0F  ; 이진수로 0000 1111
    result db 0

section .text
    global _start

_start:
    mov al, [val1]
    xor al, [val2]    ; al과 val2의 값을 XOR 연산하여 al에 저장한다 (결과: 0xF0, 이진수 1111 0000)
    mov [result], al

비트 기본 연산을 수행하는 연산자이므로 까다로운 부분은 없다

논리연산까지 정리하고 나니 분량이 길어져서 우선 여기서 끊고

다음글에서 남은 연산(비교연산, 분기연산 등) 들을 정리해야겠다

참고자료

- https://en.wikipedia.org/wiki/X86_assembly_language

x86 assembly language - Wikipedia

From Wikipedia, the free encyclopedia Family of backward-compatible assembly languages x86 assembly language is a family of low-level programming languages that are used to produce object code for the x86 class of processors. These languages provide backwa

en.wikipedia.org

- https://docs.oracle.com/cd/E19641-01/802-1948/802-1948.pdf

- https://www.nasm.us/docs/3.01/

NASM - The Netwide Assembler

www.nasm.us

Linux Memory Layout

leecrossun — Sun, 26 Oct 2025 12:53:18 +0900

Process Memory Structure

위 그림은 프로세스 메모리 구조이다

간혹 주소 0번지가 가장 위에 표현되어서 스택이 아래에 있는 자료도 있는데,

개인적으로, '스택이 아래로 자란다' 라는 표현 때문에 (높은주소->낮은주소) 를 의미해서 그림에서도 위에서 아래로 자라는 표현 방식이 더 직관적으로 와닿았다

프로세스가 실행될 때 각 프로세스는 독립된 5개의 메모리 공간(세그먼트)을 할당받는다

이 메모리 공간은 각각 목적에 따라 여러 영역으로 나뉜다

각 영역은 높은 주소부터 차례로

스택, 힙, BSS, 데이터, 코드 세그먼트로 나뉜다

'낮은 주소(코드) 에서 가장 높은 주소(스택) 로 갈수록 휘발성이 강하다' 고 생각하면 이해하기 좋다

왜 나누냐면, 용도에 맞게 각 영역에 권한을 부여하기 위해서 (rwx)

CPU 는 각 영역의 권한에 맞는 행위만 할 수 있다

예를 들어, 코드가 저장되는 세그먼트는 임의로 접근해서 WRITE 을 해서는 안되고, 변수가 저장되는 세그먼트는 EXECUTE를 제한해서 임의 코드가 실행되는 것을 막아야 한다

좀더 자세한 내용을 알아보자

코드 세그먼트 (=텍스트 세그먼트)

코드 세그먼트는 기계어 코드를 저장하고, CPU가 프로그램 실행 시 여기에 있는 기계 코드를 메모리에 올린다.

코드는 읽고 실행을 해야하지만 직접 접근해서 변경해서는 안되기 때문에 쓰기 권한은 제한되어 있다

읽기 권한 READ (O)

쓰기 권한 WRITE (X) <- 코드 위변조 방지

실행 권한 EXECUTE (O)

section .data
    message db "Hello, World!", 0xA
    message_len equ $ - message

section .text // 이 아래에 어셈블리어 코드 입력하면 컴파일 시 텍스트 세그먼트에 기계어 코드가 옴
    global _start

_start:
    mov rax, 1
    mov rdi, 1
    mov rsi, message
    mov rdx, message_len
    syscall

    mov rax, 60
    xor rdi, rdi
    syscall

데이터 세그먼트

컴파일 시점에 값이 정해진 전역변수, 전역상수가 저장된다

쓰기가 가능한 data 세그먼트와 쓰기가 불가능한 rodata (read-only) 세그먼트가 있는데,

실행 도중 변경 가능한 전역 변수는 data 세그먼트에, 그렇지 않은 전역 상수는 rodata 세그먼트에 저장된다

읽기 권한 READ (O)

쓰기 권한 WRITE (O/X)

실행 권한 EXECUTE (X)

int data_num = 31337;                       // 전역변수 (data)
char data_rwstr[] = "writable_data";        // 전역변수 (data)
const char data_rostr[] = "readonly_data";  // const 전역상수 (rodata)
char *str_ptr = "readonly";  // 포인터 전역변수 (data), 문자열 상수 (rodata)

int main() { ... }

BSS 세그먼트 (Block Started by Symbol 세그먼트)

컴파일 시점에 값이 정해지지 않은 전역변수가 위치하는 메모리 영역이다

(e.g., 개발자가 선언만 하고 초기화하지 않은 전역 변수)

프로그램 실행 시 모두 초기값 0으로 초기화된다

읽기 권한 READ (O)

쓰기 권한 WRITE (O)

실행 권한 EXECUTE (X)

힙 세그먼트

실행 중에 동적으로 할당되는 메모리이며, 스택과는 반대방향으로 자란다

Linux의 sys_brk, mmap 시스템콜로 힙 세그먼트를 관리할 수 있다

C언어에서 malloc(), calloc() 과 같은 동적 할당 함수를 통해 할당받는 메모리에 해당한다

(이 동적 할당 함수도 결국 내부적으로 위 Linux 시스템콜을 사용하는 것이다)

읽기 권한 READ (O)

쓰기 권한 WRITE (O)

실행 권한 EXECUTE (X)

int main() {
  int *heap_data_ptr =
      malloc(sizeof(*heap_data_ptr));  // 동적 할당한 힙 영역의 주소를 가리킴
  *heap_data_ptr = 31337;              // 힙 영역에 값을 씀
  printf("%d\n", *heap_data_ptr);  // 힙 영역의 값을 사용함
  return 0;
}

스택 세그먼트

함수의 매개변수, 지역변수등 임시로 할당되는 변수들이 실행 중에 저장되는 공간이다

이 변수들은 함수가 호출될 때 생성되었다가 반환될 때 해제된다

함수가 언제 호출되고 해제될 지 실행 흐름을 예측하는 것은 불가능하다

즉, 스택 프레임 크기는 미리 계산할 수 없다

그러므로, 프로세스 시작 시 스택 세그먼트를 최소 할당하고, 부족하면 이를 확장해준다

높은주소에서 낮은 주소로 확장된다 (스택은 '아래로 자란다' 라는 표현이 이 의미)

어셈블리어에서는 함수의 에필로그와 프롤로그에서 각각 직접 스택 프레임을 만들고 해제한다

프로세스 동작 중에 할당되고 사용되므로 READ, WRITE 권한이 모두 허용된다

다만, 실행 권한은 제한된다

초기에는 실행권한이 허용되었으나, 임의 코드 실행을 막기 위해 NX(Non-Executable) 보호기법이 등장한 이후 실행 권한을 없앴다

읽기 권한 READ (O)

쓰기 권한 WRITE (O)

실행 권한 EXECUTE (X) <- NX 보호기법 적용

// GCC Compiler, x86 assembly

// 함수 프롤로그 (스택 프레임 생성)
push ebp // 베이스 포인터를 스택에 push
mov ebp, esp // 베이스 포인터를 현재 스택 포인터의 주소 (esp, stack 상단) 으로 설정
sub esp, 0x100 // 현재 스택 포인터의 주소로부터 일정 크기만큼 감소 (공간 확보)

// 함수 에필로그 (스택 프레임 정리)
mov esp, ebp // 베이스 포인터를 esp로 옮김 (프롤로그 호출 시점의 스택 포인터)
pop ebp // 베이스 포인터 pop
ret // 함수 호출 전으로 리턴
// -> leave; ret; 도 동일한 동작 수행

힙과 스택이 반대로 자라는 이유?

두 세그먼트 모두 확장성있어 프로세스 실행 도중 가변적으로 크기가 변한다

만약 같은 방향으로 자라면 확장 과정에서 서로 영역을 침범하여 충돌할 수 있다

각각 시작을 반대쪽 끝에 위치시키고 자라게 하면 최대한 충돌을 피하면서 자유롭게 확장할 수 있다

최종 정리

세그먼트	역할	권한	저장 데이터
스택	임시 변수	R, W	지역변수, 매개변수
힙	실행 중 동적 할당 영역	R, W	동적 할당 함수 (malloc, calloc)로 할당받는 메모리
BSS	초기화되지 않은 데이터	R, W	초기화되지 않은 전역변수
데이터	초기화된 데이터	R, (W - 전역변수만)	초기화된 전역변수, 전역상수
코드	실행가능한 코드	R, E	함수 코드

참고 자료

- https://unix.stackexchange.com/questions/610444/the-structure-of-the-virtual-memory-of-a-linux-process

the structure of the virtual memory of a Linux process

I'm reading a textbook which shows virtual memory as: Linux also maps a set of contiguousvirtual pages (equal in size to the total amount of DRAM in the system) to the corresponding set of contiguous

unix.stackexchange.com

- https://www.geeksforgeeks.org/dsa/stack-vs-heap-memory-allocation/

Stack vs Heap Memory Allocation - GeeksforGeeks

Your All-in-One Learning Portal: GeeksforGeeks is a comprehensive educational platform that empowers learners across domains-spanning computer science and programming, school education, upskilling, commerce, software tools, competitive exams, and more.

www.geeksforgeeks.org

- 드림핵 강의

기초부터 다시 차근차근 정리

leecrossun — Sun, 26 Oct 2025 11:55:04 +0900

기존에 드림핵을 비롯하여 여러 자료를 취합하면서 개인적으로 공부하면서 노션에 정리해두었던 내용들을 더 다듬고 있다

컴퓨터 공학 기초내용이나 포너블, 보안 실습 내용들이 주가 될 것이다

기본적인 이야기이지만 그만큼 정확히 숙지하고 복습을 하는 차원에서 조금씩 업로드해보려고 한다

원래 노션에는 핵심 키워드 위주로 정리를 해놨었는데, 블로그에는 줄글로 풀어적으려고 한다

이런 개념적인 내용은 뭔가 내 언어로 설명을 해놓아야 오래 남는 느낌이기도 하고 보는사람 입장에서도 더 이해가 잘 될 것 같다

정보보안 관련 레퍼런스 : 기술블로그, 포럼, 기사, 유튜브 등

leecrossun — Tue, 27 May 2025 17:09:18 +0900

매번 찾아보기 번거로워서 정리합니다

주기적 업데이트 예정, 추천받으면 바로 리스트 추가 가능

이런건 공부느낌보다는 재밌게 보고 싶어서 조금 말랑말랑한 사이트를 선호한다

계속 손이 가는 사이트는 볼드처리

[ 기술 블로그 (기업) ]

레퍼런스	URL	비고
스모크스크린	https://www.smokescreen.io/blog/	보안 리서치 (깔끔하고 쉽게 설명함)
PortSwigger (Burp Suite 개발사)	https://portswigger.net/research	보안 리서치 (리서치 퀄리티 굿. 깔끔하다)
구글 TAG	https://blog.google/threat-analysis-group/	보안 리서치 (TTS 제공)
이스트시큐리티	https://blog.alyac.co.kr/	[국내] 위협분석
안랩	https://asec.ahnlab.com/ko/	최신 위협분석
에스투더블유	https://medium.com/s2wblog	위협분석
시스코 TALOS	http://blog.talosintelligence.com	위협분석
카스퍼스키	https://www.kaspersky.com/blog/	위협분석
맨디언트	https://m.blog.naver.com/mandiantkorea?tab=1	위협분석
이글루코퍼레이션	https://www.igloo.co.kr/security-information/category/security/page/1/	보안 리서치
윈스	https://www.wins21.com/kor/promotion/information.html	보안 동향, 기사
SK 쉴더스	https://www.skshieldus.com/kor/blog.do	[국내] 보안 리서치
파이오링크	https://www.piolink.com/kr/service/Security-Analysis.php	[국내] 위협분석
팔로알토 Unit42	https://unit42.paloaltonetworks.com/	보안 리서치
금융보안원	https://www.fsec.or.kr/bbs/244	[국내] 위협 보고서
포티넷	https://www.fortiguard.com/threat-signal-report	위협분석
체크포인트	https://research.checkpoint.com/	위협분석
크라우드스트라이크	https://www.crowdstrike.com/blog/category/threat-intel-research/	보안 리서치
리버싱랩	https://www.reversinglabs.com/blog	보안 리서치
LG CNS	https://www.lgcns.com/blog/cns-tech/security/	[국내] 보안동향
78리서치랩	https://blog.78researchlab.com/7dbd4b4f-54e7-44f4-906d-1b73fc8dcd12	[국내] 취약점
티오리	https://blog.theori.io	취약점
하임시큐리티	https://blog.hayyimsecurity.com/	취약점
구글 Project Zero	https://googleprojectzero.blogspot.com/	취약점
카이스트 CSRC	https://csrc.kaist.ac.kr/blog/	기술공유
넷마블	https://netmarble.engineering	기술공유
코드벡터	https://codevector-techlab.notion.site/	기술공유
스틸리언	https://ufo.stealien.com/	[국내] 기술공유
라온화이트햇	https://core-research-team.github.io/	[국내] 기술공유
에이치엠컴퍼니	http://hmcom.co.kr/news/news2	[국내] 기술공유
안드로이드	https://source.android.com/docs/security?hl=ko	기술공유
쏘마	https://tech.somma.kr/	[국내] 기술공유

[ 기술 블로그 (개인) ]

레퍼런스	URL	비고
James Forshaw	https://www.tiraniddo.dev/	Windows, 권한상승 등
Ivan Fratric (Google Project Zero)	https://ifsec.blogspot.com/	브라우저, Fuzzing 등
Orange Tsai	https://blog.orange.tw/
Liveoverflow	https://liveoverflow.com/ https://www.youtube.com/c/LiveOverflow	해킹, CTF

[ 포럼 & 최신 뉴스 & 취약점 ]

레퍼런스	URL	비고
Reddit - netsec	https://www.reddit.com/r/netsec/	최신 소식, 동향
Reddit - cybersecurity	https://www.reddit.com/r/cybersecurity/	최신 소식, 동향
Stackexchange - Information Security	https://security.stackexchange.com/	Q&A 방식 커뮤니티
Exploit Database	https://www.exploit-db.com/	취약점 코드 공유
arXive.org - Computer Security	https://arxiv.org/list/cs.CR/recent	최신 논문 (저널이나 학회보다 빠름)
CVE Details	https://www.cvedetails.com/	공개 취약점 데이터베이스
BlackHat Community	https://www.blackhat.com/	컨퍼런스
Defcon	https://forum.defcon.org/	컨퍼런스
NetworkChuck	https://www.youtube.com/@NetworkChuck/videos	유튜브 채널 (가볍게 밥친구)
IBM Technology	https://www.youtube.com/@IBMTechnology/featured	IBM 공식채널 (짧지만 깔끔하고 알차다. AI 관련 영상도 재밌음. 순수재미 굿. 밥친구)
KISA 보안 취약점 정보 포털	https://knvd.krcert.or.kr/index.do	[국내] 취약점 리포트, 보안 공지
보안뉴스	https://www.boannews.com/	[국내] 보안 기사

CAN normal mode

leecrossun — Sat, 1 Mar 2025 20:41:34 +0900

CAN normal mode Introduction

CAN normal mode 를 사용하여 두 개의 노드 연결
노드 1(N-1)과 노드 2(N-2) 두 개의 보드 필요

N1은 1초마다 LED 번호를 CAN 데이터 프레임으로 N2에 전송
- 이를 위해 타이머를 사용하여 1초마다 인터럽트를 발생시키고, 인터럽트 핸들러에서 N1에서 N2로 데이터를 전송
N2는 수신된 메시지에 따라 해당하는 LED ON
- N2 보드에 연결된 4개의 외부 LED(LED1, LED2, LED3, LED4)가 각각 다른 GPIO 핀에 연결
N1은 또한 4초마다 리모트 프레임을 보내 2바이트 데이터를 요청
- N2는 리모트 프레임을 수신한 후, 2바이트 데이터를 데이터프레임으로 N1에 응답
- N1은 데이터를 수신하고 화면에 표시

CAN normal mode Exercise - Tx

메인 코드 (main.c)

GPIO_Init, UART2_Init, TIMER6_Init, CAN1_Init, Filter_config는 이전과 동일하게 설정
새로운 부분은 TIMER6_Init이며, 타이머 핸들을 설정하여 1초 간격으로 타이머가 동작하도록 구성
CAN1_Init에서 Loopback 모드를 Normal 모드로 변경
CAN bit timing은 500Kbps로 설정, 이후 1Mbps로 변경 테스트 예정
Filter Config는 현재 변경 없음, 이후 특정 프레임을 필터링할 예정
CAN_Start 실행 후, CAN TX 및 CAN RX 처리는 타이머 인터럽트 핸들러에서 수행

타이머 인터럽트 핸들러 (IT.c)

Timer6 IRQ Handler → 타이머 주기 경과 콜백(Timer Period Elapsed Callback)을 트리거
1초마다 CAN TX 실행 (CAN1_TX 함수 호출)

CAN TX 구현

TX header 설정 후 1바이트 메시지 전송 (LED 번호 전송)
DLC는 1, Standard ID 설정 (임의 값 선택)
LED 번호를 전역 변수로 설정하고, 전송 후 1씩 증가
LED 번호가 4가 되면 다시 0으로 초기화
CAN TX API를 사용해 메시지 전송
즉, 1초마다 LED 번호를 전송하는 기능 구현

버튼 인터럽트 처리

타이머 시작을 버튼 인터럽트에서 수행.
EXTI15_10_IRQHandler를 사용해 버튼 인터럽트 처리.
HAL_GPIO_EXTI_IRQHandler API를 호출하여 EXTI 인터럽트 처리.
사용 보드(Nucleo or Discovery)에 따라 EXTI 핸들러가 다를 수 있음 → 적절한 ISR 구현 필요.

GPIO Init

N1 측 (노드 1)
- 애플리케이션은 버튼을 눌렀을 때 실행됨
- 버튼은 PC13 핀에 연결됨
- 따라서 PC13을 GPIO 입력(Input) 모드 + 인터럽트(Interrupt) 모드로 설정해야 함
N2 측 (노드 2)
- 4개의 LED를 제어하기 위해 4개의 GPIO 핀 사용
- 해당 GPIO 핀들은 출력(Output) 모드로 설정해야 함

코드 구현

main.c의 기존 GPIO_Init 함수에서 초기화 수행
기존 GPIO_Init 함수에는 온보드 LED 초기화 코드가 있음
여기에 N1의 버튼 핀(PC13) 설정 및 인터럽트 활성화 코드 추가
그리고 N2의 4개 GPIO를 출력 모드로 설정하는 코드 추가
GPIO 초기화는 N1과 N2 공통 함수로 작성

CAN Interrupts

leecrossun — Sat, 1 Mar 2025 20:37:50 +0900

Understanding bxCAN Interrupt requests (IRQs)

bxCAN 인터럽트가 발생하는 경우

송신 이벤트(Tx Events)
- 메시지 전송 요청이 완료될 때 (Mailbox 0, 1, 2)
수신 이벤트(Rx Events)
- RX FIFO 0에 새로운 프레임이 수신될 때
- RX FIFO 1에 새로운 프레임이 수신될 때
상태 변화(Status Change Events)
- CAN 버스 상태 변화 (Bus-off, 오류 발생 등)
오류 발생(Error Events)
- 수신/송신 오류 증가
- FIFO 오버런(overrun) 발생
- Bus-off 상태로 전환

bxCAN 인터럽트 벡터 개수

bxCAN1: 4개의 인터럽트 벡터(IRQ)
bxCAN2: 4개의 인터럽트 벡터(IRQ)
총 8개의 IRQ가 CAN1 및 CAN2에 할당됨

bxCAN 인터럽트 발생 원인 및 처리 방식

① 송신 인터럽트 (Transmit Interrupt)

Mailbox 0, 1, 2에서 메시지 전송 완료 시 발생
관련 레지스터: CAN_TSR (Transmit Status Register)
RQCP0 (Request Completed for Mailbox 0) 비트가 1이 되면 인터럽트 발생

② RX FIFO 0 인터럽트 (Receive FIFO 0 Interrupt)

FIFO 0에 새로운 메시지가 들어오면 발생
관련 레지스터: CAN_RF0R (Receive FIFO 0 Register)
FMP0 (FIFO Message Pending) 비트가 1 이상이면 인터럽트 발생
FIFO가 가득 차거나(FULL0 비트) 오버런 발생(FOVR0 비트) 시 인터럽트 발생

③ RX FIFO 1 인터럽트 (Receive FIFO 1 Interrupt)

RX FIFO 0과 동일한 방식으로 동작 (FIFO 1 사용)

④ 상태 변화 및 오류 인터럽트 (Status Change & Error Interrupt)

ESR (Error Status Register)에 의해 감지됨
주요 원인:
- EWGF (Error Warning Flag): 오류 카운터가 일정 값(96) 이상 증가하면 경고 발생
- BOFF (Bus-off 상태): 전송 오류(TEC)가 255를 초과하면 노드가 Bus-off 상태가 되어 통신 불가
- WKUI (Wakeup Interrupt): Sleep Mode에서 Start of Frame(SOF) 감지 시 발생

Bus-off 상태 및 복구

Bus-off란?
- 송신 오류(TEC)가 255를 초과하면 노드가 Bus-off 상태로 전환
- Bus-off 상태에서는 송·수신이 불가능하며, CAN 버스로부터 차단
Bus-off 복구 방법
1. 자동 복구 (Auto Bus-Off Management, ABOM) 활성화
  - ABOM 비트를 1로 설정하면 자동 복구 가능
  - 128개의 연속적인 Recessive(1) 비트를 감지하면 자동 복구됨
2. 소프트웨어를 통한 복구
  - CAN_Init()을 다시 호출하여 CAN 컨트롤러를 초기화 모드 → 정상 모드로 전환

WKUI - Wakeup Interrupt)

CAN 컨트롤러가 Sleep Mode에 있을 때, Start of Frame(SOF)이 감지되면 발생
CAN RX 엔진이 활성화되어 있어야 감지

IRQs Exercise

IRQ 활성화 (msp.c)

void HAL_CAN_MspInit(CAN_HandleTypeDef *hcan)
{
	GPIO_InitTypeDef gpio_can1;
	__HAL_RCC_CAN1_CLK_ENABLE();

	gpio_can1.Pin = GPIO_PIN_11 | GPIO_PIN_12;
	gpio_can1.Mode = GPIO_MODE_AF_PP;
	gpio_can1.Pull = GPIO_NOPULL;
	gpio_can1.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
	gpio_can1.Alternate = GPIO_AF9_CAN1;
	HAL_GPIO_Init(GPIOA, &gpio_can1);

	HAL_NVIC_SetPendingIRQ(CAN1_TX_IRQn, 15, 0);
	HAL_NVIC_SetPendingIRQ(CAN1_RX0_IRQn, 15, 0);
	HAL_NVIC_SetPendingIRQ(CAN1_RX1_IRQn, 15, 0);
	HAL_NVIC_SetPendingIRQ(CAN1_SCE_IRQn, 15, 0);

	HAL_NVIC_EnableIRQ(CAN1_TX_IRQn);
	HAL_NVIC_EnableIRQ(CAN1_RX0_IRQn);
	HAL_NVIC_EnableIRQ(CAN1_RX1_IRQn);
	HAL_NVIC_EnableIRQ(CAN1_SCE_IRQn);
}

인터럽트 서비스 루틴(ISR) 구현 (it.c)

void CAN1_TX_IRQHandler(void)
{
	HAL_CAN_IRQHandler(&hcan1);
}

void CAN1_RX0_IRQHandler(void)
{
	HAL_CAN_IRQHandler(&hcan1);
}

void CAN1_RX1_IRQHandler(void)
{
	HAL_CAN_IRQHandler(&hcan1);
}

void CAN1_SCE_IRQHandler(void)
{
	HAL_CAN_IRQHandler(&hcan1);
}

Callback function Implementation

CAN 하드웨어에서 인터럽트를 활성화하려면 메인함수에서 activate notification API 호출

HAL_CAN_ActivateNotification(&hcan1, CAN_IT_TX_MAILBOX_EMPTY | CAN_IT_RX_FIFO0_MSG_PENDING | CAN_IT_BUSOFF)

Callback 함수를 모두 구현하고, 인터럽트 모드이므로 Rx 함수는 제거

void HAL_CAN_TxMailbox0CompleteCallback(CAN_HandleTypeDef *hcan)
{
	char msg[50];
	sprintf(msg, "Message Transmitted\r\n");
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);
}

void HAL_CAN_TxMailbox1CompleteCallback(CAN_HandleTypeDef *hcan)
{
	char msg[50];
	sprintf(msg, "Message Transmitted\r\n");
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);
}

void HAL_CAN_TxMailbox2CompleteCallback(CAN_HandleTypeDef *hcan)
{
	char msg[50];
	sprintf(msg, "Message Transmitted\r\n");
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);
}

void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)
{
	CAN_RxHeaderTypeDef RxHeader;
	uint8_t message[5];
	char msg[50];

	//while(HAL_CAN_GetRxFifoFillLevel(&hcan1, CAN_RX_FIFO0));
	if(HAL_CAN_GetRxMessage(&hcan1, CAN_RX_FIFO0, &RxHeader, message)!= HAL_OK) Error_handler();

	sprintf(msg, "Message Received %s\r\n", message);
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);
}

void HAL_CAN_ErrorCallback(CAN_HandleTypeDef *hcan)
{
	char msg[50];
	sprintf(msg, "CAN Error Detected!\r\n");
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);
}

bxCAN Frame Filtering

leecrossun — Sat, 1 Mar 2025 20:33:33 +0900

Understanding bxCAN acceptance filtering

CAN 메시지 수신 과정

CAN은 브로드캐스트 방식의 통신 시스템이므로, 애플리케이션이 관심 없는 메시지까지 모두 수신하면 불필요한 인터럽트가 지속적으로 발생하여 시스템의 오버헤드 증가

따라서 CAN 메시지가 CAN Rx 핀을 통해 들어오면, 수락 필터링(Acceptance Filtering) 과정에서 Filter Bank가 적용되어 수신된 메시지를 필터링

즉, 수신된 메시지는 필터링 규칙과 비교되며, 규칙을 충족하는 메시지만 FIFO에 저장

필터링 규칙을 충족한 메시지는 FIFO에 저장되며, 인터럽트 발생
필터링 규칙을 충족하지 못한 메시지는 CAN 컨트롤러의 수신 엔진에서 폐기, 인터럽트 발생X

Rx FIFO 구조

각 CAN 컨트롤러에는 2개의 수신 FIFO가 존재]

즉, CAN1에는 2개의 Rx FIFO, CAN2에도 2개의 Rx FIFO가 존재

각 FIFO에는 최대 3개의 CAN 메시지를 저장할 수 있으며, FIFO 관리는 하드웨어에 의해 자동으로 수행

Acceptance Filtering

CAN 컨트롤러는 기본적으로 버스에서 감지한 모든 프레임을 읽어 FIFO 메모리에 저장하고, 이를 호스트 프로세서에 알림. 하드웨어 필터링 기능을 활용하면, 특정 조건을 충족하지 않는 CAN 프레임을 무시하고 폐기

→ 불필요한 메시지를 처리할 필요가 없어 프로세서의 오버헤드 감소

ST bxCAN 컨트롤러에는 28개의 필터 뱅크(Filter Banks) 가 존재하며, 이는 Master 및 Slave CAN 컨트롤러가 공유
각 필터 뱅크는 2개의 32비트 필터 레지스터(R1, R2) 를 포함

CAN Acceptance Filtering

수락 필터링은 CAN 컨트롤러가 특정 조건을 충족하는 메시지만 수락하고 나머지는 폐기하도록 하는 기능
필터링은 Filter Bank를 사용하여 수행되며, 각 필터 뱅크는 두 개의 32비트 레지스터(R1, R2)로 구성
필터링 모드:
- 마스크 모드: 특정 비트를 검사하도록 마스크 값을 설정하는 방식
- 리스트 모드: 특정 ID 값만 허용하는 방식

예제 1: 상위 3비트가 1인 경우만 수락

조건: 표준 식별자(11비트)의 상위 3비트(MSB)가 1 1 1인 프레임만 수락

마스크 레지스터(R2)에 1 1 1 0 0 0 0 0 0 0 0을 설정
식별자 레지스터(R1)에 1 1 1 X X X X X X X X를 설정 (X는 무관한 값)
수신된 메시지의 상위 3비트가 1 1 1이면 수락, 그렇지 않으면 폐기

예제 2: 상위 3비트가 0이고 하위 2비트가 1인 경우만 수락

조건: 표준 식별자의 상위 3비트가 0 0 0, 하위 2비트(LSB)가 1 1인 프레임만 수락

마스크 레지스터(R2)에 1 1 1 0 0 0 0 0 0 1 1을 설정
식별자 레지스터(R1)에 0 0 0 X X X X X X 1 1을 설정
상위 3비트가 0 0 0이고 하위 2비트가 1 1이면 프레임을 수락

예제 3: 특정 ID(0x65D 또는 0x651)만 수락

조건: 표준 식별자가 0x65D 또는 0x651인 경우만 수락

마스크 모드가 아닌 리스트 모드(ID Mode) 사용
R1에 0x65D 저장, R2에 0x651 저장
수신된 메시지의 ID가 0x65D 또는 0x651과 일치하면 수락, 그렇지 않으면 폐기

예제 4: 요청 프레임(Request Frame)만 수락

조건: 요청 프레임(RTR 비트가 1)만 수락

RTR 비트가 1이면 요청 프레임, 0이면 데이터 프레임
마스크 레지스터(R2)에서 RTR 필드를 1로 설정
식별자 레지스터(R1)에서 RTR 필드를 1로 설정
수신된 메시지의 RTR 비트가 1이면 수락, 0이면 폐기

예제 5: 확장 ID(Extended ID) 프레임만 수락

조건: 확장 식별자(IDE 비트가 1) 프레임만 수락

IDE 비트가 1이면 확장 ID, 0이면 표준 ID
마스크 레지스터(R2)에서 IDE 필드를 1로 설정
식별자 레지스터(R1)에서 IDE 필드를 1로 설정
수신된 메시지의 IDE 비트가 1이면 수락, 0이면 폐기

예제 6: 모든 프레임 수락

조건: 모든 CAN 메시지를 수락

필터를 설정하지 않으면 기본적으로 모든 메시지가 수락됨
단, 메시지를 어느 FIFO(First In First Out) 버퍼로 보낼지를 설정해야 함

Exploring filtering data structures

① FilterIdHigh : 32비트 설정에서 필터 식별 번호의 상위 16비트(MSB) 지정

관련 레지스터: Identifier Register

② FilterIdLow : 32비트 설정에서 필터 식별 번호의 하위 16비트(LSB) 지정

③ MaskIdHigh / MaskIdLow : 필터 마스크 ID 설정 (필터링할 메시지 지정)

④ FilterFIFOAssignment : 필터 뱅크(예: 0~1)에서 수신 메시지가 어느 FIFO로 전달될지 설정

⑤ FilterBank

총 28개의 필터 뱅크 사용 가능.
단일 CAN 인스턴스 사용 시 0~13번까지 14개 필터 뱅크만 사용 가능

⑥ Filter Mode : Mask Mode / ID Mode

⑦ Filter Scale

32비트 또는 16비트 설정 가능
일반적으로 32비트 사용(레지스터를 32비트로 취급)

⑧ Filter Activation : 필터를 활성화하려면 enable 설정

⑨ SlaveStartFilterBank

듀얼 CAN 사용 시만 의미 있음
28개의 필터 뱅크를 CAN1과 CAN2가 공유
0 ~ 13은 CAN1, 14 ~ 27은 CAN2가 사용

루프백(Loopback) 애플리케이션 설정

모든 프레임을 수락하는 Mask Mode 사용.
이 경우 설정 값:
- FilterIdHigh = 0
- FilterIdLow = 0
- MaskIdHigh = 0
- MaskIdLow = 0
- FilterBank = 0 (0번 필터 뱅크 사용)
- FIFO Assignment = RX FIFO 0
- Filter Mode = Mask Mode

Exercise : CAN Tx, Rx with filter config

수신 메시지 확인

데이터를 읽기 전에 해당 FIFO에 메시지가 존재하는지 확인
API: HAL_CAN_GetRxFifoFillLevel()
역할: RX FIFO의 메시지 개수 확인
반환값:
- 0이면 수신된 메시지 없음
- 1~3이면 메시지가 존재

void CAN1_Rx(void)
{
	CAN_RxHeaderTypeDef RxHeader;
	uint8_t message[5];
	char msg[50];

	while(HAL_CAN_GetRxFifoFillLevel(&hcan1, CAN_RX_FIFO0));
	if(HAL_CAN_GetRxMessage(&hcan1, CAN_RX_FIFO0, &RxHeader, message)!= HAL_OK) Error_handler();

	sprintf(msg, "Message Received %s\r\n", message);
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);

}

메시지가 존재할 때까지 대기 (while 문 활용)
HAL_CAN_GetRxMessage() 호출하여 데이터를 읽음
데이터를 출력(printf)하여 확인

CAN Filter Configuration

CAN Start 호출 전에 필터 설정
CAN Start가 실행되면 초기화 모드에서 벗어나므로, 그 전에 필터 설정을 완료
필터 구성 함수 (CAN Filter Config) 생성

32비트 vs 16비트 스케일
- 32비트 스케일: ID 레지스터 R1과 R2가 32비트로 처리
- 16비트 스케일: ID 레지스터 R1이 두 개의 16비트 레지스터로 분할
- 대부분의 경우 32비트 스케일을 사용

STM32 bxCAN Exercise

leecrossun — Sat, 1 Mar 2025 20:26:59 +0900

CAN Tx

CAN_Handle의 구조체 멤버

Instance: CAN 인스턴스 지정
Init: CAN 초기화 매개변수 설정
- Mode: Normal Mode, Loopback Mode, Silent Mode 등
- Bit Timing 관련 요소: Prescaler(Time Quantum의 길이), SyncJumpWidth, TimeSeg1, TimeSeg2
- AutoBusOff : 에러를 일으키는 노드를 자동으로 제외
- AutoRetransmission : 전송자가 ACK를 받지 못하면 자동으로 재전송
- AutoWakeup
- TransmitFifoPriority

ReceiveFifoLocked
- 0 : 3개의 메시지가 모두 채워지면 다음 메시지가 이전 것을 덮어씀
- 1 : 3개의 메시지가 모두 채워지면 다음 메시지가 무시됨

CAN 비트 타이밍

http://www.bittiming.can-wiki.info/

CAN Bit Time Calculation

The following calculation sheet is mostly useful for classic CAN as defined in ISO-11898 before 2015. For the new CAN FD as defined in ISO-11898:2015 work is in Progress. CiA provides the document CiA 601-3 CAN FD bit-timing recommendations. By providing t

www.bittiming.can-wiki.info

CAN 통신에서는 한 비트가 네 개의 세그먼트로 나뉘며, CAN bus의 원하는 bitrate를 얻으려면 세그먼트의 width를 적절히 조정해야 함
각 세그먼트는 time quanta의 측면에서 설명 ( time quantum : 모든 configuration value의 가장 작은 time unit )

동기화 세그먼트(Synchronization Segment)
전파 세그먼트(Propagation Segment)
페이즈 세그먼트 1(Phase Segment 1)
페이즈 세그먼트 2(Phase Segment 2)
비트 타이밍은 타임 퀀텀(Time Quantum, Tq) 단위로 설정
- 타임 퀀텀의 길이는 CAN 페리페럴에 공급되는 클럭 주파수에 따라 결정
  - HSE(고속 외부 클럭)에서 50MHz의 PLL 출력 클럭을 생성하고, APB1 버스에 25MHz를 공급한 경우, CAN1이 APB1 버스에 연결되어 있으므로 CAN1의 입력 클럭도 25MHz가 됨
    - Prescaler = 1일 때, CAN은 25MHz를 직접 사용
    - Prescaler = 5일 때, 5로 나누어 5MHz를 사용

비트 타이밍의 각 요소는 타임 퀀텀 개수로 표현

동기화 세그먼트 = 1Tq (고정)
전파 세그먼트 + 페이즈 세그먼트 1 = 8Tq
페이즈 세그먼트 2 = 1Tq=> 총 10Tq가 한 비트를 구성

비트 타이밍을 적절히 조정하면 원하는 비트 레이트를 설정할 수 있음

If you increase the bit duration by including more and more TQs for each segment, then you may minimize the transmission errors and signal can be carried over longer distances but bus throughput decreases

예를 들어, 테이블의 가장 첫번째 설정(Prescaler=5)에서는 1Mbps의 비트 레이트를 달성할 수 있음
비트 타이밍을 과도하게 줄이면 전송 속도는 증가하지만, 장거리 통신에서 문제가 발생
따라서 CAN Bit Time 계산기를 사용하여 최적의 값을 설정하는 것이 중요

void CAN1_Init(void)
{
	// CAN Controller setting
	hcan1.Instance = CAN1;
	hcan1.Init.Mode = CAN_MODE_LOOPBACK;
	hcan1.Init.AutoBusOff = DISABLE;
	hcan1.Init.AutoRetransmission = ENABLE;
	hcan1.Init.AutoWakeUp = DISABLE;
	hcan1.Init.ReceiveFifoLocked = DISABLE;
	hcan1.Init.TimeTriggeredMode = DISABLE;
	hcan1.Init.TransmitFifoPriority = DISABLE;
	
	// CAN bit timings setting
	hcan1.Init.Prescaler = 5;
	hcan1.Init.SyncJumpWidth = CAN_SJW_1TQ;
	hcan1.Init.TimeSeg1 = CAN_BS1_8TQ;
	hcan1.Init.TimeSeg2 = CAN_BS2_1TQ;
	
	if(HAL_CAN_Init(&hcan1) != HAL_OK) Error_handler();
	
}

CAN Transmit mailboxes

빈 상태: Mailbox가 비어 있음.
- 3개의 mailboxes 존재
Pending 상태: TXRQ 비트가 설정되어 전송 요청 후, 우선순위 확인을 위해 대기
Schedule 상태: 스케줄러에 의해 우선순위가 높은 Mailbox로 선정되어 전송 대기
- 처음 전송해야 하는 mailbox 선택하고, identifier, the data length code (DLC), data 설정
- Control register에서 TXRQ bit 설정하여 전송 요청
Transmit 상태: 버스가 Idle 상태가 되면, 실제 전송이 시작되고, 버스의 경합(Arbitration)에 참여
전송 성공:
- Mailbox는 빈 상태로 복귀하며, TXOK 비트 설정 (CAN_TSR register)
전송 실패:
- Arbitration Lost (ALST) 또는 Transmission Error (TERR) (CAN_TSR register)
- 자동 재전송 (Auto Retransmission) 기능이 활성화되어 있다면, Mailbox는 다시 Schedule 상태로 돌아가 재시도
- 만약 재전송 기능이 비활성화되어 있다면, 실패 시 Mailbox는 비워짐
우선순위 변경:
- 만약 다른 Mailbox가 Pending 상태에 진입하여 우선순위가 더 높다면, 현재 Schedule 상태에 있는 Mailbox는 다시 Pending 상태로 돌아갈 수 있음

CAN TX 데이터 구조체

CAN_TXHeaderTypeDef
- 전송 프레임의 헤더 정보를 설정
- Standard/Extended Identifier: 식별자
- IDE: 메시지 식별자 타입 (표준 프레임 vs 확장 프레임)
- RTR: 데이터 프레임인지 요청(Remote) 프레임인지를 결정
- DLC: 데이터 길이 (payload의 바이트 수)
- 데이터는 이 구조체에 포함되지 않고 별도의 외부 버퍼로 전달됨

CAN 송신 함수 HAL_CAN_AddTxMessage 구현 및 송신 완료 확인

**HAL_CAN_AddTxMessage**(**CAN_HandleTypeDef** *hcan, **const** **CAN_TxHeaderTypeDef** *pHeader, **const** **uint8_t** aData[], **uint32_t** *pTxMailbox)

폴링 방식 사용:
- 전송 요청이 대기 중인지 확인 : CAN_IsTxMessagePending API 사용
- 이 API는 선택한 메일박스에 전송 요청이 pending 상태이면 1, 그렇지 않으면 0을 반환
- while 루프로 대기하여, 반환 값이 0이 될 때까지 기다린 후 송신 완료 확인
전송 완료 후:
- 송신 성공 시 TXOK 비트가 설정되고, 메일박스가 비워지며, UART 를 통해 “전송 성공” 메시지를 출력

void CAN_Tx(void)
{
	CAN_TxHeaderTypeDef TxHeader;
	uint32_t TxMailbox;
	uint8_t message[5] = {'H', 'E', 'L', 'L', 'O'};

	TxHeader.DLC = 5;
	TxHeader.StdId = 0x65D;
	TxHeader.IDE = CAN_ID_STD;
	TxHeader.RTR = CAN_RTR_DATA;

	if(HAL_CAN_AddTxMessage(&hcan1, &TxHeader, message, &TxMailbox)!= HAL_OK) Error_handler();
	while(HAL_CAN_IsTxMessagePending(&hcan1, TxMailbox));

	sprintf(msg, "Message Transmitted\r\n");
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);

}

bxCAN operating mode

Reset/Sleep Mode
- 마이크로컨트롤러가 리셋되거나 CAN 컨트롤러가 리셋 상태
- 송수신 불가
Initialization Mode
- CAN 컨트롤러 초기화
- 제어 레지스터의 Sleep 비트를 해제
- CAN 초기화 함수(CAN Init)는 바로 이 작업부터 시작
- 초기화 모드에서는 송수신 기능이 동작하지 않으므로, 초기화 작업이 안전하게 수행
Normal Mode
- 초기화가 완료된 후, CAN 컨트롤러를 실제 송신(Tx) 및 수신(Rx) 기능 수행
- HAL_CAN_Start 호출
  - INRQ 비트를 활성화하여 CAN 컨트롤러를 초기화 모드에서 일반 모드로 전환
- CAN 컨트롤러가 정상적으로 버스에 참여하여 메시지를 송수신

// main함수에 CAN_Tx 이전에 Start 함수 호출해서 Normal Mode로 전환
HAL_CAN_Start(&hcan1);
CAN_Tx();

msp.c Initialization

void HAL_CAN_MspInit(CAN_HandleTypeDef *hcan)
{
	GPIO_InitTypeDef gpio_can1;
	__HAL_RCC_CAN1_CLK_ENABLE();

	gpio_can1.Pin = GPIO_PIN_11 | GPIO_PIN_12;
	gpio_can1.Mode = GPIO_MODE_AF_PP;
	gpio_can1.Pull = GPIO_NOPULL;
	gpio_can1.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
	gpio_can1.Alternate = GPIO_AF9_CAN1;
	HAL_GPIO_Init(GPIOA, &gpio_can1);
}

CAN loopback connection details

트랜시버 없이 테스트 (Loopback 모드 사용)
- 트랜시버 모듈을 사용하지 않는다면, PA11 (CAN TX 핀)을 연결할 필요X
- 루프백 모드는 내부적으로 동작하므로 RCS 라인도 연결 X
- 해당 핀을 3.3V로 드라이브
- 3.3V는 Nucleo 보드에서 제공되며, 3.3kΩ 저항을 통해 연결
- 이렇게 연결하면 트랜시버 없이도 테스트 가능
트랜시버를 사용하는 경우
- 트랜시버를 사용할 경우, 3.3V DC, GND, CAN TX, CAN RX 연결
  - CAN_H, CAN_L 핀이 있으며, 이는 차동 신호를 사용
  - 역할 : 싱글 엔디드 신호를 차동 신호로 변환
트랜시버 연결 방법
- 트랜시버 모듈에 3.3V 전원을 공급(3.3V 이상 공급하지 않도록 주의)
- GND를 정확히 연결
- PA11 (CAN TX) → 트랜시버 CAN TX 핀 연결
- PA12 (CAN RX) → 트랜시버 CAN RX 핀 연결
- CAN_H, CAN_L 핀은 그대로 둠 (별도로 연결할 필요 없음)
- 대부분의 트랜시버에는 120Ω 종단 저항이 포함되어 있음
  - 사용 중인 트랜시버 모듈의 회로도를 확인하여 120Ω 저항이 있는지 체크
Nucleo 보드에서 전원 및 GND 연결

3.3V와 GND는 Nucleo 보드의 헤더에서 쉽게 얻을 수 있음
3.3V → 트랜시버 3.3V 핀 연결
GND → 트랜시버 GND 핀 연결

Application Test

모든 연결을 완료한 후, 테스트를 진행.
Logic Analyzer를 사용할 경우 CAN_TX 핀에 연결.
- CAN_RX 핀은 연결하지 않음 (Loopback 모드에서는 내부에서 처리됨)
로직 분석기가 아날로그 신호를 지원하면 CAN_H에 연결 가능
아날로그 신호 지원이 없을 경우, CAN_TX 핀의 디지털 신호를 측정

로직 분석기로 CAN 메시지 디코딩

분석기 소프트웨어에서 CAN 분석기 추가

채널 선택: CAN 신호를 연결한 채널 지정

비트 레이트 설정: 500kbps (500000으로 입력)

메시지 디코딩 확인

Identifier (식별자): 65D (16진수).
데이터: "hello" (ASCII 변환 가능).

Loopback 모드에서 ACK 문제

ACK 오류(NAK)가 발생하지만, 이는 정상적인 동작
- 자체적으로 ACK 신호를 무시하고 재전송하지 않기 때문
따라서 ACK 필드는 Recessive(1) 상태로 유지됨

비트 레이트 검증

SOF(Start of Frame, 시작 프레임) 확인: 첫 번째 지배적 비트(Dominant Bit).
비트 지속 시간 측정:
- SOF가 2마이크로초(2μs)라면 500kbps 설정이 올바름

STM32 bxCAN

leecrossun — Sat, 1 Mar 2025 20:16:35 +0900

STM32 bxCAN Introduction

STM32의 bxCAN(basic extended CAN) 모듈은 CAN 메시지의 송수신을 완전히 자동으로 처리

bxCAN 의 세부 명세는 레퍼런스 메뉴얼에서 추가적으로 확인

bxCAN의 주요 특징

CAN1(마스터)과 CAN2(슬레이브) 두 개의 CAN 컨트롤러 제공
CAN 프로토콜 2.0 A와 B 버전 지원 (표준 및 확장 CAN 네트워크 모두 사용 가능)
최대 1Mbps의 비트레이트 지원 (클럭 설정에 따라 다름)
3개의 송신 메일박스 제공 (한 번에 3개의 CAN 메시지 전송 가능)
각 컨트롤러마다 3단계의 2개 수신 FIFO 제공
CAN1과 CAN2가 공유하는 28개의 필터 뱅크

bxCAN으로 할 수 있는 작업

비트레이트, 비트 타이밍 등의 CAN 파라미터 설정
메시지 전송 및 수신 처리
수신은 하드웨어가 자동으로 처리 (필터링, FIFO로 데이터 이동)
인터럽트 관리
- 전송 완료 인터럽트
- 수신 인터럽트
- 에러 인터럽트
CAN 버스의 진단 정보 확인

듀얼 CAN 구조

NUCLEO-F446RE는 듀얼 CAN을 지원하며, CAN1과 CAN2 두 개의 CAN 컨트롤러를 포함

CAN1 (마스터)
CAN2 (슬레이브)

그러나, CAN 통신은 마스터-슬레이브 기반이 아닌 멀티마스터 방식

CubeMX 및 참고 매뉴얼에서는 CAN1을 마스터, CAN2를 슬레이브라고 표현하는데, 이는 CAN2의 기능적 제약 때문(혼동 주의!)

CAN1(마스터)과 CAN2(슬레이브)

CAN2는 SRAM에 직접 접근할 수 없어 슬레이브로 지칭
CAN2를 사용하려면 반드시 CAN1을 먼저 활성화해야 함
두 컨트롤러 모두 CAN 2.0 A/B 사양 기반으로 동작

송수신 구조

기능	CAN1 (마스터)	CAN2 (슬레이브)
TX Mailboxes	3개	3개
Receive FIFO	FIFO0, FIFO1 (각 3개 메시지 저장 가능)	FIFO0, FIFO1 (각 3개 메시지 저장 가능)
Filter Bank	28개 필터 뱅크 (각 2개 필터 포함)	공유 (CAN1 활성화 필요)
Transmission Scheduler	메시지 우선순위 결정 후 전송	동일
Interrupt Control	지원	지원

송신(Tx) 메일박스 구조
- CAN1과 CAN2 각각 3개의 송신 메일박스 보유
- 한 번에 최대 3개의 메시지 전송 가능
- 전송 스케줄러가 메시지 우선순위 관리
수신(Rx) FIFO 구조
- 각 컨트롤러마다 2개의 수신 FIFO (FIFO0, FIFO1) 보유
- 각 FIFO는 최대 3개의 CAN 메시지 저장 가능
- FIFO 오버런: 수신 FIFO가 최대 3개의 메시지를 저장할 수 있으며, 4번째 메시지가 도착하면 오버런(Overrun) 발생
Acceptance Filtering
- CAN 메시지를 설정된 규칙에 따라 필터링하는 기능
- 총 28개의 필터 뱅크 보유 (각각 2개의 필터 포함)
- CAN1과 CAN2가 공유하며, CAN2가 사용하려면 CAN1이 활성화되어야 함

bxCAN Test Mode

Silent Mode
- CAN 버스에 영향을 주지 않고 메시지를 수신하는 테스트
- Bus에서 데이터를 듣기만 하고 송신하지 않음. Sniffer 역할 가능
Loopback Mode
- 자체적으로 메시지를 송수신하여 CAN 통신이 정상적으로 동작하는지 테스트
- Bus에 송신 가능하지만, Bus에서 데이터 수신은 불가능. Self-Test 용도
Silent + Loopback Mode
- 외부 네트워크 영향을 받지 않으면서 내부적으로 메시지 송수신을 검증
- Bus와 완전히 분리되어 내부 테스트만 가능

1) Silent Mode (침묵 모드)

특징

CAN_TX가 TX 엔진과 분리되어 있으며, 항상 논리적 '1' (Recessive Bit) 유지됨.
즉, CAN Bus를 방해하지 않고 항상 Recessive 상태를 유지함.
수신(Rx)은 정상적으로 동작하며, CAN Bus에서 전송되는 데이터를 읽을 수 있음.
CAN_TX는 내부적으로 Rx로 루프백되어 송신한 데이터를 수신할 수 있음.
CAN Bus의 트래픽을 분석하는 "Sniffer" 용도로 활용 가능.

요약

✅ CAN Bus에 영향을 주지 않음 (Recessive Bit 유지)

✅ Bus에서 데이터를 수신 가능

✅ 자체 송신한 데이터를 내부적으로 수신 가능

✅ 네트워크 분석(Sniffer) 용도로 사용 가능

2) Loop Back Mode (루프백 모드)

특징

CAN_TX는 정상적으로 동작하여 CAN Bus에 데이터를 전송할 수 있음.
하지만 Bus에서 데이터를 수신할 수 없음 (CAN_RX가 Bus에서 분리됨).
대신, 자신이 송신한 데이터가 내부적으로 CAN_RX로 루프백됨.
주로 자기 테스트(Self-Test) 용도로 사용됨.

요약

✅ CAN Bus에 데이터를 송신 가능

✅ 자체 송신한 데이터를 내부적으로 수신 가능

❌ CAN Bus에서 다른 노드의 데이터를 수신 불가

✅ Self-Test 용도로 사용됨

3) Silent + Loop Back Mode (침묵 + 루프백 모드)

특징

CAN_TX 및 CAN_RX 모두 CAN Bus에서 분리됨 → 완전히 독립적인 상태.
송신한 데이터가 내부적으로 Rx로 루프백됨.
하지만 CAN Bus의 데이터를 수신할 수 없음.
즉, 완전히 독립된 상태에서 자체 테스트를 수행하는 용도.

요약

❌ CAN Bus에 데이터를 송신할 수 없음

❌ CAN Bus에서 데이터를 수신할 수 없음

✅ 자체 송신한 데이터를 내부적으로 수신 가능

✅ 완전히 독립적인 상태에서 Self-Test 가능

CAN frame formats / Bus Arbitration

leecrossun — Sat, 1 Mar 2025 20:10:51 +0900

Arbitration field

CAN 메시지 유형 (Frame Types)

데이터 프레임(Data Frame): 일반적으로 가장 많이 사용되는 메시지 유형으로, CAN 노드가 다른 노드에 메시지를 전송할 때 사용된다.
원격 프레임(Remote Frame): 특정 노드에서 다른 노드에 데이터를 요청할 때 사용된다.
에러 프레임(Error Frame): CAN 프로토콜의 신호 규칙 위반이나 오류 발생 시 컨트롤러가 자동으로 전송하는 프레임이다.
오버로드 프레임(Overload Frame): 버스가 과부하 상태일 때 컨트롤러가 자동으로 전송하는 프레임이다.

데이터 프레임과 원격 프레임은 애플리케이션에서 자주 사용

에러 프레임과 오버로드 프레임은 컨트롤러가 자동으로 관리

데이터 프레임(Data Frame)

CAN 노드가 다른 노드로 메시지를 전송할 때 사용하는 기본적인 프레임 형식
브로드캐스트 방식으로 메시지를 전달
데이터 필드 최대 크기: 8바이트
프레임 내부에는 여러 필드가 포함됨 (예: 페이로드, 길이 필드, CRC 필드 등)

데이터 프레임 구조

Start of Frame (SOF): 프레임의 시작을 알리는 첫 번째 지배(dominant) 비트.
Arbitration Field: 우선순위를 결정하는 필드로, 11비트 식별자(identifier)와 1비트 RTR(Request Remote) 비트로 구성됨.
Control Field: 데이터 길이 등을 정의하는 필드.
Data Field: 최대 8바이트의 데이터를 포함하는 페이로드 필드.
CRC Field: 오류 검출을 위한 CRC 코드가 포함된 필드 (컨트롤러가 자동 계산).
ACK Field: 수신 노드가 프레임을 정상적으로 수신했는지 확인하는 필드. 정상적으로 수신되면 지배 상태(dominant)로 설정됨.
End of Frame (EOF): 프레임 종료를 나타내는 7개의 열성(recessive) 상태 비트.
Interframe Space: 프레임 간 간격을 유지하는 3개의 열성(recessive) 비트.

Arbitration Field

Identifier (식별자, 11비트): 메시지의 우선순위를 결정하는 값. 값이 작을수록 우선순위가 높음.
RTR (Request Remote) 비트: 원격 프레임 요청 여부를 나타내는 비트. 데이터 프레임에서는 항상 지배(dominant) 상태

Standard CAN vs. Extended CAN

Bosch에서 발표한 CAN 2.0은 두 가지 유형이 있음: 2.0A(표준 CAN), 2.0B(확장 CAN)

2.0A(표준 CAN)

11비트 식별자 사용
2.0A 기반 컨트롤러는 표준 프레임만 송수신 가능

2.0B (확장 CAN)

29비트 식별자 사용 (11비트 + 추가 18비트)
2.0B 기반 컨트롤러는 표준 및 확장 프레임 모두 송수신 가능
기존 2.0A 컨트롤러와 하위 호환 가능

차이점

식별자 길이: 표준 CAN(11비트) vs. 확장 CAN(29비트)
확장 프레임에는 추가 18비트 식별자 필드 존재
표준과 확장 프레임을 구분하는 IDE 비트
- IDE 비트 dominant → 표준 프레임
- IDE 비트 recessive → 확장 프레임

Arbitration 필드

11비트 식별자 + 1비트 RTR 비트(총 12비트)
여러 노드가 동시에 버스를 사용할 경우 메시지 우선순위를 결정

ACK, RTR, DLC, CRC

RTR (Remote Transmission Request) 비트
- 데이터 프레임(Data Frame)에서는 항상 dominant(0)
- 원격 프레임(Remote Frame)에서는 recessive(1)
- 원격 프레임(Remote Frame): 특정 노드가 다른 노드에게 데이터를 요청하는 메시지 (데이터 필드 없음)
기타 필드 설명
- DLC (Data Length Code): 데이터 필드 크기 지정 (최대 8바이트)
- CRC (Cyclic Redundancy Check): 송수신 데이터 무결성 검사 (15비트 체크섬)
  - As soon as CAN receiver starts receiving a frame it also calculates the CRC and then it matches with the CRC sent by the transmitter
  - if CRC match is successful then receiving node make bus state as dominant exactly at the ack slot which indicates the transmitter that at least one node received the frame correctly. If transmitter sees recessive state of the bus at ack slot, then it understands that it’s an error and retransmits the message.
- ACK (Acknowledgment) 비트:
  - 수신 노드가 정상적으로 데이터를 받았을 경우, dominant(0)로 설정 (ACK)
  - 송신 노드는 ACK 비트가 recessive(1)일 경우 재전송 (NAC)
  - CAN 버스에 송신 노드만 존재하면, ACK 응답이 없어 계속 재전송됨
    - It is worth noting that the presence of an acknowledgement bit on the bus does not mean that any of the intended devices has received the message.
    - It just means that one or more nodes on the bus has received it correctly and transmitter concludes that message sent successfully.
    - If transmitter sees recessive state at the ACK slot, then it retransmits the message until it sees dominant state. That’s the reason when there is only one node on the bus, transmitter keep sending the same message since no one is there to ack it.
  - ACK 필드는 2비트로 구성
    - ACK 비트: 정상 수신 여부
    - ACK 구분자(ACK delimiter): 항상 recessive(1)
  - ACK 비트의 한계
    - CAN 네트워크에 하나 이상의 노드만 존재하면 송신자는 ACK 응답을 받을 수 있음
    - ACK는 단순히 CAN 메시지가 데이터 링크 계층 규칙을 위반하지 않았음을 확인할 뿐
    - 특정 수신 노드가 데이터를 실제로 받았는지, 요청된 작업을 수행했는지는 보장되지 않음

EOF, IFS and SOF

End of Frame (EOF) & Inter Frame Spacing (IFS)

End of Frame (EOF): 메시지의 끝을 나타내며 7개의 연속된 recessive 비트로 구성됨
Inter Frame Spacing (IFS): EOF 이후 3개의 recessive 비트로 구성되며, 다음 메시지가 전송되기 전 반드시 포함되어야 함
즉, 총 10개의 recessive(1) 비트가 지나야 버스가 Idle 상태가 됨

Idle 상태 & 노드의 전송 조건

노드는 버스가 Idle 상태인지 확인한 후에만 데이터 전송 가능
버스가 Idle 상태가 되면 노드는 SOF을 전송하며 메시지를 시작

Start of Frame (SOF) 역할

SOF는 단일 dominant 비트로, 메시지의 시작을 알림
SOF가 등장하면 모든 노드가 이를 감지하고 CAN Bus 타이밍을 재동기화
즉, SOF는 Idle 상태 이후 첫 번째 dominant 비트로 메시지의 시작을 의미함

SOF의 중요성

노드들은 긴 recessive(1) 상태를 듣고 버스가 Idle임을 확인
첫 번째 dominant 비트를 감지하면 SOF로 인식하고 송·수신을 준비
CAN 네트워크에서 모든 노드가 동기화되는 기준점 역할

예제: 두 개의 노드 (Node A & Node B)

Node A가 메시지를 전송하려 할 때, 버스가 Idle 상태인지 확인.
Idle 상태가 확인되면 SOF(0) 비트를 보내며 프레임 시작
Node B는 dominant 비트를 감지하고 SOF임을 인식하여 메시지 수신을 준비
이를 통해 CAN 네트워크의 모든 노드는 동기화된 상태에서 통신을 진행할 수 있음

⇒ EOF(7비트) → IFS(3비트) → Idle → SOF(1비트) → 메시지 전송 순서로 진행

Remote frame

Remote frame은 다른 노드에 데이터를 요청하거나 정보를 요청하는 데 사용
- 노드 A가 arbitration field 를 123으로 설정한 Remote frame을 전송 → 노드 B는 arbitration field 가 같은 데이터 프레임으로 응답
즉, Remote frame은 요청 및 응답 형태의 통신을 구현하는 데 사용

데이터 프레임과의 구별

이 메시지는 경합 필드에 recessive RTR 비트가 설정되어 Remote frame임을 명확히 표시
데이터가 없음 (요청 메시지이기 때문)

CAN Bus Arbitration

CSMA (Carrier-sense Multiple Access): 각 노드는 메시지를 보내기 전에 버스가 비어있는지 확인
충돌 감지 및 우선순위 기반 경합 해결: 메시지의 우선순위는 식별자 필드에 미리 설정
- CD+AMP (Collision Detection + Arbitration on Message Priority): 각 메시지는 비트 단위 경합을 통해 우선순위가 높은 메시지가 버스 접근을 우선
- 우선순위: 낮은 식별자 번호일수록 우선순위가 높음

SOF (Start of Frame) 비트 전송 후, 각 노드는 자신의 식별자 비트를 전송
Recessive 상태로 시작한 후, dominant 비트를 전송
NODE-2가 recessive 비트를 보내면, 다른 두 노드 (NODE-1, NODE-3)가 dominant 비트 전송
이로 인해 NODE-2는 경합에서 탈락하고, Listen Only Mode로 전환
NODE-1과 NODE-3이 남아 경합을 계속하며, 결국 NODE-3이 우선순위가 더 높아 경합에서 승리

경합 승리 조건 정리

Dominant 비트가 Recessive 비트를 항상 우선시
식별자 값이 낮은 메시지가 우선순위가 높고, 버스를 장기간 점유
이 과정은 자동으로 CAN 컨트롤러에서 처리