از پیام چاپی به مشاهده وضعیت پردازنده
وقتی برنامه یک میکروکنترلر متوقف می‌شود، افزودن پیام سریال همیشه کافی نیست. ممکن است خطا پیش از راه‌اندازی UART رخ دهد، برنامه وارد وقفه نامناسب شود یا حافظه در نقطه‌ای تغییر کند که پیام‌ها آن را پوشش نمی‌دهند. Raspberry Pi Debug Probe برای چنین موقعیت‌هایی یک مسیر مستقیم‌تر به اشکال‌زدایی فراهم می‌کند. این وسیله کوچک، رایانه را به رابط اشکال‌زدایی و رابط سریال برد متصل می‌کند. به کمک آن می‌توان اجرای برنامه را متوقف کرد، وضعیت را دید و فرضیه درباره علت خطا را با شواهد دقیق‌تری سنجید.
معرفی رسمی Raspberry Pi توضیح می‌دهد که دستگاه بر پایه RP2040 ساخته شده و رابط‌های CMSIS-DAP و UART را روی USB ارائه می‌کند. رابط اشکال‌زدایی پیش‌فرض SWD است و سطح ورودی و خروجی اسمی سه و سه دهم ولت دارد. کابل‌ها و قاب همراه برای اتصال ساده به بردهای سازگار طراحی شده‌اند. با وجود نام Raspberry Pi، کاربرد آن صرفاً محدود به یک برد خاص نیست؛ اما سازگاری واقعی به پردازنده هدف، سطح ولتاژ، سیم‌کشی و پشتیبانی نرم‌افزار بستگی دارد. وجود یک کانکتور مشابه به تنهایی تضمین اتصال موفق نیست.
SWD با UART چه تفاوتی دارد؟
UART معمولاً داده‌ای را نشان می‌دهد که خود برنامه تصمیم گرفته ارسال کند. اگر برنامه اجرا نشود یا مسیر ارسال خراب باشد، اطلاعاتی در دسترس نیست. SWD یک رابط اشکال‌زدایی پردازنده است و می‌تواند برای کنترل اجرا و مشاهده وضعیت به کار رود. این دو مسیر مکمل‌اند. خروجی سریال برای دنبال کردن رویدادهای عادی و ثبت طولانی مناسب است؛ اشکال‌زدایی برای بررسی دقیق یک نقطه از برنامه ارزش دارد. استفاده همزمان و آگاهانه از آن‌ها، فاصله میان «می‌دانم برنامه خراب است» و «می‌دانم کجا خراب شده» را کم می‌کند.
با این حال توقف پردازنده خود رفتار سیستم را تغییر می‌دهد. تایمرها، ارتباط با قطعات جانبی و انتظار دستگاه‌های دیگر ممکن است تحت تأثیر قرار گیرند. خطایی که تنها در سرعت واقعی رخ می‌دهد شاید هنگام اجرای گام‌به‌گام ناپدید شود. بنابراین نباید نتیجه گرفت که برنامه بدون خطاست؛ ممکن است روش مشاهده، شرایط وقوع را حذف کرده باشد. در چنین مسئله‌ای بهتر است از ثبت محدود، نقطه توقف هدفمند و مشاهده قبل و بعد رخداد استفاده شود. انتخاب روش اشکال‌زدایی باید به ماهیت خطا وابسته باشد.
اتصال صحیح از روی مستندات
پیش از اتصال، پایه‌های زمین، ساعت و داده SWD را در نقشه برد هدف پیدا کنید. برای UART نیز جهت ارسال و دریافت باید روشن باشد. نام‌گذاری بعضی بردها از دید خود برد است و بعضی کابل‌ها از دید رابط، بنابراین صرف تطبیق دو برچسب مشابه کافی نیست. زمین مشترک برای مرجع سیگنال لازم است. سطح ولتاژ را با مشخصات هدف تطبیق دهید و به مدارهایی با منطق متفاوت بدون تبدیل مناسب متصل نشوید. این مرحله چند دقیقه وقت می‌گیرد، اما بسیاری از خطاهای مبهم اتصال را از ابتدا حذف می‌کند.
تغذیه برد هدف را جداگانه برنامه‌ریزی کنید. رابط اشکال‌زدایی را نباید بدون بررسی راهنمای رسمی، منبع تغذیه دلخواه فرض کرد. اگر برد از USB دیگری تغذیه می‌شود، مسیرهای مشترک زمین و احتمال برگشت جریان باید فهمیده شوند. برای شروع از برد توسعه شناخته‌شده و کابل کوتاه استفاده کنید. سیم‌های بلند و اتصال لق می‌توانند ارتباط را ناپایدار کنند و ظاهر یک مشکل نرم‌افزاری به وجود آورند. پس از اتصال، عکس یا طرح سیم‌کشی را نگه دارید تا هنگام تکرار آزمایش، شرایط دقیق قابل بازسازی باشد.
آماده‌سازی نرم‌افزار میزبان
این پروب با ابزارهایی که CMSIS-DAP را پشتیبانی می‌کنند، از جمله OpenOCD، کار می‌کند. بخش مهم آماده‌سازی، انتخاب تنظیمات درست برای خود پروب و پردازنده هدف است. ابزار میزبان باید بداند چگونه به رابط وصل شود و حافظه و هسته هدف چگونه مدیریت می‌شوند. به همین دلیل یک فایل پیکربندی از برد دیگر را نباید بدون بررسی کپی کرد. راهنمای رسمی و مثال مخصوص همان خانواده پردازنده بهترین نقطه شروع است. ابتدا ارتباط ساده و شناسایی هدف را تأیید کنید؛ سپس محیط توسعه کامل را به آن متصل نمایید.
فایل قابل اشکال‌زدایی باید با برنامه‌ای که واقعاً روی برد اجرا می‌شود تطابق داشته باشد. اگر نمادهای یک ساخت قدیمی در رایانه باز باشند و ساخت جدید روی برد قرار گرفته باشد، شماره خط و مقدار متغیرها گمراه‌کننده می‌شوند. بهتر است خروجی ساخت، شناسه نسخه و تنظیمات کامپایل کنار هم نگهداری شوند. برای شروع، بهینه‌سازی شدید را کاهش دهید تا ارتباط میان کد منبع و اجرای ماشین روشن‌تر باشد. بعداً باید خطا را با تنظیمات نزدیک به نسخه نهایی نیز بررسی کرد، چون تغییر بهینه‌سازی می‌تواند رفتار زمان‌بندی را عوض کند.
یک تمرین قابل تکرار روی برد آموزشی
برنامه‌ای ساده بنویسید که شمارنده‌ای را افزایش دهد و وضعیت یک خروجی را تغییر دهد. هدف نخست، پیدا کردن خطای پیچیده نیست؛ باید مطمئن شوید توقف، ادامه اجرا و مشاهده متغیرها درست کار می‌کند. یک نقطه توقف در بخش اصلی برنامه بگذارید و بررسی کنید که شمارنده با انتظار شما سازگار است. سپس متغیر را در چند مرحله دنبال کنید. این تمرین کوچک، زنجیره ابزار از فایل ساخت تا اتصال فیزیکی را می‌آزماید و قبل از ورود به پروژه بزرگ، مشکلات محیط را آشکار می‌کند.
در مرحله دوم، یک خطای منطقی بی‌خطر و معلوم اضافه کنید؛ مثلاً شرطی که زودتر از انتظار برقرار می‌شود. پیش‌بینی کنید برنامه کجا باید متوقف شود و سپس مشاهده را با پیش‌بینی مقایسه کنید. اگر مقدار دیده‌شده متفاوت است، مسیر تغییر متغیر را دنبال کنید. خروجی تمرین باید یک توضیح روشن از علت باشد، نه فقط این جمله که «با پروب درست شد». ابزار زمانی ارزش آموزشی دارد که کاربر یاد بگیرد چگونه از وضعیت داخلی به استدلال درباره رفتار برنامه برسد.
نقطه توقف، دیده‌بان و محدودیت منابع
نقطه توقف اجازه می‌دهد اجرا در محل مشخص متوقف شود. دیده‌بان حافظه یا Watchpoint، در صورت پشتیبانی هدف و ابزار، برای بررسی تغییر یک ناحیه مفید است. تعداد و نوع این منابع به پردازنده و سازوکار اشکال‌زدایی وابسته‌اند؛ نباید فرض کرد هر تعداد شرط دلخواه بدون هزینه در دسترس است. بهتر است نخست محتمل‌ترین محل خطا انتخاب شود و دامنه بررسی تدریجی گسترش یابد. افزودن همزمان تعداد زیادی نقطه توقف، هم مدیریت جلسه را دشوار می‌کند و هم ممکن است رفتار زمانی را بیش از حد تغییر دهد.
در برنامه‌های دارای وقفه، محل توقف باید با دقت انتخاب شود. ممکن است مقدار متغیری در حلقه اصلی درست باشد اما بلافاصله در وقفه تغییر کند. همچنین داده‌ای که میان چند بخش مشترک است به قواعد همزمانی نیاز دارد. پروب می‌تواند وضعیت را نشان دهد، اما خود به خود خطای طراحی همزمانی را حل نمی‌کند. یک گزارش خوب توضیح می‌دهد کدام بخش مقدار را نوشته، کدام بخش آن را خوانده و ترتیب مورد انتظار چه بوده است. این توصیف برای اصلاح کد از یک تصویر منفرد از پنجره متغیرها مفیدتر است.
UART به عنوان مسیر مکمل
خروجی سریال برای ثبت رویدادهایی که در زمان واقعی رخ می‌دهند مناسب است. پیام‌ها را کوتاه و دارای معنای مشخص انتخاب کنید؛ مثلاً شروع نمونه‌برداری، پایان انتقال یا ورود به حالت خواب. چاپ تمام متغیرها در هر چرخه می‌تواند برنامه را کند کند و خطای زمانی را پنهان سازد. بهتر است ابتدا چند نشانگر محدود داشته باشید و فقط در صورت نیاز اطلاعات بیشتری اضافه کنید. سرعت رابط و تنظیمات نرم‌افزار ترمینال باید با برنامه هماهنگ باشند، وگرنه خروجی نامفهوم ممکن است با خرابی برنامه اشتباه گرفته شود.
وقتی از SWD و UART همزمان استفاده می‌کنید، بدانید توقف هسته چگونه بر ارسال سریال اثر می‌گذارد. پیام نیمه‌تمام یا فاصله زمانی بلند پس از توقف الزاماً ایراد رابط نیست. زمان رویدادهای ثبت‌شده را با عملیات دستی خود مقایسه کنید. برای نتیجه قابل اعتماد، یک اجرای آزاد بدون توقف نیز داشته باشید. این مقایسه کمک می‌کند اثر مشاهده از رفتار واقعی جدا شود. در پروژه تیمی، ثبت چنین جزئیاتی باعث می‌شود همکار دیگر همان اختلاف ظاهری را دوباره به عنوان ایراد تازه گزارش نکند.
نگهداری Firmware خود پروب
نرم‌افزار داخلی پروب نیز بخشی از زنجیره توسعه است. مخزن رسمی debugprobe منبع بررسی انتشارها و تغییرات است. به‌روزرسانی می‌تواند سازگاری یا رفتار را تغییر دهد، پس نسخه پیشین و جدید را در یادداشت آزمایش ثبت کنید. به‌روزرسانی را درست در میانه بررسی یک ایراد حساس انجام ندهید، مگر اینکه دلیل مشخصی داشته باشید. ابتدا نتیجه موجود را ذخیره کنید و سپس پس از تغییر، همان آزمون پایه را تکرار نمایید. این کار مانع می‌شود اثر تغییر ابزار با اثر تغییر محصول مخلوط شود.
اگر پروب شناسایی نشد، از ساده‌ترین بخش‌ها آغاز کنید: کابل داده، درگاه رایانه، مجوز دسترسی سیستم‌عامل و حضور دستگاه در فهرست USB. بعد به نرم‌افزار و تنظیمات هدف برسید. تغییر همزمان کابل، نسخه برنامه و سیم‌کشی شاید مشکل را موقتاً رفع کند، اما علت را نامعلوم می‌گذارد. یک مسیر مرحله‌ای با ثبت هر تغییر، برای آزمایشگاه آموزشی و حرفه‌ای یکسان مفید است. هدف فقط رسیدن به اتصال نیست؛ باید بدانید چه ترکیبی پایدار است و چگونه می‌توان آن را دوباره ساخت.
مرز کاربرد در توسعه و امنیت محصول
این وسیله برای توسعه و بررسی بردهای تحت اختیار مناسب است. وجود رابط اشکال‌زدایی در یک محصول نهایی نیز موضوعی مستقل برای طراحی امنیت است: سازنده باید تصمیم بگیرد در تولید چه دسترسی‌هایی فعال بمانند و بازیابی چگونه انجام شود. پروب ابزار دور زدن خودکار حفاظت نیست و نباید چنین انتظاری از آن داشت. برای آزمون سیاست اشکال‌زدایی محصول خود، ابتدا مستندات پردازنده و فرایند تولید را بررسی کنید و حالت‌های توسعه، تولید و تعمیر را جدا تعریف نمایید. تصمیم درباره قفل‌های دائمی باید با شناخت کامل پیامدهای بازیابی گرفته شود.
Raspberry Pi Debug Probe انتخاب مناسبی برای یادگیری SWD و ساخت یک محیط توسعه ساده است، به‌ویژه وقتی بردهای هدف با سطح و رابط آن سازگارند. برای نیازهای پیچیده‌تر مانند Trace تخصصی، سرعت بالاتر یا خانواده‌های خاص پردازنده، باید گزینه‌های دیگر را با همان هدف واقعی مقایسه کرد. معیار انتخاب، تعداد لوگوهای سازگار در معرفی محصول نیست؛ توانایی اجرای یک جلسه پایدار، مشاهده خطای واقعی و بازتولید نتیجه است. اگر این سه شرط فراهم باشد، یک پروب کوچک می‌تواند زمان زیادی از چرخه آزمون و خطای توسعه را کم کند.
