Archives

memory_initialization_radix와 memory_initialization_vector를 사용해 COE 파일을 만들고 Vivado Block Memory Generator에 적용하는 방법입니다.

• Vivado
• COE
• Block Memory
• FPGA

Vivado 7 Series 설계에서 CONFIG_MODE, SPI_BUSWIDTH, CONFIGRATE를 설정하고 write_cfgmem으로 SPIx4 MCS 파일을 만드는 방법입니다.

• Vivado
• MCS
• SPIx4
• FPGA

Nexys A7의 USB-UART를 Windows COM 포트와 Tera Term에 연결하고 baud rate와 8N1 설정을 맞추는 순서를 정리합니다.

• Nexys A7
• UART
• Tera Term
• FPGA

Vivado Generate Bitstream부터 Hardware Manager의 Auto Connect와 Program Device까지 Nexys A7 FPGA를 programming하는 순서를 정리합니다.

• Vivado
• Bitstream
• Nexys A7
• FPGA

AMD 공식 다운로드 페이지에서 Windows용 Vivado installer를 받고 필요한 FPGA device family만 선택해 설치하는 순서를 정리합니다.

• Vivado
• Windows
• FPGA
• AMD

Vivado 프로젝트에 XDC constraint 파일을 만들고 Nexys A7의 PACKAGE_PIN, IOSTANDARD, clock을 할당하는 순서를 정리합니다.

• Vivado
• XDC
• Nexys A7
• FPGA

티스토리 공개 글 111개를 HTML, Markdown, JSON과 이미지로 나눠 로컬에 백업하고 확인한 결과를 기록합니다.

• Tistory
• Backup
• Node.js
• Markdown

Verilog 조합회로에는 blocking 할당을, clock 기반 순차회로에는 non-blocking 할당을 사용하는 이유와 주의점을 정리합니다.

• Verilog
• RTL
• FPGA
• ASIC

Windows PowerShell에서 pnpm 10을 npm으로 설치하고, 스크립트 실행 정책 오류를 피해서 버전을 확인하는 방법입니다.

• pnpm
• Node.js
• Windows
• PowerShell

Astro의 public과 dist가 비슷해 보이는 이유와 Git에 보관할 폴더, 삭제해도 되는 빌드 결과물을 구분합니다.

• Astro
• Build
• Static Assets

lwIP에서 UDP broadcast 송신이 timeout처럼 보이거나 패킷이 캡처되지 않으면 payload보다 SO_BROADCAST 또는 SOF_BROADCAST, NETIF_FLAG_BROADCAST, netif up/link, source IP, route를 먼저 확인해야 한다. RAW API, netconn/socket API, multi-netif 환경의 확인 순서를 정리한다.

• lwIP
• UDP
• Broadcast
• netif
• +2

DoIP에서 SecurityAccess key 전송 뒤 NRC 0x35 Invalid Key가 오면 seed/key 알고리즘만 의심하지 말고 seed freshness, level pairing, endian, session, retry counter를 나눠 확인해야 한다. 0x24, 0x33, 0x36과 구분해 로그를 남기는 흐름을 정리한다.

• DoIP
• UDS
• NRC
• Security Access
• +2

lwIP RAW TCP에서 tcp_write()가 간헐적으로 ERR_MEM을 반환하면 free RAM보다 TCP_SND_BUF, TCP_SND_QUEUELEN, MEMP_NUM_TCP_SEG, unsent/unacked 큐를 먼저 확인해야 한다. 작은 write 반복, ACK 지연, sent callback 없는 busy loop가 송신 큐를 막는 패턴을 정리한다.

• lwIP
• TCPIP
• TCP
• ERR_MEM
• +2

DoIP에서 UDS 요청 후 NRC 0x14 Response Too Long이 오면 TCP stream이나 패킷 조각 문제보다 요청이 만들 응답 크기, ECU 내부 버퍼, DID 묶음, routine result 크기를 먼저 확인해야 한다. 0x13, 0x78과 헷갈리지 않도록 응답 크기 문제를 분리해 보는 디버깅 순서를 정리한다.

• DoIP
• UDS
• NRC
• Response Too Long
• +2

lwIP 포팅에서 수신은 되는데 송신이 부하 중 멈추거나 linkoutput이 실패하면 TX descriptor 회수, pbuf chain 처리, zero-copy pbuf lifetime을 같이 봐야 한다. 복사 기반 송신과 DMA zero-copy 송신에서 ownership 기준이 어떻게 달라지는지 정리한다.

• lwIP
• TCPIP
• pbuf
• Ethernet MAC
• +2

DoIP에서 UDS 요청 후 NRC 0x31 Request Out Of Range가 오면 통신 실패보다 요청한 DID, Routine ID, sub-function, 세션별 지원 범위를 먼저 확인해야 한다. 0x22, 0x13과 헷갈리지 않도록 서비스 범위와 ECU 상태 조건을 분리해 보는 디버깅 순서를 정리한다.

• DoIP
• UDS
• NRC
• Request Out Of Range
• +2

lwIP 포팅에서 RX 패킷을 tcpip_input()으로 넘긴 뒤 간헐적인 payload 깨짐, double free, PBUF_POOL 고갈이 보이면 pbuf ownership 규칙을 먼저 확인해야 한다. ERR_OK와 실패 반환값, DMA 버퍼 재사용, ISR 컨텍스트, 예외 경로별 pbuf_free 기준을 정리한다.

• lwIP
• TCPIP
• pbuf
• Ethernet MAC
• +2

DoIP에서 UDS 요청 후 NRC 0x22 Conditions Not Correct가 오면 TCP timeout이나 Routing Activation 문제가 아니라 ECU가 현재 상태에서 그 서비스를 수행할 조건이 아니라고 보는 편이 빠르다. 세션, Security Access, 전원 모드, Tester Present, 이전 작업 상태를 함께 확인하는 디버깅 순서를 정리한다.

• DoIP
• UDS
• NRC
• Conditions Not Correct
• +2

lwIP에서 udp_sendto() 또는 socket sendto()가 ERR_RTE로 실패하면 UDP payload나 ARP보다 먼저 보낼 netif를 찾았는지 확인해야 한다. DHCP 완료 전 송신, default netif 누락, netif up/link 상태 불일치, IP 주소 미설정 같은 route 판단 지점을 bring-up 관점에서 정리한다.

• lwIP
• UDP
• ERR_RTE
• netif
• +2

DoIP에서 UDS 요청은 ECU까지 도착하는데 NRC 0x13 Incorrect Message Length or Invalid Format이 반복되면 TCP 조각이나 Routing Activation보다 먼저 DoIP Diagnostic Message 길이와 UDS 서비스별 payload 길이를 나눠 봐야 한다. Generic Header length, SA/TA, UDS payload 경계를 분리해 확인하는 디버깅 순서를 정리한다.

• DoIP
• UDS
• NRC
• Diagnostic Message
• +2

lwIP RAW TCP에서 연결 종료 시 tcp_close()가 가끔 ERR_MEM을 반환하면 단순 heap 부족으로 보면 오래 헤맨다. 아직 보내지 못한 세그먼트와 미확인 ACK 상태가 남아 있거나 close를 너무 이른 문맥에서 호출한 경우가 많아서, pcb 송신 상태와 콜백 흐름을 같이 보는 편이 빠르다.

• lwIP
• TCP
• tcp_close
• ERR_MEM
• +2

lwIP 포팅에서 ICMP는 되는데 TCP나 UDP만 깨지거나, 송신만 실패하고 수신은 정상처럼 보이면 checksum offload 설정 불일치를 먼저 확인해야 한다. lwIP 옵션과 MAC 드라이버가 같은 책임 분담을 보지 않으면 패킷은 나가도 상대가 조용히 버릴 수 있다.

• lwIP
• TCPIP
• Checksum
• Ethernet MAC
• +2

DoIP에서 Routing Activation까지는 되는 것 같은데 UDS 응답이 가끔 다른 요청에 붙거나 timeout처럼 사라져 보이면, ECU보다 먼저 Source Address를 누가 같이 쓰고 있는지 확인해야 한다. 같은 SA를 공유하면 응답 매칭과 세션 문맥이 쉽게 꼬인다.

• DoIP
• UDS
• Source Address
• Routing Activation
• +2

lwIP의 TCP_SND_BUF, TCP_WND, MEM_SIZE, MEMP_NUM_TCP_SEG, PBUF_POOL_SIZE가 각각 어떤 병목을 만들고 어떤 메모리 예산과 연결되는지 일반화된 예시로 정리한다.

• lwIP
• TCP
• MEM_SIZE
• PBUF_POOL
• +2

lwIP에서 UDP는 처음엔 잘 되는데 몇 분 뒤부터 recv callback이 끊기거나 pbuf_alloc 실패가 보이면, 드라이버보다 먼저 RAW UDP callback에서 pbuf_free를 빠뜨린 경로를 확인해야 한다. 작은 누수 하나가 PBUF_POOL 고갈로 이어져 전체 RX 경로를 막을 수 있다.

• lwIP
• UDP
• pbuf
• PBUF_POOL
• +2

DoIP에서 긴 UDS 작업 중 NRC 0x78 Response Pending이 오는 동안 Tester Present를 같은 소켓과 같은 요청 흐름에 무심코 섞어 보내면, 대기 중인 서비스 응답과 keepalive 목적의 세션 유지 요청이 충돌해 로그 해석과 재시도 정책이 쉽게 꼬인다. 두 흐름을 분리해 관리하는 편이 안전하다.

• DoIP
• UDS
• Tester Present
• Response Pending
• +2

Wireshark의 Reassembled TCP Segments 메시지가 의미하는 것과 TCP sequence number, 상위 계층 PDU length, reassembly 옵션 기준을 예제로 설명한다.

• Wireshark
• TCP
• TCP Reassembly
• Packet Capture
• +1

lwIP 포팅에서 링크는 정상이고 인터럽트도 도는데 UDP payload나 ARP 내용이 가끔 깨져 보이면, pbuf보다 먼저 DMA 버퍼와 CPU D-Cache 일관성을 확인해야 한다. RX 전 invalidate, TX 후 clean 순서가 어긋나면 랜덤 패킷 손상처럼 보이는 증상이 반복된다.

• lwIP
• DMA
• D-Cache
• RX Buffer
• +2

DoIP에서 UDS 요청이 길어질 때 CAN의 ISO-TP처럼 프레임을 쪼개어 처리하려 들면 길이 계산, 재전송, 응답 매칭이 쉽게 꼬인다. DoIP는 TCP stream 위에서 Generic Header의 payload length로 메시지 경계를 잡고, UDS 한 요청을 Diagnostic Message 단위로 다루는 편이 안전하다.

• DoIP
• UDS
• ISO-TP
• Diagnostic Message
• +2

lwIP 같은 RTOS 기반 TCP/IP stack에서 송신 재시도 루프를 아무 대기 없이 반복하면 busy loop가 되어 오히려 네트워크 thread와 다른 task의 실행을 방해할 수 있다. 짧은 RTOS delay와 timeout을 함께 두면 CPU 양보와 무한 대기 방지를 동시에 챙길 수 있다.

• lwIP
• TCP
• RTOS
• FreeRTOS
• +2

lwIP에서 tcpip_callback, netif callback, 내부 이벤트 훅 안에서 netconn 또는 sockets API를 다시 호출하면 부하가 낮을 때는 지나가도 어느 순간 전체 네트워크가 멈출 수 있다. 같은 tcpip_thread가 자기 자신에게 일을 보내고 완료를 기다리는 self-deadlock 패턴이라, 호출 컨텍스트를 분리해 두는 편이 안전하다.

• lwIP
• TCPIP
• tcpip_thread
• netconn
• +2

DoIP에서 Security Access 자체는 되는 것 같은데 unlock 직후 요청이 NRC 0x24 Request Sequence Error로 실패하면, key 계산보다 먼저 seed/key 순서와 세션 문맥이 유지됐는지 봐야 한다. 재연결, 세션 전환, 병렬 요청이 끼면 같은 ECU라도 이전 unlock 흐름이 쉽게 무효화된다.

• DoIP
• UDS
• Security Access
• NRC
• +2

lwIP에서 UDP 수신 데이터가 가끔 중간에서 잘리거나 길이가 들쭉날쭉해 보이면 드라이버보다 먼저 pbuf 체인 처리 코드를 확인해야 한다. 첫 pbuf의 len만 보고 전체 길이로 오해하면 큰 프레임, 정렬 차이, pool 분할 상황에서 재현이 애매한 버그가 생긴다.

• lwIP
• pbuf
• UDP
• tot_len
• +2

DoIP에서 UDS ECU Reset 이후 연결이 살아 있는 것처럼 보이는데 다음 진단이 실패하면, ECU 애플리케이션보다 먼저 소켓 종료, Routing Activation 재수행, Tester Present 재개 순서를 확인해야 한다. reset 전후를 같은 세션으로 취급하면 ACK는 보이는데 실제 UDS가 안 붙는 식으로 쉽게 꼬인다.

• DoIP
• UDS
• ECU Reset
• Routing Activation
• +2

lwIP에서 케이블 재삽입이나 스위치 복구 뒤 링크는 살아 있는데 UDP 송신이 한동안 안 나가거나 첫 패킷만 사라지는 경우가 있다. DHCP보다 아래층인 ARP 캐시와 netif 상태 전환이 어긋나면 생기는 전형적인 증상이라, link up/down 로그와 ARP 해상도 흐름을 같이 보는 편이 빠르다.

• lwIP
• ARP
• UDP
• netif
• +2

DoIP에서 UDS 요청 후 NRC 0x21 Busy Repeat Request가 반복되면 ECU가 죽은 게 아니라 아직 같은 자원을 점유 중인 경우가 많다. timeout과 같은 정책으로 재전송하면 세션이 더 꼬일 수 있어서, 0x21 전용 retry 간격과 요청 직렬화 기준을 따로 두는 편이 안전하다.

• DoIP
• UDS
• NRC
• Busy Repeat Request
• +2

PHY 링크는 올라왔고 RX/TX 카운터도 움직이는데 lwIP DHCP가 시작되지 않거나 재연결 뒤에 IP를 다시 못 받는 경우가 있다. 대부분은 netif_set_up(), netif_set_link_up(), dhcp_start() 호출 순서와 상태 전환 타이밍 문제다. bring-up 관점에서 자주 틀리는 포인트를 정리한다.

• lwIP
• DHCP
• netif
• Link Status
• +2

DoIP에서 Routing Activation까지는 성공했는데 첫 UDS 요청만 간헐적으로 실패하면, ECU 로직보다 먼저 SA/TA와 재연결 이후 상태를 의심해야 한다. ACK/NACK, 무응답, 다른 ECU로 간 것처럼 보이는 증상을 같은 그림으로 정리한다.

• DoIP
• UDS
• Routing Activation
• Source Address
• +2

Packet Capture Command Cookbook의 tcpdump, tshark, dumpcap, udpdump 명령어 모음과 검색/필터/복사 기능, capture filter와 display filter 차이, pcap 보안 주의사항을 정리한다.

• tools.devbj.com
• Packet Capture
• tcpdump
• tshark
• +2

lwIP RAW TCP에서 전송이 몇 KB/몇 초 뒤에 멈추고 상대는 재전송만 하는데, 링크는 살아있는 경우가 있다. 대부분은 수신 콜백에서 tcp_recved()를 호출하지 않아 TCP receive window가 열리지 않는 문제다. 증상과 수정 포인트를 실무 관점으로 정리한다.

• lwIP
• TCP
• RAW API
• tcp_recved
• +2

DoIP는 UDP처럼 '패킷 단위'로 읽히지 않는다. recv() 결과를 그대로 DoIP 메시지로 간주하면 부하에서 payload length mismatch/NACK/무응답이 터진다. TCP stream 기준으로 DoIP framing을 구현하는 안전한 순서를 정리한다.

• DoIP
• TCP
• Parser
• Framing
• +2

Ethernet CRC-32 계산 결과와 실제 wire에 붙는 FCS byte order가 왜 다르게 보이는지, 0xCBF43926과 26 39 F4 CB 예제로 정리한다.

• Ethernet
• CRC32
• FCS
• Byte Order
• +1

Ethernet CRC and FCS Calculator 사용법과 CRC-32/FCS byte order, captured frame trailer 검증 예제를 정리한다.

• tools.devbj.com
• Ethernet
• CRC32
• FCS
• +1

Secure Password and Salt Generator의 password length, character group, ambiguous character, salt byte length, entropy 표시를 어떻게 쓰면 좋은지 정리한다.

• tools.devbj.com
• Password
• Salt
• Web Crypto
• +1

JWT Decoder and Header Inspector 사용법과 header, payload, registered claim, expiration status를 볼 때 주의할 점을 정리한다.

• tools.devbj.com
• JWT
• Security
• Base64URL
• +1

Regex Live Tester and Cheat Sheet 사용법과 flags, capture group, named group, replacement preview를 확인하는 방법을 정리한다.

• tools.devbj.com
• Regex
• JavaScript
• Text Processing
• +1

Base64 String and Binary Converter 사용법과 URL-safe alphabet, padding, line wrapping, byte inspector 옵션을 정리한다.

• tools.devbj.com
• Base64
• Encoding
• UTF-8
• +1

JSON Parser and Tree Viewer의 format, minify, syntax error hint, tree viewer 기능과 API 응답 확인에 쓰는 방법을 정리한다.

• tools.devbj.com
• JSON
• API
• Formatter
• +1

DNS Lookup and TTL Inspector의 record type, TTL countdown, cache age, CNAME chain 기능을 어떻게 쓰면 좋은지 정리한다.

• tools.devbj.com
• DNS
• TTL
• Networking
• +1

Subnet Mask and CIDR Visualizer 사용법과 CIDR prefix, network address, broadcast address, usable host range를 확인하는 방법을 정리한다.

• tools.devbj.com
• Subnet
• CIDR
• Networking
• +1

tools.devbj.com의 Visual Traceroute Sandbox가 어떤 상황에서 유용한지, Run/Step/Reset과 route profile, packet loss 옵션을 어떻게 쓰면 좋은지 정리한다.

• tools.devbj.com
• Traceroute
• Networking
• TTL
• +1

Astro 블로그에서 글별 동적 OG 이미지를 만들 때 템플릿 구성과 캐시 정책을 분리해야 빌드 시간과 유지보수 문제가 줄어든다.

• Astro
• OpenGraph
• Satori
• OG Image
• +1

Astro에서 dev 서버에서는 정상인데 build 결과나 GitHub Pages 배포 후 이미지, 검색, 경로, 스타일이 깨지는 경우 확인할 체크리스트를 정리한다.

• Astro
• Build
• Debugging
• Vite
• +1

Astro 블로그에서 RSS, sitemap, canonical URL, robots.txt 같은 기본 색인 요소를 어떻게 확인해야 검색엔진이 새 글을 놓치지 않는지 정리한다.

• Astro
• RSS
• Sitemap
• SEO
• +1

Astro 기술 블로그에서 Markdown 코드블록에 파일명 표시와 복사 버튼을 붙이면 독자가 코드 위치와 사용법을 더 빨리 이해할 수 있다. 구현 시 고려할 점을 정리한다.

• Astro
• Markdown
• Code Block
• Developer Experience
• +1

Astro와 Tailwind로 만든 블로그에서 사이드 광고를 제거한 뒤 오른쪽 공간이 남거나 제목만 좁게 보일 때 확인해야 할 max-width와 공용 레이아웃 규칙을 정리한다.

• Astro
• TailwindCSS
• Layout
• UI Debugging
• +1

Astro 블로그를 GitHub Actions로 배포할 때 의존성, OG 이미지, 검색 색인 같은 반복 작업을 캐시 관점에서 어떻게 줄일 수 있는지 정리한다.

• Astro
• GitHub Actions
• Build Cache
• GitHub Pages
• +1

Astro 블로그에서 public 이미지와 src/assets 이미지의 차이를 운영 관점으로 나누고, 삽화와 OG 이미지 같은 파일을 어디에 두면 좋은지 정리한다.

• Astro
• Images
• WebP
• Performance
• +1

Astro 블로그에서 카테고리 페이지를 단순 글 목록이 아니라 시리즈 목차와 로드맵처럼 구성하면 검색 유입과 내부 이동에 어떤 장점이 있는지 정리한다.

• Astro
• Category
• Content Strategy
• Tech Blog
• +1

Astro 정적 블로그에 검색 기능을 붙일 때 Pagefind를 쓰면 어떤 점이 좋은지, 색인 생성과 배포 흐름에서 무엇을 확인해야 하는지 정리한다.

• Astro
• Pagefind
• Search
• Static Site
• +1

Astro Content Collections에서 frontmatter를 어떻게 정리해야 글 목록, 태그, 카테고리, SEO가 덜 꼬이는지 실제 운영 관점으로 정리한다.

• Astro
• Content Collections
• Frontmatter
• Tech Blog
• +1

Astro 블로그에서 글마다 OG 이미지를 생성하면 글이 늘어날수록 빌드 시간이 길어진다. 매번 새로 만들 필요 없는 PNG를 캐시하고, 새 글이나 변경된 글만 다시 생성하는 방식으로 빌드를 줄이는 사고방식을 정리한다.

• Astro
• OpenGraph
• Build Cache
• GitHub Actions
• +2

DoIP나 lwIP처럼 깊지만 검색량이 좁은 주제를 쓰다 보면 블로그 유입이 잘 늘지 않는다. 이때 전문성을 버리지 않고, 유입용 글을 어디에 배치해야 블로그가 덜 산만해지는지 카테고리 기준을 정리한다.

• Tech Blog
• Category
• SEO
• Content Strategy
• +2

Codex 등 AI 도구로 기술 블로그를 작성할 때 맡겨도 되는 작업과 사람이 직접 검토해야 하는 내용을 구분합니다.

• Codex
• AI Writing
• Technical Blog

lwIP를 bare-metal(NO_SYS)로 붙였는데 DHCP/ARP/TCP가 '가끔' 이상해지는 경우가 있다. 원인은 타이머 처리 루프를 안 돌린 경우가 많다. sys_check_timeouts()를 어디서/얼마나 자주 돌려야 하는지, 그리고 빠졌을 때 나타나는 전형적인 증상을 현장 관점에서 정리한다.

• lwIP
• NO_SYS
• sys_check_timeouts
• DHCP
• +2

TCP는 붙고 Vehicle Identification도 되는데 Routing Activation/UDS가 안 될 때가 있다. 이때 패킷 필드를 무작정 붙잡기 전에, DoIP의 Entity Status/Power Mode 같은 상태성 정보를 써서 '지금 진단 가능한 상태인지'를 먼저 확인하는 디버깅 흐름을 정리한다.

• DoIP
• Entity Status
• Power Mode
• Vehicle Identification
• +2

DoIP Vehicle Discovery가 간헐적으로 실패하는 원인은 UDS보다 UDP broadcast, interface 상태, gateway boot timing, retry 정책, discovery cache 관리에 있는 경우가 많다.

• DoIP
• Vehicle Discovery
• UDP Broadcast
• Automotive Ethernet
• +2

DoIP에서는 TCP 연결 endpoint와 실제 진단 대상 ECU가 다를 수 있다. Gateway 기반 차량 네트워크에서 logical address, routing activation, internal forwarding, response source tracking을 어떻게 봐야 하는지 정리한다.

• DoIP
• Gateway Routing
• Logical Address
• Automotive Ethernet
• +2

DoIP firmware download에서는 작은 진단 요청 때 보이지 않던 TCP stream 처리, large payload, timeout, flash latency 문제가 한꺼번에 드러난다. TransferData 흐름과 parser 안정성 관점에서 정리한다.

• DoIP
• Firmware Download
• UDS TransferData
• Automotive Ethernet
• +2

DoIP Negative Acknowledge와 UDS Negative Response는 완전히 다른 레이어의 신호다. DoIP NACK는 transport/protocol 문제이고, UDS 0x7F는 diagnostic application 문제라는 점을 로그와 파서 관점에서 정리한다.

• DoIP
• Negative Acknowledge
• UDS Negative Response
• Automotive Ethernet
• +2

lwIP에서 네트워크가 '가끔만' 죽는 이슈는 pbuf 수명주기 문제인 경우가 많다. 특히 PBUF_REF/zero-copy를 섞으면 버퍼 재사용 타이밍이 한 번만 어긋나도 랜덤 크래시가 난다. pbuf 타입별 수명주기와 실무에서 자주 터지는 함정을 짧게 정리한다.

• lwIP
• pbuf
• PBUF_REF
• Zero-copy
• +2

DoIP에서 Diagnostic ACK를 봤는데 UDS 응답이 없으면 보통 'ACK를 UDS 응답으로 착각'한 경우가 많다. DoIP ACK/NACK는 DoIP 레벨 신호고, UDS 응답(Positive/Negative/NRC)은 별개다. ACK/NACK를 디버깅 힌트로 쓰는 관점을 정리한다.

• DoIP
• UDS over IP
• Diagnostic ACK
• Diagnostic NACK
• +2

DoIP functional request는 특정 ECU 하나를 대상으로 하는 physical request와 다르다. 하나의 요청에 여러 ECU가 응답할 수 있고, 응답 순서도 보장되지 않는다. 그래서 response collection, source tracking, timeout policy가 중요하다.

• DoIP
• Functional Address
• UDS functional request
• Automotive Ethernet
• +2

이더넷 IRQ에서 패킷 받자마자 lwIP API를 호출하면, 어떤 보드에서는 잘 돌아가고 어떤 보드에서는 랜덤하게 죽는다. 원인은 대부분 컨텍스트/락 문제다. ISR에서 할 일과 tcpip_thread로 넘길 일을 분리하는 패턴을 짧게 정리한다.

• lwIP
• RTOS
• tcpip_thread
• tcpip_callback
• +2

DoIP는 TCP라서 붙기만 하면 끝인 줄 아는데, 실무에서는 가만히 두면 어느 순간 세션이 끊기는 경우가 많다. Alive Check, TCP Keepalive, UDS Tester Present는 목적이 다르다. 끊김을 줄이려면 이 셋을 분리해서 설계해야 한다.

• DoIP
• Alive Check
• TCP Keepalive
• Routing Activation
• +2

DoIP 디버깅하다 보면 은근 자주 보이는 패킷이 하나 있다. 처음 보면 좀 이상하다. 특별한 데이터도 없음 ECU 제어도 아님 읽는 것도 아님 근데 계속 주기적으로 날아간다. 이게 바로: Tester Present Session 유지 메시지 다. 오

• UDS Tester Present
• S3 timeout
• DoIP session keep alive
• UDS over IP
• +1

DoIP 붙이고 나서 많이 하는 착각이 하나 있다. “연결됐으면 이제 다 되는 거 아닌가?” 근데 실제 ECU는 그렇지 않다. TCP 연결 성공 Routing Activation 성공 UDS 요청도 감 근데 중요한 기능은 안 된다. 왜냐면 아직 ECU

• UDS Session Control
• Diagnostic Session
• DoIP UDS
• Extended Session
• +1

DoIP로 기본 통신까지 붙고 나면 다음에 거의 반드시 만나게 되는 게 있다. 바로: Security Access Seed / Key Unlock 절차 이쪽이다. 처음에는 그냥 인증 정도로 보이는데, 실제로 들어가 보면 ECU마다 구현 차이도 크고 디

• UDS Security Access
• Seed Key
• DoIP Security
• UDS over IP
• +1

DoIP 구현하다 보면 결국 여기까지 온다. 요청 보냈다 ECU 응답 기다린다 근데 바로 응답 안 온다 이때 timeout을 어떻게 처리하느냐가 꽤 중요하다. 특히 Response Pending(0x78) 을 제대로 처리 안 하면 멀쩡한 ECU도 실패

• UDS timeout
• Response Pending
• NRC 0x78
• DoIP debug
• +1

DoIP 디버깅하다 보면 이런 순간이 온다. 패킷은 정상 Routing Activation도 성공 ECU 응답도 옴 근데 결과가 실패다. 이럴 때 대부분은 UDS Negative Response 를 보고 있는 상황이다. 처음에는 “통신은 되는데 왜 실

• UDS Negative Response
• NRC
• DoIP debug
• Automotive Ethernet
• +1

앞에서 헤더까지 봤으면 이제 진짜 중요한 걸 볼 차례다. UDS 메시지가 DoIP 위에서 실제로 어떻게 전달되는지 이 부분이다. 결론부터 말하면 단순하다. DoIP는 “운반”, UDS는 “내용” 즉, DoIP는 박스고, UDS는 그 안에 들어가는 물건

• DoIP Diagnostic Message
• UDS over IP
• Automotive Ethernet
• DoIP debug
• +1

DoIP에서 Vehicle Identification이 어떤 역할을 하며, IP 기반 진단 연결 전에 차량과 ECU를 어떻게 발견하는지 정리합니다.

• DoIP
• VID
• Vehicle Identification
• discovery
• +3

DoIP에서 TCP 연결 이후 Routing Activation이 왜 필요하고, 여기서 진단 요청이 막히는 이유가 무엇인지 정리합니다.

• DoIP
• Routing Activation
• UDS
• Automotive
• +3

DoIP 패킷을 읽기 위한 header, protocol version, payload type, payload length의 기본 구조를 차근차근 정리합니다.

• DoIP 헤더
• DoIP 프로토콜 구조
• DoIP Payload Type
• DoIP Payload Length
• +6

CAN 기반 진단에 익숙한 사람이 DoIP를 처음 볼 때 헷갈리는 큰 그림을 정리한다. DoIP가 왜 나왔고, UDS와 어떤 관계인지, Vehicle Identification부터 Routing Activation까지 기본 흐름을 가볍게 훑는다.

• DoIP
• DoIP 개론
• UDS on DoIP
• CAN 진단
• +1

Astro View Transitions 환경에서 AdSense가 첫 화면에만 나오고 페이지 전환 후 비는 이유와 확인 순서를 정리합니다.

• Astro
• AdSense
• View Transitions

Astro와 MDX를 활용하여 고성능 기술 블로그를 구축하는 첫 번째 단계로, 개발 환경 설정 및 프로젝트 초기화 방법을 다룬다.

• Embedded
• TechLog
• Astro
• MDX
• +2

Astro 정적 사이트 제너레이터를 사용하여 GitHub Pages에 개인 기술 블로그를 배포하고, 커스텀 도메인을 연동하는 전 과정을 상세히 정리했다.

• Embedded
• TechLog

Tailwind CSS v4를 사용하여 AstroPaper 테마의 본문 너비를 확장하고, 대형 모니터에서만 노출되는 우측 사이드바 광고 영역을 추가하는 방법을 정리합니다.

• Astro
• TailwindCSS
• WebDev
• UI/UX