دیدن مسیر اجرا پیش از خرابی
J-Trace PRO Cortex از SEGGER یک پروب عیب‌یابی و ردیابی اجرا برای اهداف سازگار Arm Cortex است. تفاوت مهم آن با مشاهده معمول متغیرها این است که می‌تواند اطلاعات مسیر اجرای پردازنده را دریافت کند و برای بررسی آنچه پیش از خرابی رخ داده در اختیار ابزار تحلیل بگذارد. وقتی یک خطا تنها پس از مدتی طولانی اتفاق می‌افتد، قرار دادن نقطه توقف در محل حدس‌زده‌شده همیشه کافی نیست. ردیابی می‌تواند زمینه رخداد را نشان دهد، به شرط آنکه تراشه، برد، اتصال و نرم‌افزار همگی مسیر لازم را پشتیبانی کنند.
مدلی که این راهنما درباره آن صحبت می‌کند نسخه Cortex است. نام J-Trace PRO روی خانواده‌ای از محصولات دیده می‌شود و قابلیت یک نسخه نباید به نسخه دیگر تعمیم داده شود. صفحه رسمی این مدل به پشتیبانی از اهداف Cortex-A، Cortex-R و Cortex-M اشاره می‌کند، اما این عبارت به معنای سازگاری همه تراشه‌ها و همه بردهای ساخته‌شده با این هسته‌ها نیست. قبل از انتخاب، شماره دقیق تراشه، امکانات ردیابی آن، پایه‌های در دسترس و پشتیبانی نرم‌افزاری بررسی می‌شود. داشتن یک کانکتور دیباگ به تنهایی برای ردیابی دستورها کافی نیست.
تفاوت توقف، گزارش و ردیابی
در دیباگ معمول، پردازنده متوقف می‌شود و وضعیت فعلی آن را می‌بینید. در ثبت پیام، برنامه خودش اطلاعاتی را در مسیر خروجی می‌نویسد. ردیابی سخت‌افزاری مسیر دیگری دارد: بخش ویژه‌ای از هدف اطلاعات مرتبط با اجرا را تولید می‌کند و پروب آن را دریافت می‌کند. این روش می‌تواند برای تحلیل رخدادی مفید باشد که توقف اجرای برنامه رفتار آن را تغییر می‌دهد. با این حال عبارت ردیابی نباید به معنی مشاهده تمام داده‌های داخلی در هر لحظه تعبیر شود. نوع اطلاعات وابسته به قابلیت هدف و پیکربندی فعال است.
پیام‌های کاربردی همچنان مفید هستند، زیرا معنای تجاری یا منطقی یک رخداد را بهتر از آدرس دستور توضیح می‌دهند. در مقابل، مسیر دستور می‌تواند مشخص کند برنامه چگونه به یک وضعیت غیرمنتظره رسیده است. این دو شاهد مکمل یکدیگرند. مثلاً گزارش برنامه می‌گوید یک درخواست رد شده، اما ردیابی می‌تواند نشان دهد کدام شاخه شرطی و کدام مسیر بازگشت به آن تصمیم منتهی شده است. انتخاب ابزار باید از پرسش آغاز شود: دنبال محل خرابی هستید، مدت اجرای تابع را می‌خواهید یا می‌خواهید بدانید کدام بخش واقعاً اجرا شده است؟
پیش‌نیاز تراشه و طراحی برد
برای ردیابی خارجی، وجود قابلیت مناسب در تراشه و دسترسی فیزیکی به خطوط مرتبط ضروری است. برخی بردهای توسعه فقط پایه‌های SWD را بیرون آورده‌اند؛ این اتصال ممکن است برای برنامه‌ریزی و دیباگ کافی باشد، اما خطوط لازم برای ردیابی موازی را ارائه نکند. پیش از خرید یا اتصال پروب، شماتیک برد را بررسی کنید. مسیرهای مربوط به ساعت و داده ردیابی، نوع کانکتور و امکان استفاده همزمان با وسایل جانبی باید مشخص باشند. تغییر پیکربندی پایه‌ها در نرم‌افزار نیز ممکن است بر دسترسی به این مسیر اثر بگذارد.
پروب جای طراحی صحیح مسیر سیگنال را نمی‌گیرد. کابل بلند، انشعاب اضافی و زمین نامناسب می‌توانند در سرعت بالا کیفیت ارتباط را کاهش دهند. یک اتصال که در دیباگ کم‌سرعت کار می‌کند لزوماً برای ردیابی پرسرعت مناسب نیست. از کابل و رابط توصیه‌شده استفاده کنید و شماره پایه را از نمای درست کانکتور بخوانید. اگر برای برد اختصاصی کانکتور طراحی می‌کنید، این موضوع را در مرحله طراحی در نظر بگیرید؛ افزودن سیم‌های بلند پس از ساخت برد ممکن است فقط یک آزمایش محدود را ممکن کند.
شروع با مرجع شناخته‌شده
بسته رسمی محصول یک برد مرجع ردیابی Cortex-M را معرفی می‌کند. ارزش چنین مرجعی در جدا کردن مشکل میزبان و پروب از مشکل برد اختصاصی است. ابتدا با پروژه و اتصال شناخته‌شده، دریافت ردیابی را آزمایش کنید. اگر این مسیر کار می‌کند ولی برد شما نه، دامنه بررسی به هدف، تنظیمات و کیفیت اتصال محدودتر می‌شود. این نتیجه هنوز ثابت نمی‌کند پروب در هر شرایطی سالم است، اما شاهد عملی بسیار بهتری از صرف روشن شدن چراغ یا شناسایی USB فراهم می‌کند.
برای آزمایش نخست یک برنامه کوچک با چند مسیر روشن مناسب است. یک حلقه ساده، یک تابع دوره‌ای و یک شاخه وابسته به ورودی می‌توانند نشان دهند که ابزار کد درست را نمایش می‌دهد. هدف از این مرحله اندازه‌گیری عملکرد محصول نهایی نیست. می‌خواهید مطمئن شوید فایل اجرایی، نمادها، آدرس‌ها و مسیر دریافت با یکدیگر هماهنگ هستند. پس از آن می‌توان همان تنظیمات پایه را به پروژه اصلی منتقل کرد و هر تفاوت مربوط به ساعت، حافظه یا راه‌اندازی را جداگانه بررسی کرد.
میزبان و مسیر انتقال
سازنده برای این مدل رابط USB پرسرعت و جریان پیوسته ردیابی را معرفی می‌کند. مفهوم عملی جریان پیوسته این است که داده فقط به ظرفیت محدود یک بافر داخلی متکی نباشد و بتوان آن را برای تحلیل طولانی‌تر به میزبان منتقل کرد. با این حال واژه نامحدود در معرفی محصول به معنی حافظه یا ذخیره‌سازی بی‌نهایت روی رایانه نیست. ظرفیت دیسک، سرعت انتقال، بار میزبان و تنظیمات ابزار همچنان در اجرای واقعی اهمیت دارند. برای ثبت طولانی باید فضای کافی و رفتار سامانه در طول زمان بررسی شود.
میزبان آزمایش را تا حد امکان پایدار نگه دارید. قطع خودکار برق USB، خواب سیستم، اتصال واسطه نامناسب یا برنامه‌ای که دیسک را سنگین درگیر می‌کند می‌تواند ثبت طولانی را مختل کند. یک اجرای کوتاه موفق تضمین نمی‌کند جلسه چندساعته همان نتیجه را داشته باشد. پیش از شکار خطای نادر، یک ثبت طولانی آزمایشی انجام دهید و کیفیت داده و وضعیت خطاهای ابزار را بررسی کنید. این کار از اتلاف فرصتی جلوگیری می‌کند که ممکن است فقط یک بار در شبانه‌روز رخ دهد.
فایل اجرایی دقیق و نمادها
برای تفسیر ردیابی، نرم‌افزار باید بداند کد واقعی در چه آدرسی قرار دارد. فایل اجرایی و نمادها باید با همان نسخه‌ای که روی هدف اجرا می‌شود منطبق باشند. تفاوت کوچک در گزینه‌های کامپایل یا پیوند می‌تواند نگاشت آدرس‌ها را تغییر دهد. بنابراین نام فایل کافی نیست؛ شناسه ساخت و ترجیحاً اثرانگشت فایل را همراه ثبت نگه دارید. اگر بوت‌لودر یا چند تصویر اجرایی در سامانه وجود دارد، محدوده‌های آنها نیز باید در تحلیل لحاظ شود تا مسیر اجرا به بخش نادرست نسبت داده نشود.
بهینه‌سازی کامپایلر باعث می‌شود ارتباط خط منبع و دستور ماشین همیشه یک به یک نباشد. درون‌گذاری تابع، حذف کد مرده و جابه‌جایی دستورها ممکن است مشاهده را برای خواننده ناآشنا عجیب کند. در تحلیل، نمای دستور و نمای منبع را کنار هم به کار ببرید. نتیجه‌ای مانند «این خط هرگز اجرا نشده» باید با ساخت مورد استفاده تفسیر شود. برای اشکال‌زدایی می‌توان ساخت ساده‌تری داشت، اما بررسی نهایی رفتار یا عملکرد باید روی نسخه‌ای انجام شود که به شرایط محصول نزدیک است.
مثال عملی: خطایی که دیر رخ می‌دهد
فرض کنید کنترلری پس از چند ساعت دریافت داده وارد وضعیت خطا می‌شود. ابتدا زمان تقریبی رخداد، ورودی‌ها و نشانه قابل مشاهده را تعریف کنید. ثبت را به یک پرسش محدود کنید: پیش از ورود به تابع خطا، کدام مسیرهای برنامه اجرا شده‌اند؟ سپس از قابلیت‌های ثبت و تحلیل محیط سازگار، مانند Ozone، برای یافتن توالی مربوط استفاده کنید. اگر تنها آخرین وضعیت پردازنده را ببینید، ممکن است اثر خرابی را با علت اشتباه بگیرید. مسیر پیشین می‌تواند محل تغییر تصمیم یا ورود غیرمنتظره به شاخه‌ای کم‌استفاده را آشکار کند.
بعد از یافتن مسیر مشکوک، یک ورودی کوچک‌تر بسازید که همان وضعیت را تکرار کند. ردیابی به تنهایی جای بازتولید خطا را نمی‌گیرد. اگر مشکل با یک طول بسته خاص رخ می‌دهد، همان مرز را در یک آزمون محدود بررسی کنید. اصلاح باید بر علت مبتنی باشد و با اجرای دوباره همان سناریو تأیید شود. همچنین وضعیت حذف داده یا قطع ثبت را بررسی کنید؛ فاصله خالی در شاهد ممکن است ناشی از دریافت ناقص باشد و نباید خودکار به عنوان پرش عجیب پردازنده تفسیر شود.
پروفایل اجرا و نقاط پرمصرف
یکی از کاربردهای معرفی‌شده برای J-Trace PRO، تحلیل اجرای برنامه و یافتن بخش‌های پرتکرار است. چنین تحلیلی می‌تواند نشان دهد وقت پردازنده در کدام مسیرها صرف می‌شود و به انتخاب محل بهینه‌سازی کمک کند. اما درصد زمان یک تابع بدون شناخت بار آزمایش معنای محدودی دارد. برنامه‌ای که در حالت بیکار بیشتر وقتش را در انتظار می‌گذراند با برنامه تحت بار کامل یکسان نیست. پیش از مقایسه، ورودی، فرکانس، گزینه‌های ساخت و فعالیت وقفه‌ها را ثابت و ثبت کنید.
همچنین زمان کل یک تابع را از زمان صرف‌شده در زیرتابع‌هایش جدا کنید. اگر یک تابع منتظر ورودی بیرونی است، تغییر چند دستور محاسباتی شاید هیچ اثر محسوسی بر تأخیر کاربر نگذارد. اگر وقفه‌ها زیاد هستند، نسبت دادن همه زمان به مسیر اصلی گمراه‌کننده خواهد بود. ابتدا پرسش عملکردی را روشن کنید، سپس داده مناسب را بخوانید و پس از تغییر دوباره اندازه بگیرید. نتیجه مفید عددی است که با سناریوی واقعی و یک مقایسه کنترل‌شده همراه باشد، نه صرفاً نموداری با رنگ‌های متنوع.
پوشش اجرا چه چیزی ثابت می‌کند؟
پوشش کد از امکاناتی است که سازنده برای این پروب مطرح می‌کند. مشاهده اینکه یک بخش اجرا شده برای یافتن قسمت‌های آزمایش‌نشده ارزشمند است، ولی اجرا شدن به معنی درست بودن نتیجه نیست. تابعی ممکن است یک بار اجرا شود و همچنان در ورودی مرزی خطا داشته باشد. پوشش دستور نیز الزاماً معادل همه انواع پوشش تصمیم یا شرط مورد نیاز در یک فرایند رسمی نیست. معیار دقیق پروژه باید جداگانه تعریف شود و خروجی ابزار با همان معیار سنجیده شود.
برای استفاده عملی، ابتدا مجموعه سناریوهای مورد انتظار را مشخص کنید: آغاز عادی، ورودی نامعتبر، خطای ارتباط و بازیابی. سپس ببینید کدام مسیرها در هیچ سناریویی مشاهده نشده‌اند. این یافته می‌تواند به نوشتن آزمون تازه یا حذف کد غیرقابل دسترس منجر شود. در گزارش، نسخه برنامه، دامنه ثبت و محدودیت مشاهده را بیاورید. از تبدیل یک درصد پوشش به ادعای کلی درباره ایمنی یا نبود خطا خودداری کنید. پوشش شاهدی درباره فعالیت کد در آزمایش مشخص است و باید کنار نتیجه آزمون و بازبینی طراحی خوانده شود.
عیب‌یابی دریافت نامطمئن
اگر دیباگ کار می‌کند اما ردیابی داده قابل تفسیر نمی‌دهد، مسیرها را جدا بررسی کنید. پیکربندی قابلیت ردیابی هدف، انتخاب پایه‌ها، ساعت مرتبط، کابل و فایل اجرایی از نقاط شروع هستند. کاهش سرعت در چارچوب راهنمای هدف می‌تواند به تشخیص مسئله کیفیت سیگنال کمک کند. اگر در سرعت پایین نتیجه پایدار شد، علت را در طراحی و اتصال بررسی کنید؛ صرف پایین آوردن سرعت ممکن است برای نیاز نهایی کافی نباشد. اطلاعات خطای خود نرم‌افزار را نگه دارید تا نتیجه به حدس بصری وابسته نماند.
تغییر چند تنظیم همزمان معمولاً تشخیص را سخت‌تر می‌کند. یک پیکربندی پایه موفق نگه دارید و هر تغییر را با نام و نتیجه ثبت کنید. اگر ابزار نسخه تازه‌ای دارد، پیش از جایگزینی در یک پروژه حساس، یک آزمایش مرجع انجام دهید. خطایی که پس از ارتقا دیده می‌شود ممکن است از تنظیمات مهاجرت‌کرده یا فایل هدف متفاوت باشد. داشتن نمونه ثبت سالم و پروژه کوچک مرجع، مقایسه را سریع‌تر می‌کند و گزارش به پشتیبانی سازنده را نیز دقیق‌تر خواهد کرد.
نگهداری نتیجه و انتخاب ابزار
فایل ردیابی می‌تواند جزئیات ساختار برنامه و رفتار سامانه را آشکار کند. آن را همراه فایل اجرایی منطبق، تنظیمات جلسه و شرح ورودی آزمایش نگه دارید تا بعداً قابل تفسیر باشد. یک فایل حجیم بدون زمینه ممکن است برای همکار دیگر تقریباً بی‌استفاده شود. برای گزارش خطا، بازه مهم و مراحل بازتولید را مشخص کنید، اما اصل داده را نیز تا پایان بررسی حفظ کنید. اگر اشتراک بیرونی لازم است، محتوای برنامه و داده‌های احتمالی را از نظر محرمانگی بررسی کنید.
J-Trace PRO Cortex برای مسئله‌ای ارزش دارد که دیدن تاریخچه اجرای کد، پروفایل یا پوشش سخت‌افزاری در آن اهمیت دارد و هدف نیز زیرساخت لازم را فراهم می‌کند. اگر نیاز صرفاً برنامه‌ریزی و چند نقطه توقف باشد، ظرفیت ردیابی ممکن است استفاده نشود. تصمیم درست از بررسی قابلیت هدف و یک نمونه آزمایش واقعی می‌آید. اتصال سالم، فایل اجرایی دقیق و پرسش تحلیلی روشن، سه پایه‌ای هستند که اطلاعات خام را به شاهد قابل استفاده برای اصلاح نرم‌افزار تبدیل می‌کنند.
