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

כך זה התחיל

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

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

גירדתי את עודפי הבדיל האלה בעזרת קיסם, הרכבתי משקפי מגן וחיברתי את הארדואינו לסוללה (כדי שלא ישמיד לי בטעות את יציאת ה-USB של המחשב). האורות דווקא נדלקו, ה-Bootloader הבהב קצת, ואחריו החלה לפעול תוכנת Blink שנצרבה מראש. יופי! ניתקתי את הסוללה וחיברתי למחשב. הלוח זוהה מיד כפורט לגיטימי, אז כבדיקה ראשונית ניסיתי להעלות אליו קוד "ריק" חדש.

avrdude: stk500_recv(): programmer is not responding

זו היתה השגיאה שהופיעה, ואחריה ניסתה סביבת הפיתוח של ארדואינו ליצור קשר שוב, עשר פעמים, ובכל פעם נכשלה:

avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x01

בכל פעם שסביבת הפיתוח ניסתה להעלות קוד, נורית החיווי של RX על הלוח הבהבה קצת, אבל לא היתה שום תגובה ב-TX.

החקירה נפתחת

לקחתי לוח תואם Uno R3 אחר, שידעתי שהוא עובד טוב, והחלפתי בין המיקרו-בקרים. זה של הלוח התקול עבד מצוין על הלוח החלופי, אבל הלוח התקול המשיך לעשות בעיות גם עם המיקרו-בקר החדש. במילים אחרות, האשמה היא לא ב-ATmega328 אלא איפשהו בלוח.

הניסוי הבא היה  בדיקת משוב (loop back test), שבה מחברים בחוט את RX ישירות ל-TX, פותחים את ה-Serial Monitor ושולחים כמה אותיות. אם הכל תקין, נקבל את אותן אותיות בחזרה מיד, כהד. המבחן הזה כל כך בסיסי, וכל כך נדיר שלוח ארדואינו ייכשל בו, עד שקשה בכלל למצוא באינטרנט מה עושים אם הוא נכשל! ואף על פי כן, הלוח החדש שלי נכשל במבחן הזה. כל העדויות הובילו לבעיה רצינית בקו ה-TX, אף על פי שבדיקת רציפות במולטימטר הראתה שכניסות RX ו-TX בלוח מחוברות היטב חשמלית לפינים הנכונים ב-ATmega328.

החשוד המיידי

בלוחות Uno R3, התרגום בין ה-USB לבין קווי ה-Serial של המיקרו-בקר (RX/TX) נעשה על ידי מיקרו-בקר נוסף מדגם ATmega16U2. שלפתי את הכלים המקצועיים – צורב AVRISP MKII וסביבת הפיתוח Atmel Studio – והתחלתי לחטט בג'וק הזה. הגדרות הפיוזים שלו היו נכונות, לפי מפרטים שמצאתי ברשת, וגם הקוד שהיה צרוב עליו היה נכון (קראתי אותו מהג'וק לקובץ במחשב והשוויתי לקבצים שמגיעים עם התקנת הארדואינו, בתיקיה Arduino/hardware/arduino/avr/firmwares/atmegaxxu2).

במקביל, חיפשתי הרבה בגוגל, ומצאתי רק פוסט אחד של מישהו עם בעיה זהה, משנת 2012(!). הפוסט ההוא נותר ללא תשובה. אני לגמרי לבד.

כתבתי תוכנה עבור ה-ATmega16U2 עצמו, שמגדירה את פינים RX ו-TX שלו כפלט ושולחת דרכם פולסים סדירים, וצרבתי אותה עליו דרך חיבור ה-ICSP שליד הג'וק. בעזרת סקופ בחנתי את מה שמופיע בחיבורי RX/TX שבצדי הלוח… וראיתי בשניהם את האות הצפוי!

אחרי זה, בשביל הכיף, כתבתי תוכנית נוספת שהבהבה בנוריות ה-LED של RX ו-TX על הלוח – מסתבר שהן לא מוזנות מקווי התקשורת עצמם אלא מפינים סמוכים של ה-ATmega16U2 – ולאחר מכן צרבתי מחדש את הקוד המקורי. הבעיה לא נפתרה כמובן, ולמרבה העצבים גם לא קיבלתי תשובה מ-ICStation למייל ששלחתי להם בנושא. כבר הייתי מוכן לנתק את ה-ATmega328 התקין ולהשליך את שאר הלוח לפח בשאט נפש.

המפנה

אלא שאחרי כמה ימים חזרתי אליו. פשוט לא נראה לי הגיוני שלא אצליח למצוא את מקור הבעיה, כי בסופו של דבר זה לא מעגל כזה מורכב, וחייב להיות פתרון. עם זכוכית מגדלת והמון סבלנות עברתי לכל אורך הנתיבים המתפתלים, משני צדי הלוח, בין RX/TX של ה-ATmega328 לאלה של ה-ATmega16U2. בשלב מסוים, שני הנתיבים עוברים דרך משהו שנראה כמו ג'וק זעיר עם שמונה רגליים. למזלי, לפני זמן לא רב הלחמתי רכיבים כאלה בדיוק בקיט ה-SMD, וכך ידעתי שזהו בסך הכל מארז קומפקטי לארבעה נגדים נפרדים לגמרי. המולטימטר הראה התנגדות תקינה בין כל זוג רגליים.

הגישה עם הפרובים הרגילים והעבים (יחסית) של המולטימטר שלי אל הפינים המיניאטוריים של ה-ATmega16U2 היא משימה למנתח מוח רגוע במיוחד, אבל איכשהו הצלחתי לעשות זאת למספיק זמן כדי לראות משהו משונה – התנגדות גדולה מהצפוי בין פין RX שם ל"יציאה" מהנגד שעל הקו. מכיוון שאין נגדים נוספים או רכיבים אחרים ביניהם, הבנתי שהסיבה חייבת להיות מגע רופף – כנראה הלחמה בעייתית עם שטח מגע קטן מדי או מזוהם שאינו נותן למספיק חשמל לעבור. זה סותר לכאורה את הממצא מתוכנת הפולסים שכתבתי, אלא שהיא הגדירה כאמור את RX כפלט, ואילו בפועל, במצב תקשורת רגיל, הוא מוגדר כפין קלט – ואם אינני טועה, גם עם נגד Pull-up פנימי, מה שבהחלט יכול לשנות את התוצאות.

לא ראיתי בעין בעיית הלחמה, אבל זה לא מוכיח כלום – הרכיבים קטנים מאד, בזוויות שקשה לבחון עם זכוכית מגדלת. אם יש בעיה, היא יכולה להיות בשני מקומות: ברגל של הנגד ו/או בפין RX של ה-ATmega16U2. מטעמי גודל הרכיבים בחרתי לנסות את האפשרות הראשונה קודם, חיממתי מלחם ופשוט נגעתי לשניה ברגל המתאימה של הנגד.

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

הפקת לקחים

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

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