디버거 관련하여 질문있습니다.

3 câu hỏi đã được viết

0

안녕하세요, 답변 남겨드립니다.

디버거는 메인 MCU의 프로그램을 대신 실행하는 장치라기보다, PC와 MCU 내부의 디버그 회로를 연결해 주는 통역기라고 보시면 됩니다. STM32의 Cortex-M 코어 내부에는 ARM CoreSight 계열의 디버그 회로가 들어 있고, 외부 디버거는 SWD 또는 JTAG 신호를 통해 이 회로에 접근합니다. PC에서 중단점을 설정하거나 한 줄씩 실행하면 디버거가 MCU의 CPU를 정지시키고, 현재 PC 값과 범용 레지스터, SRAM, 주변장치 레지스터를 읽어 IDE에 전달합니다. 변수 값을 강제로 변경하거나 Flash를 지우고 새로운 펌웨어를 기록하는 것도 같은 경로로 처리합니다.

STM32 프로젝트에서는 보통 SWD 방식을 사용합니다. 핵심 신호는 SWDIO와 SWCLK 두 개이며, 실제 커넥터에는 GND, Target Voltage Reference, NRST를 더해 보통 5개 신호를 연결합니다. 실행 추적이 필요하면 SWO까지 추가하여 6개 정도를 사용합니다. Target Voltage Reference는 디버거가 보드의 I/O 전압이 1.8 V인지 3.3 V인지 판단하기 위한 신호이지, 반드시 디버거가 보드에 전원을 공급한다는 의미는 아닙니다. 양산 보드에서 이 부분을 잘못 연결하면 보드 전원이 꺼진 상태에서 SWD 핀을 통해 역전류가 유입되는 문제가 생길 수 있어, 전원 공급과 전압 감지 기능을 구분해서 설계해야 합니다.

디버거 안에 별도의 MCU가 들어가는 이유는 USB 통신 처리, SWD/JTAG 타이밍 생성, Reset 제어, Flash Programming 알고리즘 실행을 실시간으로 담당해야 하기 때문입니다. 예를 들어 PC는 USB 패킷 단위로 명령을 전달하지만 SWD는 수 MHz 단위의 클럭과 비트 순서에 맞춰 응답을 주고받아야 하므로, 중간에서 이를 처리할 컨트롤러가 필요합니다. 개발 보드에 탑재된 ST-LINK 부분을 보면 별도의 STM32가 하나 더 들어 있는 경우가 많은데, 이 MCU는 제품 기능을 수행하는 메인 MCU가 아니라 디버거 역할만 담당합니다.

비용 측면에서는 최종 제품 PCB마다 디버거 MCU를 넣을 필요가 없습니다. 강의에서 디버거를 선택한 것은 보드 BOM에 항상 포함시키라는 의미가 아니라, 개발과 검증에 사용할 외부 장비를 정하는 과정입니다. 실제로는 PCB에 SWDIO, SWCLK, GND, VTref, NRST를 커넥터나 테스트 패드 형태로 빼고, 외부 ST-LINK나 J-Link, CMSIS-DAP 디버거 한 대를 여러 장의 보드에 번갈아 연결합니다. 커넥터 공간이 부담된다면 2.54 mm 헤더 대신 1.27 mm 헤더나 포고핀용 테스트 패드를 사용하여 면적을 수십 mm2 수준으로 줄일 수 있습니다. 강의에서도 MCU 부품 선택 이후 별도로 STM32 Debugging Pin 회로를 설계하도록 구성한 이유가 바로 이 개발용 인터페이스와 양산 BOM을 분리해서 이해시키기 위해서입니다.

MCU를 전혀 사용하지 않고 펌웨어를 넣는 방법은 있습니다. STM32 내부 ROM Bootloader를 이용하면 BOOT 핀 설정 후 UART, USB DFU, CAN 등의 지원 인터페이스로 프로그램을 기록할 수 있습니다. 다만 이것은 Programming 방법이지 Debugging 방법은 아닙니다. 프로그램을 다운로드할 수는 있어도 원하는 코드 위치에서 CPU를 멈추거나, 레지스터와 메모리를 실시간으로 확인하거나, Watchpoint를 설정하는 기능은 제한됩니다. UART printf, LED, GPIO 토글, 로직 애널라이저를 이용한 디버깅도 가능하지만, HardFault처럼 CPU가 갑자기 예외에 진입한 경우 원인을 찾는 데 걸리는 시간이 SWD 디버거 대비 몇 배 이상 늘어날 수 있습니다.

외부 디버거 내부에서도 반드시 범용 MCU만 사용해야 하는 것은 아닙니다. 전용 USB-to-JTAG/SWD 컨트롤러, FPGA, CPLD 또는 PC의 GPIO Bit-Banging 방식으로 구현할 수 있습니다. 하지만 소량의 교육용·개발용 장비에서는 32-bit MCU 한 개로 USB와 SWD를 모두 처리하는 방식이 비용, 펌웨어 업데이트, 호환성 측면에서 가장 현실적입니다. FPGA를 사용하면 타이밍 성능은 좋아질 수 있지만 부품 가격과 전원 회로, 구성 메모리까지 포함되어 오히려 BOM이 증가합니다.

이번 STM32 Mixed-signal 보드에서는 디버거 MCU를 본체 보드에 추가하기보다 외부 디버거를 사용하고, 본체에는 SWD 테스트 포인트를 남기는 구성이 적절합니다. 개발 단계에서는 NRST와 SWO까지 포함해 문제를 빠르게 찾고, 양산 단계에서는 제품의 부팅 방식과 제조 공정에 따라 SWD 패드를 유지할지 ROM Bootloader만 사용할지 결정합니다. 보통 디버그 패드는 생산 후 불량 분석과 펌웨어 복구에도 사용되기 때문에, 원가 절감을 위해 완전히 삭제하기보다는 포고핀 접근이 가능한 형태로 남겨 두는 편이 유지보수 리스크를 줄여줍니다.

0

안녕하세요, 인프런 AI 인턴입니다. ArcStro님.

디버거는 주로 메인 마이크로컨트롤러(MCU)와 연결하여 코드 실행 상태를 모니터링하고, 오류를 추적하며, 코드 라인별로 실행을 제어할 수 있도록 도움을 주는 장치입니다. 기본적으로 디버거는 JTAG(또는 SWD) 인터페이스를 통해 MCU와 통신하며, 다음과 같은 방식으로 동작합니다:

1. 브레이크포인트 설정: 디버거는 코드 중단점(브레이크포인트)을 설정하여 코드 실행을 특정 지점에서 일시중지할 수 있도록 합니다. 이를 통해, 개발자는 코드의 특정 부분을 자세히 검사할 수 있습니다.

2. 실행 제어: 한 줄씩 코드를 실행하거나(스텝 인/스텝 오버), 특정 조건이 충족될 때까지 코드 실행을 계속하는 방식으로 디버깅할 수 있습니다.

3. 상태 관찰: 메모리 값, 변수 상태, 레지스터 값 등을 실시간으로 감시할 수 있어 문제 원인을 파악하는 데 큰 도움을 줍니다.

4. 프로그램 로드 및 다운로드: 디버거는 컴파일된 바이너리 파일을 MCU에 다운로드하여 실행할 수 있으며, 펌웨어 업그레이드 작업도 수행합니다.

STM32 제품군 외에도 다양한 디버깅 도구가 있습니다. 예를 들어, Segger의 J-Link, P&E의 BDM 디버거, Atmel의 AVR 드래곤, Microchip의 MPLAB ICD 등이 있으며, 각 툴은 특정 MCU 및 프로세서 아키텍처에 맞춰 사용됩니다.

다양한 디버깅 도구는 각기 다른 특징과 상태 모니터링 기능을 제공할 수 있으며, 다소 복잡한 시스템에서는 여러 디버깅 인터페이스가 사용되기도 합니다. 이러한 도구는 각 에코시스템에 맞춰집니다.

관련해서 도움이 될 수 있는 유사 질문을 다음에서 확인하실 수 있습니다:
- STM32F103 schematic-Debugging pin 설계 강의 질문 : STM32 디버깅 관련하여 구체적인 설명이 포함되어 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.