강의자료 pdf파일

안녕하세요, 답변 남겨드립니다.강의 내용에 대한 pdf교안 파일은 모두 업로드 되어있긴한데, 혹시 어떤 내용인지 예를 들어주실 수 있으실까요? 제가 확인해서 빠진게 있다면 업로드해서 안내드리겠습니다.몇번째 강의에 어떤 내용인지 구체적으로 알려주시면 제가 최대한 빨리 확인해서 처리해드리겠습니다!문의 감사합니다.

7. 임베디드 보드 Schematic 설계 - Component Library 및 Symbol 생성 // Mixed_signal 라이브러리

안녕하세요, 답변 남겨드립니다.이번 강의의 본편 범위는 STM32F103 보드를 새로 설계하는 것이 아니라, SOM(System On Module) 보드를 설계하는 흐름에 맞춰져 있습니다. 다만 수강 과정에서 KiCAD를 처음 다루시는 분들이 보통 라이브러리 구조나 심볼/풋프린트 연결, 프로젝트 세팅에서 막히는 경우가 많아서, 그 부분을 미리 정리하기 위한 목적의 사전강의를 커리큘럼 앞단에 포함해두었습니다.여기서 사전강의로 안내된 내용은 인프런의 “STM32 PCB HW 설계” 강의 일부를 기반으로 하고 있는데, 이 파트의 목적은 STM32F103 자체를 설계 대상으로 삼기 위함이 아닙니다. 예를 들어 KiCAD에서 심볼 라이브러리를 추가하는 방법, 심볼에 풋프린트를 매핑하는 방법, 라이브러리 테이블(프로젝트/글로벌) 개념, ERC/DRC를 돌리기 전 점검 포인트 같은 “툴 사용 및 설계 데이터 관리 방식”을 학습하기 위한 용도입니다. 즉, STM32F103을 실제로 BOM/PCB까지 완성하는 과제형 진행이 아니라, KiCAD에서 설계 자산을 다루는 감각을 익히는 워밍업 단계라고 보시면 됩니다.따라서 현재 수강 중인 SOM 설계 강의 폴더(또는 제공 라이브러리)에서 STM32F103 심볼이 보이지 않는 것은 정상입니다. STM32F103 심볼은 SOM 설계 강의에 포함된 것이 아니라, 말씀드린 “STM32 PCB HW 설계” 강의 측 라이브러리에 포함되어 있는 구성입니다. 이 부분은 강의 범위와 제공 자료가 분리되어 있기 때문에 발생하는 현상이며, 지금 단계에서 STM32F103 심볼을 찾는 데 시간을 쓰실 필요가 없습니다.지금 진행 단계에서는 SOM 설계에 필요한 라이브러리만 확인해서 따라오시면 됩니다. 예를 들어 SOM 커넥터/보드투보드 커넥터, 전원 관련 소자(레귤레이터, 인덕터, 커패시터), 인터페이스 커넥터, 테스트포인트, 마운팅 홀 등 SOM 설계에 직접 사용되는 심볼/풋프린트가 정상적으로 로드되고, 회로도에서 풋프린트 할당이 문제없이 되는지만 체크하시면 충분합니다. 만약 KiCAD에서 라이브러리 인식이 꼬여서 SOM 심볼/풋프린트가 안 보이는 경우에만, 사전강의에서 다룬 방식대로 라이브러리 경로 설정과 테이블 등록을 점검해주시면 됩니다.정리하면, STM32F103 심볼이 현재 SOM 설계 강의 자료에 없는 것은 의도된 구성이고 정상 동작입니다. 사전강의는 “STM32를 설계하려고” 넣은 것이 아니라 “KiCAD 사용법을 빠르게 표준화하려고” 넣은 것이며, 현재는 SOM 라이브러리만 기준으로 진행하시면 됩니다.

강의 자료 문의

안녕하세요, 답변 남겨드립니다.강의 실행하시고 커리큘럼에 보시면 다운받을 수 있는 표기 확인해보시면 됩니다!(사진)이런식으로 표기되어있습니다.

강의 pdf 자료

안녕하세요. 답변드립니다.교안은 「회로설계 Road-map으로 헷갈리는 회로설계 직무 체계 정리하기」챕터에 자료로 있습니다.해당 강의의 챕터를 확인해 보시고, 자료를 다운로드하시면모든 챕터의 강의 자료를 받아보실 수 있습니다.감사합니다. 정리하기

7장 Mixed_signal 라이브러리 다운

안녕하세요, 답변 남겨드립니다.문의주신 7장 Mixed_signal 라이브러리는 [Schematic 설계 실습 1] LPDDR4 schematic 설계하기 - 1 강의 자료에 업로드해 두었습니다.해당 강의의 자료(첨부/리소스)에서 다운로드하셔서 KiCad에 라이브러리로 등록하시면 됩니다.또한 동일 내용으로 메일로도 공지드리겠습니다.감사합니다.

kicad 라이브러리 추가 방법

안녕하세요, 답변 남겨드립니다.KiCad에서 기본 글로벌 라이브러리에 없는 부품을 쓰는 표준적인 방법은 “심볼 라이브러리 테이블(sym-lib-table)”과 “풋프린트 라이브러리 테이블(fp-lib-table)”에 내가 가진 라이브러리를 등록해 두고, 회로도에서는 심볼을, PCB에서는 풋프린트를 각각 선택해서 매칭시키는 방식입니다. 이때 글로벌 테이블에 추가하면 모든 프로젝트에서 공용으로 보이고, 프로젝트 테이블에 추가하면 해당 프로젝트에서만 보이는데, KiCad 공식 문서에서도 이 두 테이블 구조(글로벌/프로젝트)를 전제로 설명하고 있습니다.실무 관점에서는 “프로젝트 재현성” 때문에 프로젝트 전용 라이브러리를 우선 권합니다. 예를 들어 mixed-signal 보드처럼 MCU, ADC/DAC, PHY, 전원IC, 커넥터가 섞이면 부품 수가 80~250개 수준으로 금방 커지고, 팀원/PC/OS가 바뀌는 순간 글로벌 라이브러리 경로가 깨지면 하루가 통째로 날아갈 수 있습니다. 그래서 보통 프로젝트 폴더 아래에 라이브러리 폴더를 같이 넣고, 경로는 ${KIPRJMOD}(현재 프로젝트 디렉터리 변수) 기반으로 잡습니다. KiCad는 이런 “경로 치환 변수(path substitution variables)”로 라이브러리 위치를 유연하게 관리하는 워크플로우를 공식 문서에서 권장합니다.구체적인 추가 절차는 다음 흐름으로 이해하시면 됩니다. 먼저 심볼은 .kicad_sym 파일(또는 심볼 라이브러리 폴더) 형태로 준비하고, 풋프린트는 보통 xxx.pretty 폴더 안에 .kicad_mod들이 들어있는 형태로 준비합니다. 그런 다음 회로도 편집기에서 “설정/Preferences → 심볼 라이브러리 관리(Manage Symbol Libraries…)”로 들어가 프로젝트 탭에 심볼 라이브러리를 추가하고, PCB 편집기에서 “설정/Preferences → 풋프린트 라이브러리 관리(Manage Footprint Libraries…)”로 들어가 프로젝트 탭에 xxx.pretty 폴더를 추가하시면 됩니다. 이 글로벌/프로젝트 테이블 편집 위치 자체는 KiCad 문서에 그대로 정리돼 있습니다. 이후 회로도에서 심볼을 배치한 뒤, 해당 심볼의 속성에서 Footprint 필드에 방금 등록한 풋프린트를 지정하면 매칭이 끝납니다. 실무에서 자주 하는 방식은 “심볼은 제조사/부품군 단위로 묶은 하나의 .kicad_sym 라이브러리”, “풋프린트는 패키지군(LQFP.pretty, QFN.pretty, SOT.pretty 등) 단위 라이브러리”로 관리해서 검색 시간을 줄이는 쪽입니다.부품을 어디서 가져오느냐가 핵심인데, 디지키처럼 유통사에서 바로 KiCad 심볼/풋프린트를 제공하는 경우도 있지만, 그렇지 않은 부품이 훨씬 많습니다. 이때 현업에서 많이 쓰는 경로는 크게 세 갈래입니다. 첫째는 SnapEDA 같은 CAD 라이브러리 검색 서비스를 통해 KiCad용 심볼/풋프린트/3D 모델을 받아오는 방식입니다. SnapEDA는 KiCad 심볼/풋프린트 다운로드를 직접 지원한다고 안내하고 있고, 내려받은 압축파일 구조(.pretty, .kicad_sym 등)를 유지하라는 가이드도 제공합니다. 둘째는 제조사 공식 페이지의 “CAD Models / ECAD” 리소스를 활용하는 방식이고, 셋째는 GitHub에 공개된 검증된 라이브러리(회사/커뮤니티가 관리하는 KiCad 라이브러리 리포지토리)를 서브모듈처럼 붙여 쓰는 방식입니다. 특히 팀 단위로는 라이브러리를 Git으로 버전관리하면서 sym-lib-table/fp-lib-table을 같이 관리하는 패턴이 포럼에서도 자주 언급됩니다.다만 외부에서 받아온 라이브러리는 “그대로 믿고 쓰면 안 되고, 데이터시트로 치수를 역검증”하시는 게 mixed-signal 보드에서는 사실상 필수입니다. 예를 들어 STM32 LQFP-64(0.5 mm pitch) 같은 경우 핀피치가 촘촘해서 패드 폭을 0.30 mm로 잡는지 0.28 mm로 잡는지에 따라 솔더 브리징 리스크가 달라지고, 패드 길이도 리드 토(Toe) 여유를 0.3~0.5 mm 정도 확보하느냐에 따라 리워크 난이도가 달라집니다. 또 QFN(0.4~0.5 mm pitch)은 패드 아래 솔더마스크 정의(NSMD/SMD) 정책에 따라 솔더량이 크게 변해서, 외부 풋프린트가 IPC-7351 nominal을 따르는지, 아니면 특정 제조사 추천랜드패턴인지 확인하셔야 합니다. 실무에서는 “데이터시트의 recommended land pattern”이 있으면 그 치수를 1순위로 두고, 없으면 IPC-7351을 기준으로 하되 제조 공정(예: 4/4 mil 라우팅 한계, 마스크 정밀도, 드릴 공차)에 맞춰 미세 조정합니다. 정량적으로는 풋프린트 검증 체크리스트를 최소한 이런 수준으로 잡으면 사고가 확 줄어듭니다. 패드 간격과 패드 폭은 데이터시트 대비 오차를 ±0.05 mm 이내로 맞추고, 드릴 홀 부품은 finished hole 기준으로 공차를 고려해 0.10~0.20 mm 정도 여유를 두며, 코트야드(courtyard)는 조립 여유를 포함해 바디 외곽에서 0.25 mm 이상 확보하는 식으로 룰을 고정해두는 방식입니다. 이렇게 숫자를 정해두면 부품이 100개가 넘어가도 검증 기준이 흔들리지 않습니다.실제 예시로, 질문 주신 STM32 기반 mixed-signal 보드에서 “기본 글로벌 라이브러리에 없는 부품”은 보통 전원IC(특히 DFN/QFN), 아날로그 프런트엔드(ADC/DAC), 특수 커넥터, 특정 EMI 필터/커먼모드 초크 같은 것들입니다. 예를 들어 어떤 ADC가 WLCSP라면 외부 라이브러리에서 풋프린트를 구하는 것보다, 데이터시트를 보고 KiCad 풋프린트 에디터로 직접 만드는 쪽이 결과적으로 더 빠를 때가 많습니다. WLCSP는 볼 직경과 볼 피치(예: 0.35 mm pitch, ball 0.20 mm)가 제조 난이도를 결정하고, 솔더마스크 정의와 패드 형태가 수율을 좌우하므로 “내 보드 제조사 공정능력(최소 마스크댐, 레이저 비아 가능 여부)”에 맞춰 커스텀하는 게 안전합니다. 반대로 RJ45나 USB-C처럼 표준 커넥터류는 SnapEDA나 제조사 STEP/ECAD를 받아서 3D까지 포함해 쓰는 게 시간을 크게 줄여줍니다.마지막으로 운영 팁을 하나 더 드리면, 프로젝트 라이브러리를 쓰실 때는 프로젝트 폴더 아래를 libs/symbols, libs/footprints, libs/3dmodels처럼 고정해 두고, 심볼/풋프린트 라이브러리 테이블에는 절대경로 대신 ${KIPRJMOD}/libs/... 형태로만 등록하시면 협업성과 재현성이 크게 좋아집니다. 그리고 외부에서 받은 풋프린트는 첫 적용 때 3D 뷰와 실제 부품 도면을 맞대서 “핀1 방향, 바디 외곽, 코트야드, 실크 간섭”까지 확인한 다음, 첫 제작에서는 동일 패키지 1~2개는 리워크가 쉬운 위치로 배치해 두는 식으로 리스크를 줄이시는 게 현업적으로는 훨씬 효율적입니다.

수강기간변경

안녕하세요,문의주셔서 감사합니다.해당 강의는 무제한으로 바뀌었고, 공지를 한번 드리긴 했었는데기존 수강생 분들도 물론 무제한으로 바꿔드리고 있습니다!반영해드렸으니 확인해보시고 또 궁금한 점은 편히 문의주세요!

VIa에 GND 항목이 없습니다.

안녕하세요, 답변 남겨드립니다.지금 화면에서 VIA의 Net 목록에 GND가 안 뜨는 건 “GND를 따로 추가하는 절차를 놓쳤다”기보다는, 보드 안에 “GND라는 이름의 네트가 존재하지 않거나, 존재하더라도 이름이 GND가 아니라 다른 형태로 들어가 있는 상태”일 때 생깁니다. 스크린샷처럼 /ADC Chip/AIN0 같이 계층 경로가 붙은 네트들이 보이는 프로젝트에서는 특히 “그라운드도 계층형 로컬 라벨로 만들어져서 /Ethernet PHY/GND 같은 이름으로 존재”하거나, 반대로 “GNDA/DGND/PGND처럼 분리된 이름만 있고 GND는 애초에 없다”로 귀결되는 경우가 가장 많습니다.가장 빠른 확인은 지금 Net 드롭다운 위에 있는 Filter 칸에 GND를 그대로 타이핑해보시는 것입니다. 이때 /Ethernet PHY/GND, /Motor Driver Schematic/GND처럼 경로가 붙어 있어도 “문자열에 GND가 포함”되면 걸려야 정상입니다. 그런데 Filter에 GND를 넣었는데도 아무것도 안 나오면, 그 순간 거의 확정적으로 “이 PCB 데이터베이스 안에 GND 계열 네트가 아직 생성/전파되지 않았다”거나 “이름이 GND가 아니라 완전히 다른 이름”이라는 뜻입니다.그 다음 단계는 회로도에서 “정말로 GND 네트가 만들어져 있나”를 확인하셔야 합니다. 예를 들어 Ethernet PHY 블록에서 디커플링 캐패시터 하나(예: 0.1uF)의 한쪽 핀이 전원(VDD33 등), 다른 한쪽이 그라운드로 내려가야 하는데, 그 그라운드 쪽이 전원 심볼 GND로 연결돼 있지 않고 단순 와이어만 그려져 있거나, GNDA/DGND로 붙어 있거나, 또는 로컬 라벨로만 되어 있으면 PCB에서 “GND”라는 이름이 안 생길 수 있습니다. Mixed-signal에서 흔히 하는 방식처럼 아날로그 그라운드를 GNDA, 디지털을 DGND로 나눠 쓰셨다면 이건 정상 동작이고, VIA Net 목록에서 GND를 찾으시면 끝까지 안 나옵니다. 이 경우는 PHY 전원 디커플링이 DGND로 들어갔는지, 아날로그 블록의 레퍼런스/ADC 그라운드가 GNDA인지처럼 “의도된 네이밍”을 먼저 정리하시는 게 맞습니다.회로도에서 GND가 맞게 존재한다면, 다음으로는 보드에 넷 정보가 최신으로 반영됐는지 확인하셔야 합니다. 회로도 수정 후에 PCB로 업데이트가 안 된 상태면, PCB는 예전 넷 목록만 가지고 있어서 VIA Net 목록에 GND가 안 보일 수 있습니다. 이때는 회로도에서 PCB로 업데이트를 한 번 돌리신 뒤(풋프린트/넷 연결 반영), PCB에서 다시 VIA 속성 Net 목록을 보시면 GND가 생겨 있는 경우가 많습니다. 실무에서는 PHY 블록처럼 디커플링이 10개, 20개씩 붙는 회로에서 이 동기화가 한 번 빠지면 레이아웃 단계에서 “왜 넷이 없지”로 불필요하게 30분~수 시간씩 날아가는 일이 잦아서, 회로도 수정 직후 보드 업데이트를 습관처럼 하시는 게 효율이 좋습니다.만약 회로도에 GND 심볼도 있고 업데이트도 했는데도 여전히 GND가 안 뜬다면, 그때는 “같은 선에 다른 라벨을 붙여서 네트 이름이 GND가 아닌 다른 이름으로 확정된 상황”을 의심하시면 됩니다. 현업에서 실드 접지, 샤시 접지, 파워 접지를 분리하려고 SHIELD, CHASSIS, PGND 같은 라벨을 GND가 붙은 선에 추가하는데, 이런 경우 사용자는 GND라고 생각하지만 툴에서는 그 라벨 이름이 네트의 대표 이름으로 잡혀서 VIA 목록에서 GND가 사라진 것처럼 보입니다. 이 경우 해결은 단순해서, 해당 선에서 “GND로 유지할 건지, 아니면 SHIELD/CHASSIS/PGND처럼 분리 이름으로 갈 건지”를 결정하고 라벨을 정리하시면 됩니다. Ethernet 쪽에서는 특히 RJ45 실드 접지를 시스템 GND에 직결하지 않고 옵션 소자(예: 0Ω 옵션, RC 옵션)로 튜닝 포인트를 남기는 설계를 많이 하니, 네트 이름도 SHIELD_GND처럼 별도로 두는 게 오히려 더 실무적일 때가 많습니다.그리고 한 가지 더 중요한 포인트는, 스티칭 비아 목적이라면 “VIA를 찍고 Net을 수동으로 GND로 바꿔야만” 하는 건 아닙니다. 보통은 GND 구리존(Zone)을 먼저 깔고 그 존의 네트를 원하는 그라운드(DGND나 GND 등)로 지정한 다음, 스티칭 비아를 그 존 안에 배치해서 자동으로 접속되게 운용합니다. 이 방식은 VIA 속성에서 넷을 일일이 바꾸는 것보다 실수가 훨씬 적고, 특히 PHY 주변처럼 비아를 수십 개 박는 구간에서 작업 시간이 체감으로 2배 이상 단축되는 경우가 많습니다. 예를 들어 0.30mm 드릴, 0.60mm 패드 수준의 스티칭 비아를 2.0~3.0mm 피치로 PHY와 매그네틱 주변에 배치하면 리턴패스가 안정화되는 효과를 자주 보는데, 이때 넷이 확실히 잡혀 있어야 존이 제대로 물리고, 결과적으로 EMC/신호품질 쪽에서도 재작업이 줄어듭니다.위 과정까지 확인해보셨는데, 안보이신다면 한번 더 질문주시기 바랍니다.

디버거를 디버깅하려면

안녕하세요, 답변 남겨드립니다.좋은 질문이네요!말씀하신 “디버거를 디버깅하려면 또 다른 MCU가 필요하고, 그러면 끝없이 재귀로 이어지지 않느냐”는 의문은 아주 자연스럽고, 실제로 실무에서 디버깅 구조를 처음 잡을 때 많은 분들이 한 번은 반드시 걸리는 포인트입니다. 결론부터 정리하면, 재귀가 무한히 이어지지 않는 이유는 하드웨어 세계에는 애초에 “더 아래로 내려가지 않는 바닥층”이 존재하기 때문입니다. 그 바닥층은 대표적으로 MCU 내부의 ROM 부트로더(마스크 ROM)와, Cortex-M 계열에 하드웨어로 박혀 있는 디버그 포트(SWD/JTAG의 Debug Access Port) 같은 것들입니다. 이 부분은 사용자가 펌웨어를 올리기 전에도 이미 칩 안에 존재하고 동작하므로, 디버거용 MCU를 또 디버깅해야만만 출발할 필요가 없습니다.STM32를 PC에서 디버깅할 때 “PC와 타깃 MCU 사이에 또 다른 MCU가 필요하다”라고 이해하신 부분은, 많은 상용 디버그 프로브(ST-LINK, J-Link 등)가 내부적으로 MCU를 써서 USB 프로토콜 처리와 SWD/JTAG 신호 생성(또는 변환)을 하기 때문에 그렇게 보이는 면이 있습니다. 다만 구조적으로 중요한 것은 “디버깅에 꼭 별도 MCU가 필수인가”가 아니라, “PC가 바로 SWD/JTAG 전기 신호를 만들어 내기 어렵기 때문에 중간에 전용 장치(프로브)가 들어간다”는 점입니다. 그 전용 장치는 MCU일 수도 있고 FPGA/CPLD일 수도 있고, 경우에 따라서는 USB-to-JTAG 브리지 전용 칩일 수도 있습니다. 핵심은 프로브가 타깃의 SWDIO/SWCLK(또는 TMS/TCK 등)를 구동해 주면, 타깃 STM32 내부의 디버그 하드웨어가 즉시 반응한다는 것입니다. 즉, 타깃 쪽에는 “디버깅을 위해 추가 펌웨어가 먼저 올라가야 하는 단계”가 없습니다. 그래서 타깃 디버깅 자체는 무한 재귀와 무관하게 성립합니다.그렇다면 “프로브(디버거) 자체의 펌웨어는 최초에 어떻게 올리느냐”가 남는데, 여기서 ROM 부트로더가 바닥층으로 작동합니다. 실무 예시로 ST-LINK가 가장 설명이 쉽습니다. ST-LINK는 내부에 STM32 계열 MCU가 들어 있는 경우가 많고, 그 STM32에는 공장 출하 시점부터 ROM에 부트로더가 들어 있습니다. 이 ROM 부트로더는 사용자가 아무 펌웨어를 올리지 않아도 특정 핀 상태(부트 핀 조합)나 특정 인터페이스(UART/USB DFU 등)를 통해 플래시에 펌웨어를 써 넣을 수 있게 해줍니다. 즉 “디버거 MCU에 펌웨어를 올리기 위해 또 다른 디버거가 필요”한 게 아니라, 처음 한 번은 ROM 부트로더 같은 고정된 경로를 통해 올리거나, 제조 공정에서 전용 프로그래머로 써 넣습니다. 현업 양산 라인에서는 이 초기 프로그래밍을 보통 테스트/프로그래밍 지그에서 처리하고, 수율·속도를 위해 SWD 클럭을 보수적으로 1~4MHz 수준으로 잡아도 수 초 내에 수십~수백 KB 펌웨어를 충분히 씁니다. 이후에는 프로브 펌웨어 업데이트도 “다시 ROM 부트로더 모드로 진입해서” PC에서 업데이트하는 방식이 흔하고, 그래서 재귀 구조로 빠지지 않습니다.“디버거를 디버깅”해야 하는 경우도 실제로 있습니다. 예를 들어 사내에서 커스텀 SWD 프로브를 만들어 USB 통신 스택까지 직접 구현했다면, 그 프로브 MCU 펌웨어에 버그가 생길 수 있습니다. 이때도 무한 재귀로 가지 않고, 보통은 다음 중 하나로 해결합니다. 프로브 MCU가 가진 ROM 부트로더를 이용해 최소 기능(USB enumeration과 로그 출력만 되는) 진단 펌웨어를 먼저 올려서 문제를 좁히거나, 프로브 MCU에 대해서만은 별도의 외부 프로그래머(상용 J-Link나 ST-LINK, 혹은 생산용 SWD 프로그래머)를 연결해서 디버깅합니다. 여기서도 바닥층은 “외부 프로그래머” 또는 “ROM 부트로더”입니다. 그리고 프로브 수준에서는 펌웨어 디버깅보다 전기적 검증이 더 큰 비중을 차지하는 경우가 많아서, USB 프로토콜 애널라이저나 로직애널라이저로 D+ / D- 파형, SWCLK/SWDIO 토글, 리셋 시퀀스 등을 직접 보는 방식으로도 상당 부분 원인 분리가 됩니다. 예를 들어 SWDIO에 10~20ns급 링잉이 심하게 얹히면 10MHz 이상에서 디버그가 간헐적으로 끊길 수 있는데, 이건 “펌웨어 버그”가 아니라 신호 무결성 이슈라서 오실로스코프 한 번으로 바로 방향이 잡히는 편입니다.질문을 과제 맥락(보드 Power Budget)으로도 현실적으로 연결해 보면, 디버깅 구조를 보드에 “내장 ST-LINK”처럼 넣을지, “외부 디버거를 꽂는 커넥터(SWD 헤더)만 둘지”에 따라 전력 예산이 달라집니다. 외부 디버거를 쓰면 보드에서 추가로 먹는 전력은 거의 0에 가깝고(커넥터 풀업/레벨시프터 정도), 내장 디버거를 넣으면 그 디버거 MCU + USB PHY + LED 등이 상시로 수 mA~수십 mA를 소비할 수 있습니다. 보수적으로 잡으면 내장 디버거 블록은 3.3V에서 20mA 정도(= 66mW)만 잡아도 예산에는 충분히 안전측으로 들어가는 편이고, USB 전원으로 구동한다면 5V에서 20mA면 100mW로 환산됩니다. 이런 차이는 Mixed-signal 보드에서 LDO 발열, 아날로그 레일 노이즈 마진과도 연결되므로, 과제에서 전력 트리를 짤 때 “디버깅 인터페이스를 어떤 방식으로 구성했는지”가 실제 숫자로 영향을 줍니다. 강의 커리큘럼에서도 디버깅 인터페이스(JTAG/SWD) 핀 구성 파트를 별도로 다루는 이유가 여기에 있습니다.정리하면, 타깃 STM32 디버깅은 타깃 내부의 하드웨어 디버그 블록이 이미 바닥층이기 때문에 별도 MCU를 “연쇄적으로” 요구하지 않고, 디버거(프로브) 펌웨어도 ROM 부트로더나 생산용 프로그래머라는 바닥층을 통해 최초 주입이 가능해서 재귀가 무한히 이어지지 않습니다. 실무에서는 이 바닥층을 의도적으로 확보하기 위해, 커스텀 보드를 만들 때도 “최소 1개는 반드시 살아있는 프로그래밍 경로(예: SWD 헤더 또는 UART 부트 핀)”를 남겨 두는 것을 거의 표준 규칙처럼 가져갑니다.

강의 연장

안녕하세요,문의주셔서 감사합니다.해당 강의는 무제한으로 바뀌었고, 공지를 한번 드리긴 했었는데기존 수강생 분들도 물론 무제한으로 바꿔드리고 있습니다!반영해드렸으니 확인해보시고 또 궁금한 점은 편히 문의주세요!