סקירה כללית
קובץ קושחה יכול להיות תקף לחלוטין ועדיין לא מוכן לייצור.
עבור תכנות קושחה על מכלול PCB, צוות EMS צריך את התמונה שפורסמה, התקן היעד המדויק, גרסת הלוח שעליו הוא חל, ממשק התכנות, כל כתובת זיכרון או תצורת מכשיר נדרשת, ודרך מוגדרת לאימות התוצאה. מוצרים שדורשים גם מספרים סידוריים, כתובות MAC, ערכי כיול או אישורי אבטחה זקוקים להוראות טיפול נוספות.
בדיקת ייצור שימושית היא פשוטה:
האם טכנאי שלא כתב את הקושחה יכול לתכנת את הלוח נכון מההוראות שפורסמו?
אם לא, ייתכן שהתוכנה תסתיים מנקודת מבט של פיתוח, אך מסירת הייצור לא.
שים את מהדורת התכנות בעמוד אחד
תמונת הקושחה היא רק חלק אחד מהמסירה.
עבור פרויקטים רבים, המסמך הנלווה השימושי ביותר הוא גיליון שחרור תכנות קצר שמספר לייצור מה אושר וכיצד יש להשתמש בו.
אין זה משנה אם הלקוח מכנה זאת הוראת תכנות, הערת שחרור, הוראת ייצור או הוראת עבודה מבוקרת. החלק החשוב הוא שהמפעיל לא צריך לשחזר את ההגדרה משרשורי דואר אלקטרוני, הערות פיתוח ישנות ושמות קבצים.
גיליון שחרור מעשי עשוי לכלול:
|
שדה שחרור |
מה ההפקה צריכה |
|
שחרור קושחה |
קובץ או קבצים מאושרים מדויקים |
|
עדכון קושחה |
גרסת תוכנה שפורסמה |
|
מכשיר יעד |
מכשיר ניתן לתכנות מדויק |
|
עדכון מועצת המנהלים |
עדכון חומרה אושר עבור הקושחה |
|
ממשק תכנות |
SWD, JTAG, UART, USB DFU, SPI או ממשק מוגדר אחר |
|
גישה לתכנות |
נקודות בדיקה נגישות לכותרת, מחבר, מתקן- או שיטה אחרת |
|
יעד זיכרון |
כתובת התחל או אזור זיכרון במידת הצורך |
|
תצורת המכשיר |
בתים של אופציות, מילות תצורה, נתיכים, הגדרות אתחול או הגנה במידת האפשר |
|
הגדרת תכנות |
מתכנת, פרויקט, סקריפט או הגדרות מאושר במידת הצורך |
|
נתונים ספציפיים-ליחידה |
מספר סידורי, כתובת MAC, ערך כיול או נתונים אחרים לכל-יחידה, במידת הצורך |
|
שיטת אימות |
איך ההפקה מאשרת שהתכנות עבר |
|
פוסט{0}}שלב התכנות |
בדיקת אתחול, בדיקה פונקציונלית, תיוג, מעקב או פעולה נדרשת אחרת |
לוח MCU פשוט עשוי להזדקק רק לכמה מהפריטים הללו. מוצר עם מספר התקנים הניתנים לתכנות, גרסאות קושחה מרובות, מזהים ייחודיים או פונקציות אבטחה יצטרך יותר.
גיליון השחרור מרחיק החלטות הנדסיות מידיו של המפעיל. כשהלוח מגיע לתכנות, התמונה, ההגדרה וכללי האימות המאושרים כבר אמורים להיות ברורים.
שלוש דרכים שבהן קובץ קושחה תקין עדיין יכול להפסיק את הייצור
הקובץ עצמו לרוב אינו הבעיה. המידע סביבו הוא.
ה-BIN נכון, אבל אף אחד לא הגדיר את הכתובת
קובץ בינארי גולמי מכיל את הנתונים שיש לתכנת, אך הוא אינו אומר מטבעו למתכנת לאן שייכים הנתונים הללו.
זה שונה מתבניות נושאות-כתובות כגון Intel HEX או Motorola S-רשומה.
לכן קובץ .bin יכול להיות תקף לחלוטין בזמן שהוראת הייצור עדיין לא שלמה. אם זרימת העבודה של התכנות דורשת כתובת התחלה או אזור זיכרון, המידע הזה חייב להגיע ממקום אחר מלבד הקובץ הבינארי.
זו הסיבה שקבלת הקושחה אינה זהה להוצאת תכנות שמישה.
הקושחה נכונה, אבל היא שייכת לעדכון לוח אחר
תיקוני קושחה וחומרה נשלטים לעתים קרובות בנפרד. זה בדרך כלל בסדר עד ששינוי חומרה משפיע על התאימות.
שקול פרויקט עם קושחה V1.6, Board Rev.B ו- Board Rev.C. כל השלושה עשויים להיות פריטים תקפים שפורסמו, אך ייתכן ש-Firmware V1.6 אושרה רק עבור Rev.C.
שתי גרסאות נכונות בנפרד עדיין יכולות ליצור שילוב ייצור שגוי.
מהדורת התכנות צריכה לזהות את גרסת הלוח הרלוונטית בכל פעם ששינוי חומרה יכול להשפיע על:
- מטלות סיכות;
- סוגי חיישנים;
- התקני זיכרון;
- ממשקי תקשורת;
- תצורת אתחול;
- מיפוי קלט/פלט;
- התנהגות כיול.
אין לצפות ששם קובץ הקושחה ישא החלטה זו בעצמו.
המתכנת אומר PASS, אבל הלוח עדיין לא שוחרר
PASS ירוק על המתכנת אומר לך ששלב התכנות עמד בכלל האימות המוגדר שלו.
זה לא אומר לך אם הלוח המורכב מתקשר בצורה נכונה, קורא את החיישנים שלו, מחליף את היציאות שלו או מתנהג כראוי תחת עומס.
לוח יכול לתכנת בהצלחה ועדיין יש לו פגם בהרכבה, תצורת חומרה שגויה, בעיית תקשורת, תקלת חשמל או כשל ברמת האפליקציה.-
זה המקום שבו בדיקות פונקציונליות מתחילות לעשות עבודה אחרת.
אימות תכנות מאשר את פעולת התכנות. בדיקה פונקציונלית בודקת את ההתנהגות של המכלול המתוכנת.
פורמט הקובץ חשוב פחות משיטת תכנות ברורה
HEX ו-BIN נפוצים, אבל אף אחד מהם אינו אוטומטית התשובה הנכונה לכל מוצר.
זרימות עבודה של תכנות ייצור עשויות להשתמש גם ב:
- ELF או תבניות הפעלה קשורות;
- מוטורולה S-תקליט;
- קובצי תכנות ספציפיים-לספק;
- -חבילות תצורה ספציפיות למכשיר.
BIN גולמי זקוק בדרך כלל לכתובת יעד מוגדרת בנפרד. פורמטים הנושאים-כתובות יכולים לשאת יותר מידע זה בתוך הקובץ. האם נעשה שימוש ב-ELF, HEX, BIN, S- או פורמט אחר תלוי במכשיר היעד ובהגדרת התכנות המאושרת.
ברצפת הייצור, הכלל פשוט יותר:
השתמש בפורמט הנתמך על ידי הגדרת התכנות המאושרת, ותעד כל מה שהקובץ עצמו אינו מגדיר.
אם היקף ה-EMS מוגבל לתכנות תמונת ייצור מאושרת, קוד המקור הוא בדרך כלל מיותר. קוד מקור, פרויקטים של IDE וסביבות בנייה הופכים לרלוונטיים כאשר קומפילציה, איתור באגים, שינוי קושחה או הפקת-תמונות היא חלק מההיקף המוסכם.
שליחת כל המאגר עדיין לא אומרת לייצור איזה build מאושר.
גישה לתכנות היא גם החלטת חומרה
עבור-תכנות מערכת, חבילת התוכנה היא רק חצי מההגדרה.
תחנת הייצור זקוקה גם לגישה פיזית וחשמלית למכשיר היעד.
בהתאם למוצר, זה עשוי להיות באמצעות:
- SWD;
- JTAG;
- UART או ממשק מאתחול אחר;
- USB DFU;
- SPI;
- מחבר תכנות ייעודי;
- מתקן-נקודות בדיקה נגישות;
- ממשק -ספציפי למכשיר אחר.
ייתכן שהוראת התכנות תצטרך גם להגדיר את מצב המתח של הלוח, המחבר או -נקודת הבדיקה, מצב האתחול הנדרש, מתאם התכנות, התנהגות האיפוס ורצף המחיקה/תוכנית/אימות הצפוי.
פרטים אלו נפתרים בצורה הטובה ביותר לפני שהלוחות המורכבים מגיעים לתחנת התכנות.
לא ניתן לתקן אות SWD בלתי נגיש על ידי שליחת קובץ HEX טוב יותר.
עבור מוצרים התלויים בגישה למכשיר או בתכנות נקודות בדיקה, מוכנות לתכנות היא בחלקה בעיה של DFT, לא רק העברת תוכנה.
שמור את עדכון הקושחה ועדכון הלוח ביחד
קבצים בשם latest.hex או final_new_v2.bin עשויים להיות מובנים לחלוטין לאדם שיצר אותם. הם בקרות ייצור גרועות.
הייצור זקוק לדרך אמינה כדי להבחין בין הגרסה המאושרת לבין:
- גרסה מיושנת;
- מבנה הנדסי;
- תמונה-לבדיקה בלבד;
- וריאנט מוצר נוסף.
בהתאם למערכת הבקרה של מסמכים-של הלקוח, הזהות שפורסמה עשויה לכלול את גירסת הקושחה, שם הקובץ המבוקר, תאריך השחרור, גירסת הלוח הרלוונטית, הפניה לאישור לקוח, גודל הקובץ או סכום בדיקה/hash.
הפקה אינה זקוקה לשמות אוניברסליים אחדים או סכימת בדיקה. זה כן צריך דרך אמינה להבדיל בין ה-build ששוחרר מכל השאר בתיקייה.
זה הופך להיות חשוב עוד יותר כאשר פלטפורמת חומרה אחת תומכת במספר גרסאות תוכנה. הלוחות עשויים להיראות זהים בעוד שהמוצרים המוגמרים אינם זהים.
כאשר התכנות כולל יחידה-נתונים ספציפיים
עבור מוצרים רבים, כל לוח מקבל את אותה תמונת קושחה.
מוצרים אחרים זקוקים גם למידע ספציפי-ליחידה כגון:
- מספרים סידוריים;
- כתובות MAC;
- מזהי מוצר;
- מקדמי כיול;
- תצורה אזורית;
- הגדרות-ספציפיות ללקוח;
- אישורי המכשיר.
בשלב זה, הקושחה הנפוצה והנתונים לכל-יחידה הם שני זרימות נתונים שונות.
ההפקה צריכה לדעת מהיכן מגיעים הערכים הייחודיים, היכן הם כתובים, כיצד כל ערך משויך ללוח הפיזי הנכון, וכיצד מונעים כפולות של הקצאות.
קל להתעלם מפרט אחד: מתי ערך ייחודי נחשב נצרך?
מספר סידורי או כתובת MAC עשויים להיחשב בשימוש כאשר הם מוקצים, כאשר התכנות מצליח, או רק לאחר שהיחידה עוברת את הבדיקה הנדרשת. אין כלל אחד לכל מוצר, אבל צריך להיות כלל מוסכם לפני תחילת הבנייה.
כך גם לגבי יחידות שנכשלו. הצוות צריך לדעת אם ניתן לעשות שימוש חוזר בערך שהוקצה, יש לפרוש, או להישאר מקושר ללוח שנכשל לצורך מעקב.
מעבר תכנות אינו מעבר FCT
אימות תכנות ובדיקות פונקציונליות עשויים להתרחש קרוב זה לזה בזרימת הייצור, אך הם עונים על שאלות שונות.
אימות תכנות
אימות תכנות שואל:
האם הנתונים המיועדים נכתבו כהלכה לפי שיטת התכנות המאושרת?
בהתאם למכשיר ולהגדרה, זה עשוי להיות כרוך בפונקציית אימות של מתכנת, השוואת קריאה חוזרת כאשר הדבר מותר, CRC, אימות תצורה או שיטה מאושרת אחרת.
בדיקה פונקציונלית
בדיקה פונקציונלית שואלת:
האם מכלול ה-PCB המופעל והמתוכנת מבצע את הפונקציות הנדרשות על ידי המוצר?
בהתאם לפרויקט, זה עשוי לכלול:
- התנהגות-העצמת כוח;
- תִקשׁוֹרֶת;
- תגובת קלט/פלט;
- קלט חיישן;
- פלט ממסר או מפעיל;
- תיקו נוכחי;
- תנאי הפעלה של הלקוח-.
אין להתייחס אוטומטית למתכנת המציג PASS כראיה לכך שמכלול ה-PCB עבר FCT.
עבור פרויקטים הדורשים תיאום טעינת קושחה עם אימות רמת הלוח-, STHL'sבדיקה ובדיקההיכולות מספקות את נתיב השירות הרלוונטי.
שני מצבים שדורשים הנחיות נוספות
רוב עבודות התכנות אינן זקוקות לתהליך הקצאה משוכלל. שני מצבים אכן ראויים לתשומת לב נוספת כאשר הם חלים.
בדיקת קושחה וקושחת ייצור
חלק מהמוצרים משתמשים בקושחת אבחון במהלך הייצור ובשחרור קושחה שונה למשלוח.
אם כן, ההפקה צריכה לדעת איזו תמונה חלה בכל שלב, מתי מוחלפת תמונת הבדיקה, כיצד מאושרת ההפצה הסופית והאם נדרשת בדיקה תפקודית נוספת לאחר מכן.
אחרת, לוח יכול לעבור אבחון ייצור ועדיין לעזוב את הייצור כשהקושחה הלא נכונה מותקנת.
לא כל מוצר צריך קושחת בדיקה נפרדת. התהליך צריך לעקוב אחר המוצר בפועל.
אספקה מאובטחת
חלק מהמכשירים התומכים ב-אבטחה דורשים תמונות חתומות או מוצפנות, הגדרות אתחול- מאובטחות, תצורת OTP/eFuse, מפתחות, אישורים או נתוני הקצאה מבוקרים אחרים.
כאשר דרישות אלה חלות, ספק OEM ו-EMS צריכים להסכים למי הבעלים של הנתונים הרגישים, אילו פעולות הייצור מורשה לבצע וכיצד מאושרות הגדרות בלתי הפיכות.
אין לטפל בפריטים אלה כמו קבצי קושחה רגילים.
מה אם הקושחה משתנה לאחר תחילת התכנות?
ניתן למקם תמונת קושחה חדשה בתיקייה משותפת כמעט מיד.
הלוחות שכבר נמצאים ברצפת הייצור אינם משתנים איתו.
אם מהדורה חדשה מגיעה לאחר תחילת התכנות, הצוות צריך נטייה ברורה עבור:
- יחידות שכבר מתוכנתות עם הגרסה הקודמת;
- יחידות שכבר נבדקו;
- יחידות ממתינות לתכנות;
- האם נדרש תכנות מחדש;
- האם הבדיקה התפקודית מושפעת;
- האם נדרשת בדיקה חוזרת;
- היכן גבול התיקון יושב בתוך מגרש הייצור.
רמת הביקורת צריכה לעקוב אחר השינוי.
מחרוזת תצוגה מתוקנת ושינוי בהתנהגות השליטה-בכוח אינם נושאים את אותו סיכון ייצור. אבל אין להציג את שניהם פשוט על ידי החלפת קובץ והוראת הקו להמשיך.
זה המקום שבו בקרת גרסאות מפסיקה להיות ניירת והופכת לבקרת ייצור.
בדיקת קדם-קצרה קצרה
לפני שתוכנת יחידת הייצור הראשונה, הקונה וצוות EMS אמורים להיות מסוגלים לענות:
- איזו תמונה או תמונות בדיוק מתפרסמות?
- איזה מכשיר ניתן לתכנות מקבל כל תמונה?
- לאיזה גרסת לוח אושרה הקושחה?
- האם נדרשת כתובת טעינה או מפת זיכרון?
- האם בתים של אפשרויות, נתיכים או נתוני תצורה מוטבעים או נפרדים?
- באיזה ממשק תכנות משתמשים?
- האם גישת התכנות הנדרשת זמינה בלוח?
- כיצד מופעל הלוח במהלך התכנות?
- איזה מתכנת, פרויקט או הגדרה מאושרת חלים?
- האם נדרשים נתונים ספציפיים-ליחידה?
- מה מוכיח שפעולת התכנות עברה?
- האם נדרשת בדיקה פונקציונלית או בדיקה אחרת לאחר מכן?
- האם הפרויקט משתמש בקושחה לבדיקה, בהקצאה מאובטחת או בזרימת עבודה מיוחדת אחרת?
אם התשובות הללו ברורות, חבילת התכנות עצמה עשויה להכיל רק כמה קבצים.
אם הם לא, הוספת קבצים נוספים פותרת רק לעתים נדירות את הסגירה.
כיצד STHL תומך בתכנות קושחה בתוך ייצור PCBA
Shenzhen STHL Technology Co., Ltd (STHL) תומכת בתכנות MCU, FPGA ו-EEPROM כחלק מפרויקטי הרכבת PCB ישימים. ניתן לתאם תכנות עם בדיקות פונקציונליות ודרישות מעקב ספציפיות לפרויקט-במידת הצורך.
עבור בנייה בודדת, סקירת התכנות עשויה לכסות את התמונה שפורסמה, מכשיר היעד, גרסת הלוח, גישת התכנות, תצורת המכשיר הנדרשת, שיטת האימות וכל נתון-ספציפי ליחידה שסופק על ידי הלקוח.
יש להסכים על המתכנת, המתקן או הכבל המדויק, דרישות האבטחה, בעלות הקושחה ורשומות הייצור הנדרשות עבור הפרויקט הספציפי במקום להניח מהצהרת יכולת כללית.
מַסְקָנָה
דרישות תכנות הקושחה החשובות ביותר של PCBA אינן מוגדרות לפי האם הלקוח שולח HEX, BIN, ELF או קובץ נתמך אחר.
מסירה מוכנה-לייצור אמורה לאפשר לצוות הייצור לענות על ארבע שאלות בסיסיות:
- אילו נתונים יש לתכנת?
- לאיזה גרסה של מכשיר ולוח זה שייך?
- איך ההפקה צריכה לתכנת ולאמת אותה?
- מה צריך לקרות לפני שמכלול ה-PCB עובר לשלב הייצור הבא?
עבור לוח MCU פשוט, התשובות הללו עשויות להתאים לדף אחד. מוצר עם מספר התקנים הניתנים לתכנות, נתונים ייחודיים, גרסאות קושחה מרובות או דרישות אבטחה יזדקקו כמובן לפרטים נוספים.
הקושחה מוכנה לייצור כאשר צוות הפקה מוסמך יכול לחזור על תהליך התכנות המאושר מהמידע ששוחרר, במקום להסתמך על ידע שקיים רק בראשו של המפתח.
עבור מבנה הדורש תכנות קושחה, כלול את קבצי התכנות הזמינים והוראות עם ה-BOM, קבצי Gerber, מידע הרכבה, כמות ודרישות בדיקה כאשר אתהשלח את פרטי פרויקט ה-PCBA שלך.
לשאלות ספציפיות-תכנות, צור קשר עם STHL בכתובתinfo@pcba-china.com.
