Logic Analyzer برای چه کاری است؟
Saleae Logic 8 سیگنال‌های دیجیتال و آنالوگ سطح برد را Capture می‌کند تا رفتار واقعی Firmware و Busها را ببینید. هشت کانال، Decode پروتکل‌ها و جست‌وجوی Capture در Logic 2 برای Debug Embedded بسیار مفید است.
مشخصات مهم
حداکثر 100MS/s برای دیجیتال، 10MS/s برای آنالوگ و هشت ورودی چندمنظوره دارد. برای SPI، I2C، UART و ده‌ها Decoder دیگر مناسب است.
جایگاه کنار Oscilloscope
Logic Analyzer زمان‌بندی و محتوای دیجیتال را عالی نشان می‌دهد، اما برای کیفیت شکل موج، Noise و اندازه‌گیری دقیق آنالوگ همچنان Oscilloscope ابزار مکمل است.
داده دیجیتال با شکل موج آنالوگ فرق دارد
Logic analyzer در تحلیل دیجیتال به ما می‌گوید در زمان‌های نمونه‌برداری، سیگنال در کدام سطح منطقی دیده شده است. این تصویر برای ترتیب بیت‌ها و ارتباط چند خط بسیار مفید است، اما جزئیات کامل لبه، overshoot یا نویز گذرا را تضمین نمی‌کند. یک خط ممکن است در نمایش دیجیتال تمیز دیده شود ولی حاشیه الکتریکی کمی داشته باشد. برای چنین مسئله‌ای اندازه‌گیری آنالوگ مناسب و در بسیاری موارد اسیلوسکوپ لازم است. ابزار را بر اساس سؤال انتخاب کنید، نه فقط تعداد کانال.
در نمونه آموزشی، می‌خواهید بدانید چرا حسگر گاهی پاسخ نمی‌دهد. اگر مشکل از نشانی اشتباه در پیام باشد، decode دیجیتال سرنخ خوبی می‌دهد. اگر مشکل از بالا رفتن کند خط یا تغذیه نامناسب باشد، مشاهده محتوای پیام کافی نیست. ابتدا فرضیه را مشخص کنید و سپس ثبت دیجیتال و آنالوگ را متناسب تنظیم کنید. ترکیب این دو دید کمک می‌کند خطای firmware از مشکل الکتریکی جدا شود.
پیش از اتصال، سطح ولتاژ را بشناسید
نام UART یا SPI سطح ولتاژ را تعیین نمی‌کند. پیش از وصل کردن پروب، شماتیک، مرجع زمین و محدوده ورودی مدل دقیق دستگاه را بخوانید. تحمل حفاظتی، محدوده اندازه‌گیری آنالوگ و آستانه منطقی سه مشخصه متفاوت‌اند. وجود حفاظت ورودی به معنی مناسب بودن آن ورودی برای هر اندازه‌گیری نیست. مدل Logic 8 را نیز با مدل‌های Pro که مشخصات دیگری دارند اشتباه نگیرید؛ جدول سازنده باید برای همان سخت‌افزار شما بررسی شود.
زمین مشترک برای اندازه‌گیری تک‌سر اهمیت دارد، اما اتصال زمین در سامانه‌های دارای پتانسیل متفاوت می‌تواند مسئله ایجاد کند. برای مدار متصل به برق شهر یا بخش‌های بدون جداسازی، پروب را مانند ابزار عمومی بی‌خطر وصل نکنید و از روش و تجهیز مناسب همان اندازه‌گیری استفاده کنید. در آزمایشگاه آموزشی، یک برد کم‌ولتاژ و تغذیه‌شده از منبع شناخته‌شده انتخاب کنید. این انتخاب هم ریسک را کم می‌کند و هم تفسیر سیگنال را ساده‌تر می‌سازد.
کانال‌ها را با معنای سیگنال نام‌گذاری کنید
پیش از capture، جدول اتصال بسازید: شماره کانال، نام پایه روی برد، نقش سیگنال و سطح ولتاژ. نام‌هایی مثل clock و data از شماره‌های خام مفیدترند، اما جهت را نیز روشن کنید. در SPI، MOSI و MISO از دید controller تعریف می‌شوند و اشتباه در این دید می‌تواند تفسیر را معکوس کند. عکس اتصال‌ها و نام کانال‌ها را همراه فایل capture نگه دارید تا تحلیل بعدی به حافظه فرد متکی نباشد.
طول سیم و محل اتصال نیز روی مشاهده اثر دارند. سیم‌های بلند و زمین نامناسب می‌توانند نویز یا اثرگذاری روی مدار ایجاد کنند. اگر اتصال پروب رفتار مدار را عوض می‌کند، این موضوع خود یک شاهد است و باید ثبت شود. تلاش کنید setup کوچک و تکرارپذیر باشد و تغییر سیم‌کشی را یک متغیر آزمایش بدانید. ضبط بدون مستند کردن اتصال‌ها ممکن است برای همکار بعدی ارزش کمی داشته باشد.
نرخ نمونه‌برداری را از نیاز زمانی انتخاب کنید
حداکثر نرخ درج‌شده روی محصول، تضمین decode هر سیگنال با همان فرکانس نیست. باید چند نمونه کافی برای تشخیص لبه‌ها و فاصله‌های زمانی وجود داشته باشد و محدودیت دستگاه و نرم‌افزار رعایت شود. تعداد کانال‌های فعال، حالت آنالوگ یا دیجیتال و شرایط انتقال نیز می‌توانند بر تنظیمات قابل استفاده اثر بگذارند. به جای انتخاب خودکار بیشترین عدد، ابتدا سرعت باس و کوتاه‌ترین رخداد مهم را مشخص کنید.
برای بررسی کافی بودن نرخ، یک capture مرجع بگیرید و سپس با نرخ متفاوت همان رویداد را تکرار کنید. اگر تفسیر بیت یا زمان‌بندی عوض می‌شود، احتمالاً تنظیم اولیه یا کیفیت سیگنال نیاز به بررسی دارد. این مقایسه جای محاسبه مشخصات را نمی‌گیرد، ولی خطای آشکار را نشان می‌دهد. در گزارش، نرخ مؤثر و کانال‌های فعال را ثبت کنید. عبارت «با Logic گرفته شد» برای بازتولید یک اندازه‌گیری زمانی کافی نیست.
Trigger و ثبت لحظه مسئله
ثبت طولانی همه فعالیت‌ها همیشه بهترین راه یافتن خطا نیست. اگر می‌دانید رخداد با لبه یک پایه یا شروع یک تراکنش همراه است، trigger را به همان نشانه مرتبط کنید. مقداری داده پیش از رخداد نیز می‌تواند علت را نشان دهد. فقط بخش پس از شکست ممکن است نتیجه را ثبت کند و مرحله ایجاد مشکل را از دست بدهد. طراحی trigger باید از فرضیه عیب‌یابی بیاید و با قابلیت نرم‌افزار نصب‌شده هماهنگ باشد.
در یک تمرین، firmware هنگام شروع عملیات یک GPIO آزمایشی را تغییر دهد. این خط می‌تواند زمان log نرم‌افزاری را به سیگنال واقعی باس وصل کند. سپس فاصله میان آغاز عملیات، نخستین بیت و پاسخ حسگر را بسنجید. پس از پایان، تغییر آزمایشی firmware را مستند و حذف یا کنترل کنید. چنین نشانه‌ای برای جدا کردن تأخیر برنامه از تأخیر خود ارتباط بسیار مفید است.
تحلیل I2C با چند سؤال مشخص
در I2C، ابتدا خط‌های SDA و SCL را درست شناسایی کنید و شروع و پایان تبادل را ببینید. سپس نشانی، جهت و پاسخ ACK یا NACK را بررسی کنید. نمایش نشانی در ابزارهای مختلف ممکن است با قرارداد متفاوتی همراه باشد؛ پیش از مقایسه با دیتاشیت، بدانید نرم‌افزار چه قالبی نشان می‌دهد. یک اختلاف ظاهری عددی همیشه نشانی اشتباه firmware نیست. تنظیم decoder و معنای بیت جهت را کنار مستند حسگر بخوانید.
اگر NACK دیده می‌شود، تنها کد برنامه را تغییر ندهید. تغذیه حسگر، زمان آماده‌شدن، نشانی انتخاب‌شده با پایه‌های سخت‌افزاری و شرایط pull-up نیز مطرح‌اند. یک تراکنش سالم و یک تراکنش ناموفق را در شرایط مشابه مقایسه کنید. اگر clock متوقف یا کشیده می‌شود، زمان‌بندی را با قرارداد دستگاه بررسی کنید. decode باید به شکل موج و زمینه فیزیکی متصل بماند؛ خروجی متنی به تنهایی همه علت‌ها را نشان نمی‌دهد.
تحلیل SPI و تنظیم mode
SPI به توافق درباره قطبیت و فاز clock، ترتیب بیت و انتخاب دستگاه وابسته است. تنظیم اشتباه decoder می‌تواند بایت‌هایی بسازد که ظاهراً منظم‌اند ولی معنای درست ندارند. ابتدا دیتاشیت مقصد و تنظیم firmware را بخوانید، سپس لبه نمونه‌برداری را روی capture بررسی کنید. خط انتخاب دستگاه نیز برای مرزبندی تراکنش اهمیت دارد و حذف آن از ثبت می‌تواند تحلیل را مبهم کند.
برای تمرین، یک فرمان خواندن شناسه یا رجیستر بی‌خطر روی قطعه آزمایشگاهی اجرا کنید. مقدار مورد انتظار از دیتاشیت و تعداد بیت‌ها را پیشاپیش بنویسید. اگر پاسخ جابه‌جا یا وارونه دیده می‌شود، ترتیب بیت و mode را بررسی کنید. اگر خط پاسخ ثابت است، اتصال، فعال بودن دستگاه و جهت سیم را بسنجید. از اجرای فرمان‌های نویسنده روی حافظه یا تنظیمات حساس برای نخستین آزمون پرهیز کنید؛ خواندن شناخته‌شده مرجع بهتری می‌سازد.
تحلیل UART و خطاهای قالب
برای UART، baud rate، تعداد بیت داده، parity و stop bit باید با دو طرف ارتباط هماهنگ باشند. یک متن ناخوانا ممکن است از تنظیم decoder باشد، نه از محتوای خراب فرستنده. ابتدا الگوی ساده و تکرارپذیر از برد آزمایشی بفرستید و طول بیت را روی capture بررسی کنید. سپس تنظیمات را با firmware تطبیق دهید. سطح الکتریکی و وارونگی احتمالی را نیز جدا از قالب داده در نظر بگیرید.
اگر فقط آغاز پیام خراب است، زمان راه‌اندازی یا انتخاب trigger می‌تواند بخشی از علت باشد. اگر خطا با افزایش طول پیام بیشتر می‌شود، اختلاف زمان‌بندی و شرایط دریافت را بررسی کنید. ثبت هم‌زمان یک GPIO وضعیت یا خط جهت در ارتباط نیمه‌دوطرفه می‌تواند سرنخ بدهد. نتیجه را با چند پیام و چند تکرار تأیید کنید تا یک capture تصادفی مبنای تغییر طراحی نشود.
فایل capture به عنوان شاهد مهندسی
فایل خام را همراه تنظیمات decoder، نسخه firmware و چیدمان اتصال ذخیره کنید. تصویر صفحه برای توضیح یک بخش مفید است ولی امکان تغییر تفسیر یا اندازه‌گیری دوباره را محدود می‌کند. اگر گزارش فقط عکس دارد، همکار ممکن است نتواند فرض mode یا نرخ نمونه‌برداری را بازبینی کند. برش‌های مهم را با زمان و توضیح مشخص کنید تا فایل طولانی قابل استفاده بماند.
در پروژه دارای داده حساس، باس ممکن است کلید، شناسه یا محتوای کاربر حمل کند. پیش از اشتراک capture، داده را بازبینی کنید و برای گزارش عمومی از نمونه ساختگی استفاده کنید. حذف یک برچسب از تصویر لزوماً داده خام داخل فایل را حذف نمی‌کند. روش اشتراک باید با حساسیت کل فایل هماهنگ باشد. برای بازتولید خطا اغلب می‌توان ورودی آزمایشی ساخت که همان رفتار فنی را بدون اطلاعات واقعی نشان دهد.
از مشاهده به اصلاح firmware
پس از یافتن اختلاف، یک تغییر کوچک انجام دهید و همان آزمایش را دوباره اجرا کنید. اگر چند تنظیم clock، timeout و ترتیب فرمان را هم‌زمان تغییر دهید، معلوم نمی‌شود کدام‌یک علت را برطرف کرده است. علاوه بر نمونه خطادار، یک نمونه سالم قبلی را نیز بررسی کنید تا اصلاح باعث regression نشود. معیار پایان باید رفتار درست روی باس و نتیجه درست برنامه باشد، نه صرفاً ناپدید شدن یک خطای decoder.
برای خطاهای وابسته به دما، تغذیه یا بار، شرایط محیط را ثبت کنید و نتیجه را محدود به همان شرایط بدانید. ابزار ثبت به شما شواهد می‌دهد، اما کیفیت استنتاج به طراحی آزمایش وابسته است. یک گزارش خوب توضیح می‌دهد انتظار چه بود، چه چیزی روی سیم دیده شد، کدام فرض رد شد و تغییر چگونه تأیید شد. این روش Logic 8 را از وسیله نمایش موج به بخشی از فرایند عیب‌یابی قابل انتقال در تیم تبدیل می‌کند.
