دیباگ Cortex-M از راه CAN؛ بی‌نیاز از SWD/JTAG

به گفته hackster

Erich Styger، مهندس امبدد و استاد، به‌همراه دانشجویش Simon Kathriner روشی عملی برای دیباگ سخت‌افزاری میکروکنترلرهای Arm Cortex‑M بدون نیاز به رابط‌های سنتی SWD/JTAG ارائه کرده‌اند. ایده‌ی اصلی، استفاده از گذرگاه Controller Area Network (CAN) برای جابه‌جایی فرامین دیباگ و تکیه بر قابلیت «کمتر شناخته‌شده» DebugMonitor در خانواده‌ی Cortex‑M است. نتیجه، دیباگی است که در محصول نهایی و بدون دسترسی مستقیم به پین‌های دیباگ هم قابل انجام است.

چرا همیشه SWD/JTAG پاسخ‌گو نیست؟

دیباگ سنتی سخت‌افزار معمولاً به یک پروب دیباگ و کابل SWD/JTAG متکی است. این روش:

• به پین‌های اختصاصی روی هدف و دسترسی فیزیکی نیاز دارد که در محصول نهایی اغلب ممکن نیست.
• هزینه‌ی پروب، کابل و طراحی پین‌ها را تحمیل می‌کند و سیگنال‌های پرسرعت آن مستعد تداخل است.
• در سامانه‌هایی که همه‌ی MCUها از قبل به یک field bus مانند CAN متصل‌اند، یک مسیر جایگزین منطقی و در دسترس وجود دارد.

Styger همین نکته را مبنا قرار داده: وقتی شبکه‌ی CAN در دسترس است، چرا از آن برای دیباگ سخت‌افزاری استفاده نکنیم؟

ایده و قابلیت‌ها: دیباگ از طریق CAN با تکیه بر DebugMonitor

قابلیت DebugMonitor که در بسیاری از مدل‌های Arm Cortex‑M موجود است (به‌جز M0/M0+)، در این راهکار نقش کلیدی دارد. با استفاده از آن و یک چارچوب نرم‌افزاری سبک روی هدف، می‌توان عملیات‌های مرسوم دیباگ را از راه دور و از طریق CAN انجام داد، از جمله:

• برنامه‌ریزی فلش (flash programming)
• توقف کنترلر (halt)
• بازرسی/دستکاری حافظه (memory inspection)
• اجرای قدم‌به‌قدم (instruction stepping)

به بیان Styger، DebugMonitor از «ویژگی‌های کم‌تر ارزیابی‌شده» در اکوسیستم Cortex‑M است و برای ایجاد قلاب‌های دیباگ در زمان اجرا بسیار مناسب است.

زنجیره‌ی کامل به‌صورتی طراحی شده که ابزارهای رایج توسعه تقریباً بدون تغییر باقی بمانند و تنها مسیر انتقال دیباگ از SWD/JTAG به CAN جابه‌جا شود:

۱) Host

• ابزارهای رایج مانند gdb و VS Code روی میزبان استفاده می‌شوند.
• پروتکل دیباگ CMSIS-DAP به‌صورت معمولی از طریق USB تولید می‌شود.

۲) gateway USB↔CAN

• یک gateway اختصاصی پیام‌های CMSIS-DAP را بین USB و CAN ترجمه می‌کند.
• این پل باعث می‌شود هیچ تغییری در gdb یا VS Code لازم نباشد و مسیر حمل فقط از SWD/JTAG به CAN منتقل گردد.

۳) هدف مبتنی بر Arm Cortex‑M

• روی هدف، یک چارچوب (framework) سبک نصب می‌شود که قلاب‌های لازم را به DebugMonitor متصل می‌کند.
• این چارچوب هنگام دیباگ، ارتباط معمول CAN دستگاه را زنده نگه می‌دارد؛ بنابراین رفتار شبکه مختل نمی‌شود.
• این قابلیت روی همه‌ی هسته‌های Cortex‑M به‌جز M0/M0+ قابل استفاده است.

مزایا

• دیباگ در محصول نهایی: هنگامی که دسترسی فیزیکی به پین‌های SWD/JTAG ممکن نیست.
• کاهش هزینه و پیچیدگی: حذف کانکتورهای دیباگ و مسیرهای پرسرعت حساس به تداخل.
• استفاده از زیرساخت موجود: در سامانه‌های چند-کنترلره که از قبل به CAN متصل‌اند.
• حفظ سرویس‌دهی شبکه: چارچوب هدف ارتباط CAN را حین دیباگ قطع نمی‌کند.

معایب

• نیاز به شبکه/رابط CAN در دستگاه‌های هدف.
• نیاز به پشتیبانی DebugMonitor؛ این قابلیت در همه‌ی Cortex‑Mها به‌جز M0/M0+ موجود است.
• حضور یک gateway برای تبدیل CMSIS-DAP بین USB و CAN.

انتشار، پروژه و منابع

چارچوبی که DebugMonitor را به دیباگ روی CAN پیوند می‌دهد، توسط Simon Kathriner (دانشجوی Erich Styger) نوشته شده و در GitLab با مجوز متن‌باز نامشخص منتشر شده است. توضیحات فنی و روند کار در وبلاگ Styger به‌تفصیل آمده است.