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

אחרי שהקונה האומלל התייאש מהניסיונות לתפעל לבד את חמשת הלוחות שקנה (Pro Mini 3.3V 8MHz), הוא פנה לעזרה בקבוצת ארדואינו בפייסבוק, ושם ניתך עליו גשם של עצות – חלקן הגיוניות ביותר, חלקן הזויות – אך הבעיה לא נפתרה. כך הגיעו אליי שניים מהלוחות, וכשהתפניתי קצת (עם דגש על "קצת") מטרדות היומיום התיישבתי לבדוק מה לא בסדר.

בדיקה ויזואלית

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

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

לא עובד

הלד המובנה הציג הבהוב ראשוני שמאפיין תוכנות Bootloader לארדואינו, ואחריו הבהוב קצר פעם בשלוש שניות לערך. אלה היו סימנים טובים יחסית, עדות לכך שהלוח לפחות לא הרוס במידה קטסטרופלית. הוצאתי מהמגירה מתאם USB-to-TTL, מהסוג איתו נהוג להעלות קוד ל-Pro Mini – וזה לא עבד. סביבת הפיתוח עשתה את עצמה עובדת במשך כדקה, עד שהתייאשה והחזירה את הטקסט המוכר

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x8c
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x8c
 avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8c
avrdude: stk500_recv(): programmer is not responding

וכן הלאה. בהקשר של ארדואינו, הודעה זו פירושה בדרך כלל שהצורב לא הצליח לתקשר כמו שצריך עם ה-Bootloader שעל המיקרו-בקר, ולזה יכולות להיות כמה סיבות, אך לא התעכבתי אליהן אלא הוצאתי את התותחים הכבדים: סביבת הפיתוח Atmel Studio וצורב AVR מקצועי.

מידע פנימי

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

העתקתי את תוכן ה-Flash של המיקרו-בקר אל קובץ HEX במחשב, פתחתי אותו בעורך טקסט והשוויתי את הסוף שלו (המקום שבו נמצא קוד ה-Bootloader) לקובץ ה-Bootloader שמסתתר אי-שם בתיקיות הארדואינו. קובצי HEX נראים כמו בלוקים ענקיים של ספרות ואותיות, ואי אפשר להבין מהם כלום בעין, אבל כן הבחנתי מייד שהקוד שהגיע מהלוח הוא הרבה יותר ארוך. איזה מין Bootloader זה? העתקתי שורת טקסט וחיפשתי אותה בגוגל. הסתבר שזהו Bootloader לארדואינו של Sparkfun, אם כי בהשוואה מדוקדקת יותר התגלה שהוא לא זהה לו לחלוטין – מספר בייטים בסוף היו שונים. האם זו הסיבה לתקלה?

שמונה שניות לפתרון

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

הסיבה לעיכוב היא שברוב המתאמים USB-to-TTL הנפוצים, אין קו Reset נורמלי שאפשר לחבר לארדואינו, וזה מחייב את המשתמש ללחוץ ידנית על לחצן האתחול חלקיק שניה לפני תחילת הצריבה. כדי שהתהליך לא יהיה מתסכל כל כך, הוסיפו ל-Bootloader הזה שמונה שניות המתנה אקסטרה, שבהן המשתמש יכול להתחיל את הצריבה בלי לחץ.

צרבתי Bootloader אחר, הפעם בלי המילה Mini בסוף, ועכשיו הכל עבד כצפוי, בשני הלוחות.

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