אופס, טעות בג'וק: הכירו את ה-Errata

בעבודה עם רכיבים אלקטרוניים, ה-Datasheet הוא ידידו הטוב ביותר של האדם. עם זאת, במיקרו-בקרים ורכיבים מתקדמים אחרים, קיים מסמך נוסף שמפתחים רציניים חייבים להכיר: ה-Errata.

מקרה קיצוני של טעויות בסיליקון: לוח פיתוח שהתמיכה בו הופסקה רשמית
מקרה קיצוני של טעויות בסיליקון: לוח פיתוח שהתמיכה בו הופסקה רשמית

את ה-Errata (בלטינית "טעויות") כבר הזכרתי פעם או פעמיים בעבר בבלוג, אך הפעם החלטתי להקדיש למסמך חשוב זה פוסט שלם. הטריגר לפוסט היה הגילוי שהתחילו למכור מיקרו-בקרים ממשפחת K42 החדשה של Microchip. לא ניכנס לפרטים כאן, מספיק לומר שהמשפחה הזו מייצגת מהפכה גדולה בעולם ה-PIC, והתקדמות שצריכה להדאיג את כל המתחרים בזירת ה-8-ביט; רציתי מאוד להשיג אחד או שניים כאלה ולשחק איתם קצת.

אלא שהמציאות לא תמיד יפה כמו בחומרים השיווקיים, ולעתים קרובות ג'וקים חדשים שיוצאים לשוק כוללים כמה באגים בחומרה. ה-Datasheet מפרט את התכונות של הג'וק רק על פי התוכנית המקורית, לא לפי איך שהם ירדו בפועל מפס הייצור, ובין התוכנית לייצור יכולות להתרחש כל מיני תקלות. התקלות שמזוהות נרשמות בקובץ ה-Errata. חברות שונות קוראות לו בשמות קצת שונים (למשל Silicon Errata או Erratasheet), אבל הכוונה זהה.

זה נכון שקשה להימנע לחלוטין מבאגים, ובכל זאת יש משהו קצת מסריח בקטע הזה. לדוגמה, ה-K42 יצאו לשוק לפני פחות מחודש, ולכן אין מצב שה-Errata הנוכחי שלהם מבוסס על פידבק ממשתמשים בשטח. מישהו בחברה עצמה ערך בדיקות יסודיות, עלה על תקלות וניסח אותן בצורה מסודרת במסמך. זאת אומרת שהחברה ידעה מראש שהיא מוציאה לשוק שבבים תקולים. אז למה לא לעצור את הייצור/הפצה, לתקן מה שאפשר ולספק ללקוחות שבב נקי מבאגים כבר מהקנייה הראשונה?

לוח פיתוח עם שבב של ST, שידוע לשמצה בגלל בעיות בחומרת ה-I2C
לוח פיתוח עם שבב של ST, שידוע לשמצה בגלל בעיות בחומרת ה-I2C

לצערנו, כל היצרנים עושים את זה, וכמו שקורה גם בהרבה מוצרי תוכנה כיום, הלקוח הופך להיות – נגד רצונו – בודק הבטא של החברות. מי שזה מתאים לו סבבה, ומי שלא (כמוני) יחכה לגרסאות הסיליקון הבאות והמשופרות של הרכיב – בשאיפה שיהיו כאלה. עד אז, בואו ונראה מה יש במסמך Errata טיפוסי.

החלק החשוב הראשון הוא טבלת הסיכום, שמתארת בקצרה את הבאגים המוכרים ואת גרסאות הסיליקון שבהן הם קיימים. עיון בטבלה הזו יכול לגלות לנו עד כמה המצב חמור באופן כללי, ועד כמה זה רלוונטי ליישום ספציפי שאנחנו צריכים. למשל, אם למיקרו-בקר מסוים מפורטות עשר תקלות במודול DAC, יכול להיות שזה עדיין יהיה בסדר גמור מבחינתנו אם אין לנו שום כוונה להשתמש ב-DAC. כמו כן, אם השגנו גרסת סיליקון חדשה ומעודכנת, ייתכן שנראה שרוב הבעיות בכלל לא קיימות יותר.

טבלת סיכום לדוגמה מה-Errata של PIC18F24K42
טבלת סיכום לדוגמה מה-Errata של PIC18F24K42

בהמשך המסמך מחכה לנו הפירוט של התקלות האלה. לגבי כל אחת יש תיאור מפורט של התנאים בהם היא באה לידי ביטוי, וכן – חשוב מאוד! – דרכים להתמודד איתה או לעקוף אותה (Workaround), אם יש כאלה. לפעמים הפתרון המוצע הוא משהו אזוטרי שצריך להתרחש ברמת הקומפיילר או קוד האסמבלי, לפעמים זה משהו פשוט שגם אנחנו יכולים לבצע בקלות בקוד שלנו, ולפעמים אין שום פתרון.

דוגמה לפירוט של בעיה ללא פתרון (ה-FLASH לא מחזיק מעמד במספר הכתיבות שהובטח)
דוגמה לפירוט של בעיה ללא פתרון (ה-FLASH לא מחזיק מעמד במספר הכתיבות שהובטח)

לסיום, בחלק ממסמכי ה-Errata (למשל באלה של Microchip) מופיעות גם "הבהרות" לגבי ה-Datasheet, כלומר הסברים ותיקונים שלא הספיקו להיכנס לגרסה הנוכחית שלו. ליתר ביטחון כדאי לסקור גם את שאר המסמך, ולבדוק שלא החביאו בו הפתעות לא נעימות נוספות.

צריך לזכור שה-Errata הוא לא הסמכות המוחלטת והסופית בנושא באגים בחומרה: מה שמופיע בו הם רק הבאגים שזוהו. ייתכן בהחלט שיש עוד בעיות שאורבות שם בפנים, ושאתם תהיו בין הראשונים שיסבלו מהן…

תוספת מאוחרת: בדרך כלל ה-Errata נמצא באותו מקום עם ה-Datasheet, אבל אם לא מוצאים אותו בשום מקום, ייתכן שהתוכן כלול בתוך ה-Datasheet עצמו. כרגיל, לכל יצרן יש דרך משלו לעשות דברים.

להרשמה
הודע לי על
2 תגובות
מהכי חדשה
מהכי ישנה לפי הצבעות
Inline Feedbacks
הראה את כל התגובות

נו באמת… עוד RTFM אחד…
מניסיון, צריך לפחות 2-3 גרסות revisions לצ'יפים, כך שאם אתה רוצה משהו יציב, אל תשתמש בצ'יפים שה-revision שלהם הוא A או B.
בהנחה שלא הכניסו עוד באגים ב-C והלאה…