Debug vi điều khiển với ST-Link và Logic Analyzer

Thói quen chèn printf("Vao day roi!\n") vào cổng UART là phản xạ đầu tiên của nhiều người khi bắt bệnh vi điều khiển. Tuy nhiên, trong các hệ thống nhúng thời gian thực (Real-time), cách làm này để lại 3 hệ quả nghiêm trọng. Để chẩn đoán lỗi nhanh và chính xác, giải pháp chuẩn mực là kết hợp ST-Link (Hardware Debugger) và Logic Analyzer.

Vì sao printf() có thể gây khó khăn khi debug vi điều khiển?

Khi debug vi điều khiển, nhiều người thường chèn printf() để in giá trị biến hoặc kiểm tra chương trình đã chạy đến đâu. Đây là cách tiện lợi khi thử nghiệm nhanh. Tuy nhiên, trong hệ thống nhúng thời gian thực, việc xuất log có thể làm thay đổi thời gian thực thi và khiến lỗi khó tái hiện hơn.

Làm tăng độ trễ khi truyền UART theo cơ chế blocking

Với UART cấu hình 8N1, mỗi byte cần 10 bit truyền, gồm bit bắt đầu, 8 bit dữ liệu và bit kết thúc. Một chuỗi 30 byte ở baudrate 9600 cần khoảng 31,25 ms để truyền hết trên đường dây.

Nếu printf() sử dụng UART theo cơ chế blocking, tác vụ gọi hàm phải chờ quá trình truyền hoàn tất. Việc in log liên tục có thể làm trễ chu kỳ đọc cảm biến, xử lý giao tiếp hoặc điều khiển động cơ. Truyền bằng ngắt hoặc DMA giúp giảm thời gian chờ của CPU, nhưng vẫn cần quản lý bộ đệm và lượng dữ liệu log.

Làm lỗi biến mất tạm thời

Có những chương trình chạy ổn khi thêm printf() nhưng lại treo khi bỏ lệnh in. Nguyên nhân có thể là độ trễ do xuất log vô tình thay đổi thứ tự thực thi, che khuất lỗi tranh chấp tài nguyên hoặc lỗi đồng bộ.

Hiện tượng lỗi thay đổi khi được quan sát thường được gọi là Heisenbug. Khi gặp tình huống này, thêm nhiều log chưa chắc giúp tìm đúng nguyên nhân.

Không cung cấp đầy đủ trạng thái khi hệ thống gặp lỗi

Log UART chỉ phản ánh những thông tin đã được lập trình để in ra. Nếu chương trình treo trước lệnh in, mắc kẹt trong vòng lặp hoặc đi vào HardFault_Handler, log có thể dừng đột ngột mà không cho biết trạng thái CPU tại thời điểm xảy ra lỗi.

Vì vậy, printf() nên được sử dụng kết hợp với các công cụ gỡ lỗi khác. ST-Link giúp kiểm tra luồng thực thi, bộ nhớ và thanh ghi; Logic Analyzer hỗ trợ quan sát tín hiệu giao tiếp thực tế trên đường mạch.

Debug STM32 bằng ST-Link qua giao diện SWD

ST-Link là công cụ nạp chương trình và gỡ lỗi STM32, hỗ trợ làm việc với các môi trường như STM32CubeIDE và Keil MDK. Thông qua giao diện SWD, người dùng có thể dừng CPU, chạy từng bước và kiểm tra trạng thái chương trình.

Kết nối ST-Link với bo mạch

Trước khi debug STM32 bằng ST-Link, cần xác định đúng chân kết nối trên mạch nạp và bo mạch đích. SWD sử dụng hai đường tín hiệu chính là SWDIO và SWCLK, đồng thời cần chung GND và kết nối nguồn tham chiếu theo thiết kế của thiết bị.

Không nhầm chân nguồn tham chiếu với chân cấp nguồn. Một số mạch nạp dạng module có đầu ra 3,3 V hoặc 5 V, trong khi ST-Link khác sử dụng chân đo điện áp mục tiêu. Cần kiểm tra đúng sơ đồ chân của thiết bị trước khi đấu nối.

Sau khi kết nối phần cứng, thực hiện các bước cơ bản:

• Cấp nguồn đúng yêu cầu cho bo STM32 và kiểm tra GND chung.
• Chọn ST-Link làm debugger, sử dụng giao diện SWD trong IDE.
• Biên dịch chương trình với thông tin debug và nạp xuống vi điều khiển.
• Bắt đầu phiên debug, đặt điểm dừng tại main() để kiểm tra kết nối.

Nếu IDE không nhận chip, hãy kiểm tra nguồn, dây SWDIO/SWCLK và cấu hình chân debug. Có thể thử giảm tốc độ SWD hoặc sử dụng chế độ kết nối dưới reset khi thiết bị hỗ trợ và đã nối NRST.

Breakpoint, Live Watch và thanh ghi ngoại vi

Khi kết nối thành công, ba nhóm công cụ dưới đây giúp khoanh vùng lỗi firmware hiệu quả hơn.

• Breakpoint: dừng chương trình tại vị trí cần kiểm tra
• Breakpoint cho phép dừng CPU tại một vị trí mã lệnh để kiểm tra biến, tham số và luồng xử lý. Ví dụ, khi STM32 không đọc được cảm biến I2C, có thể đặt breakpoint ngay sau hàm giao tiếp để xem mã trả về và nội dung bộ đệm.
• Sau khi dừng, sử dụng các thao tác chạy từng bước để xác định chương trình đi vào nhánh nào hoặc mắc kẹt tại đâu.

Cần lưu ý rằng dừng CPU vẫn làm thay đổi hành vi thời gian thực. Thiết bị ngoại vi bên ngoài có thể tiếp tục hoạt động trong khi firmware đã dừng, gây timeout hoặc mất đồng bộ giao tiếp.

Live Watch: theo dõi biến khi chương trình đang chạy

Live Watch hoặc tính năng tương đương trong IDE hỗ trợ cập nhật giá trị biến mà không cần liên tục dừng CPU. Công cụ này phù hợp để quan sát bộ đếm lỗi, trạng thái kết nối hoặc dữ liệu cảm biến biến đổi chậm. Tuy nhiên, giá trị được đọc theo chu kỳ của debugger, không phải được ghi nhận ở mọi chu kỳ CPU. Những thay đổi quá nhanh có thể bị bỏ lỡ. Khả năng quan sát còn phụ thuộc IDE, cấu hình debug và mức tối ưu hóa của trình biên dịch.

• Thanh ghi ngoại vi: kiểm tra trạng thái phần cứng
• Cửa sổ thanh ghi ngoại vi giúp đối chiếu cấu hình firmware với trạng thái thực tế của UART, I2C, SPI hoặc timer. Khi giao tiếp thất bại, có thể kiểm tra cờ bận, cờ lỗi và trạng thái bộ đệm thay vì chỉ dựa vào thông báo log.
• Tên cờ và cách xử lý khác nhau giữa các dòng STM32, vì vậy cần tra Reference Manual của đúng chip. Một số thanh ghi có tác dụng phụ khi đọc; không nên bật cập nhật liên tục nếu chưa hiểu cơ chế hoạt động của chúng.

Kiểm tra lỗi HardFault

HardFault là ngoại lệ báo hiệu một lỗi nghiêm trọng trong quá trình thực thi. Những nguyên nhân có thể gặp gồm truy cập bộ nhớ không hợp lệ, sử dụng con trỏ sai hoặc lỗi liên quan đến stack.

Khi chương trình đi vào HardFault_Handler, hãy giữ nguyên trạng thái để kiểm tra trước khi reset:

• Dừng CPU và xác nhận vị trí hiện tại: kiểm tra xem chương trình có đang ở trong handler hay không.
• Kiểm tra Call Stack: dùng chuỗi lời gọi hàm để khoanh vùng luồng thực thi; thông tin này có thể không đầy đủ nếu stack bị hỏng.
• Phân tích exception stack frame: tìm PC và LR đã được lưu khi ngoại lệ xảy ra. PC đang hiển thị trong handler không phải PC của chương trình trước lỗi.
• Đọc các thanh ghi lỗi được nhân Cortex-M hỗ trợ: chẳng hạn CFSR và HFSR; chỉ sử dụng địa chỉ trong BFAR hoặc MMFAR khi cờ hợp lệ tương ứng được đặt.

Không phải dòng STM32 nào cũng có cùng bộ thanh ghi chẩn đoán. Ngoài ra, với một số lỗi bus không chính xác, PC được lưu có thể không trỏ đúng lệnh gây lỗi ban đầu. Cần đối chiếu stack frame, mã máy và trạng thái lỗi để xác định nguyên nhân.

Dùng Logic Analyzer kiểm tra UART, I2C và SPI 

Kiểm Soát Firmware Với ST-Link (Giao Diện SWD)

Giao diện SWD (Serial Wire Debug) trên nhân ARM Cortex-M cho phép can thiệp trực tiếp vào CPU chỉ với 4 đường kết nối vật lý cơ bản:

4 tính năng gỡ lỗi then chốt trong IDE (CubeIDE / Keil MDK)

• Hardware Breakpoint: Dừng chương trình tại dòng code bất kỳ để kiểm tra luồng rẽ nhánh mà không làm xáo trộn dữ liệu bộ nhớ.
• Live Watch: Giám sát giá trị biến và cờ hệ thống thay đổi liên tục theo thời gian thực mà không cần dừng CPU.
• Tra cứu SFR (Special Function Registers): Kiểm tra trực tiếp các bit trong thanh ghi ngoại vi (cờ TXE/RXNE của UART, cờ BUSY/BERR của I2C).
• Call Stack: Khi xảy ra HardFault_Handler, mở Call Stack để tra cứu thanh ghi PC (Program Counter) và LR (Link Register), chỉ điểm chính xác dòng lệnh gây lỗi.

=> Xem thêm: So sánh UART, I2C và SPI: Chọn chuẩn nào cho dự án nhúng của bạn?

Bắt Sóng Tín Hiệu Thực Tế Với Logic Analyzer

Debugger giúp xác định luồng code trong vi điều khiển, còn Logic Analyzer giải quyết câu hỏi: Tín hiệu vật lý trên đường dây có đang chạy đúng chuẩn không?

• Protocol Decoder tự động: Phần mềm tự động giải mã chuỗi xung nhịp thành dữ liệu Hex/ASCII kèm cờ START/STOP trực quan.
• Bắt lỗi giao thức tức thì: Phát hiện ngay các khung lỗi như NACK (sai địa chỉ I2C, thiếu trở kéo pull-up) hoặc lỗi Frame Error (lệch baudrate UART do sai cấu hình thạch anh).
• Đo kiểm thời gian (Timing): Kéo thước đo kiểm tra độ rộng xung clock, thời gian setup/hold time của ngoại vi.

Xem thêm: USB 8 Kênh MCU ARM FPGA Phân Tích Logic Debug 24M

Case Study: Xử Lý I2C Bị Treo Bus

Hiện tượng: Vi điều khiển giao tiếp cảm biến I2C hoạt động được vài giây thì đứng yên, code kẹt cứng tại vòng lặp chờ cờ I2C_FLAG_BUSY.

• Bước 1( ST-Link ): Dừng CPU -> Phát hiện cờ BUSY luôn ở mức 1 (Driver bị khóa). 
• Bước 2 ( Logic Analyzer ): Kẹp kênh đo vào SCL & SDA -> Thấy SCL ở mức HIGH nhưng SDA bị kéo ghì xuống LOW. => Nguyên nhân: IC Slave bị ngắt đột ngột khi đang gửi dở bit 0, kẹt trạng thái giữ chân SDA. 
• Bước 3 ( Khắc phục ): Cấu hình chân SCL thành GPIO Output -> Xuất thủ công 9 xung clock để Slave nhả chân SDA -> Khởi tạo lại ngoại vi I2C và tiếp tục chạy bình thường. 

Quy Trình 4 Bước Chẩn Đoán Lỗi Mạch Nhúng: 

Kết luận

Gỡ lỗi bằng printf() không xấu, nó vẫn là một cách tiện lợi cho các bài toán kiểm tra nhanh. Tuy nhiên, sự khác biệt giữa một người mới học và một kỹ sư nhúng dày dạn kinh nghiệm nằm ở khả năng chủ động kiểm soát hệ thống: biết rõ từng xung nhịp chạy trên đường mạch và từng bit cờ lật trong thanh ghi. Việc đầu tư thời gian làm quen với mạch nạp ST-Link và một chiếc Logic Analyzer nhỏ gọn sẽ giúp bạn tiết kiệm hàng chục giờ đồng hồ "mò kim đáy bể" trước những lỗi treo bus hay tràn ngắt bí ẩn.

Trong dự án nhúng của bạn, "vũ khí" gỡ lỗi ưa thích nhất hiện tại là gì, và đâu là ca bắt bệnh "đau đầu" nhất mà bạn từng gặp? Hãy để lại bình luận phía dưới để cùng trao đổi nhé!