Ce fișiere de firmware sunt necesare pentru programarea PCBA?

Prezentare generală

Un fișier de firmware poate fi perfect valid și tot nu poate fi pregătit pentru producție.

Pentru programarea firmware-ului pe un ansamblu PCB, echipa EMS are nevoie de imaginea lansată, dispozitivul țintă exact, revizuirea plăcii căreia i se aplică, interfața de programare, orice adresă de memorie necesară sau configurația dispozitivului și o modalitate definită de a verifica rezultatul. Produsele care necesită, de asemenea, numere de serie, adrese MAC, valori de calibrare sau acreditări de securitate au nevoie de instrucțiuni suplimentare de manipulare.

O verificare utilă a producției este simplă:

Poate un tehnician care nu a scris firmware-ul să programeze placa corect din instrucțiunile lansate?

Dacă nu, software-ul poate fi terminat din punct de vedere al dezvoltării, dar transferul de producție nu este.

Pune versiunea de programare pe o singură pagină

Imaginea firmware-ului este doar o parte a transferului.

Pentru multe proiecte, cel mai util document însoțitor este o scurtă fișă de lansare de programare care spune producției ce a fost aprobat și cum ar trebui să fie utilizat.

Nu contează dacă clientul numește aceasta instrucțiune de programare, notă de lansare, instrucțiune de fabricație sau instrucțiune de lucru controlat. Partea importantă este că operatorul nu trebuie să reconstruiască configurația din fire de e-mail, note de dezvoltare vechi și nume de fișiere.

O fișă practică de eliberare poate include:

O placă MCU simplă poate avea nevoie doar de câteva dintre aceste elemente. Un produs cu mai multe dispozitive programabile, mai multe variante de firmware, identificatori unici sau funcții de securitate va avea nevoie de mai mult.

Foaia de eliberare ține deciziile de inginerie departe de mâinile operatorului. În momentul în care placa ajunge la programare, imaginea aprobată, configurarea și regula de verificare ar trebui să fie deja clare.

Formatul fișierului contează mai puțin decât o metodă clară de programare

HEX și BIN sunt comune, dar niciunul nu este automat răspunsul potrivit pentru fiecare produs.

Fluxurile de lucru de programare de producție pot utiliza, de asemenea:

• ELF sau formate executabile aferente;
• Motorola S-record;
• fișiere de programare-specifice furnizorului;
• pachete de configurare specifice-dispozitivului.

Un BIN brut necesită, în general, o adresă de destinație definită separat. Formatele purtătoare de adresă-poate conține mai multe informații în fișier. Dacă se utilizează ELF, HEX, BIN, S-record sau alt format, depinde de dispozitivul țintă și de configurația de programare aprobată.

La nivelul producției, regula este mai simplă:

Utilizați un format acceptat de configurația de programare aprobată și documentați orice nu definește fișierul în sine.

Dacă domeniul EMS este limitat la programarea unei imagini de producție aprobate, codul sursă este de obicei inutil. Codul sursă, proiectele IDE și mediile de compilare devin relevante atunci când compilarea, depanarea, modificarea firmware-ului sau generarea de imagini-de producție face parte din domeniul de aplicare convenit.

Trimiterea întregului depozit încă nu spune producției care build este aprobată.

Accesul la programare este și o decizie hardware

Pentru programarea în-sistem, pachetul software reprezintă doar jumătate din configurație.

Stația de producție are nevoie și de acces fizic și electric la dispozitivul țintă.

În funcție de produs, poate fi prin:

• SWD;
• JTAG;
• UART sau altă interfață bootloader;
• USB DFU;
• SPI;
• un conector de programare dedicat;
• puncte de testare accesibile-fixare;
• un alt dispozitiv-interfață specifică.

Este posibil ca instrucțiunile de programare să necesite, de asemenea, să definească starea de alimentare a plăcii, conectorul sau punctul{0}}de test, starea de pornire necesară, adaptorul de programare, comportamentul de resetare și secvența așteptată de ștergere/programare/verificare.

Aceste detalii sunt rezolvate cel mai bine înainte ca plăcile asamblate să ajungă la stația de programare.

Un semnal SWD inaccesibil nu poate fi remediat prin trimiterea unui fișier HEX mai bun.

Pentru produsele care depind de accesul la fixare sau de programarea punctelor de testare, pregătirea pentru programare este parțial o problemă DFT, nu doar o transferare a software-ului.

 

Păstrați împreună revizuirea firmware-ului și revizuirea plăcii

Fișierele denumite latest.hex sau final_new_v2.bin pot fi perfect de înțeles de persoana care le-a creat. Sunt controale slabe de producție.

Fabricarea necesită o modalitate fiabilă de a distinge eliberarea aprobată de:

• o versiune învechită;
• o construcție de inginerie;
• o imagine-numai de test;
• altă variantă de produs.

În funcție de sistemul de control al documentelor-clientului, identitatea lansată poate include revizuirea firmware-ului, numele fișierului controlat, data lansării, revizuirea aplicabilă a plăcii, referința aprobării clientului, dimensiunea fișierului sau o sumă de verificare/hash.

Producția nu are nevoie de o singură schemă universală de denumire sau de sumă de control. Are nevoie de o modalitate fiabilă de a distinge versiunea lansată de orice altceva din folder.

Acest lucru devine și mai important atunci când o platformă hardware acceptă mai multe variante de software. Plăcile pot arăta identice în timp ce produsele finite nu sunt.

 

Când programarea include date specifice unității-

Pentru multe produse, fiecare placă primește aceeași imagine de firmware.

Alte produse au nevoie și de informații specifice-unității, cum ar fi:

• numere de serie;
• adrese MAC;
• ID-uri de produs;
• coeficienți de calibrare;
• configurația regională;
• setări specifice-clientului;
• acreditările dispozitivului.

În acel moment, firmware-ul comun și datele pe{0}}unitate sunt două fluxuri de date diferite.

Producția ar trebui să știe de unde provin valorile unice, unde sunt scrise, cum este asociată fiecare valoare cu placa fizică corectă și cum sunt prevenite atribuirile duble.

Un detaliu este ușor de trecut cu vederea: când se consideră consumată o valoare unică?

Un număr de serie sau o adresă MAC poate fi considerată utilizată atunci când este atribuită, când programarea are succes sau numai după ce unitatea trece testul necesar. Nu există o regulă unică pentru fiecare produs, dar ar trebui să existe o regulă convenită înainte de începerea construcției.

Același lucru este valabil și pentru unitățile eșuate. Echipa trebuie să știe dacă o valoare atribuită poate fi reutilizată, trebuie retrasă sau rămâne legată de placa eșuată pentru trasabilitate.

 

Un permis de programare nu este un permis FCT

Verificarea programării și testarea funcțională pot avea loc strâns împreună în fluxul de producție, dar răspund la întrebări diferite.

Verificarea programarii

Verificarea programării cere:

Datele dorite au fost scrise corect conform metodei de programare aprobate?

În funcție de dispozitiv și de configurare, aceasta poate implica funcția de verificare a unui programator, comparația de citire, acolo unde este permisă, CRC, verificarea configurației sau o altă metodă aprobată.

Testare funcțională

Testarea funcțională întreabă:

Ansamblul PCB alimentat și programat îndeplinește funcțiile cerute de produs?

În funcție de proiect, acesta poate include:

• comportamentul de alimentare{0};
• comunicare;
• răspuns de intrare/ieșire;
• intrare senzor;
• ieșire releu sau actuator;
• consumul de curent;
• condiţiile de operare{0}}definite de client.

Un programator care afișează PASS nu trebuie tratat automat ca o dovadă că ansamblul PCB a trecut de FCT.

Pentru proiectele care necesită încărcarea firmware-ului să fie coordonată cu validarea la nivel-placă, STHLTestare și inspecțiecapabilitățile oferă calea de serviciu relevantă.

 

Două situații care au nevoie de instrucțiuni suplimentare

Majoritatea joburilor de programare nu au nevoie de un proces de furnizare elaborat. Două situații merită o atenție suplimentară atunci când se aplică.

Testați firmware și firmware de producție

Unele produse utilizează firmware de diagnosticare în timpul producției și o versiune diferită de firmware pentru livrare.

Dacă da, producția trebuie să știe ce imagine se aplică în fiecare etapă, când imaginea de test este înlocuită, cum este confirmată lansarea finală și dacă este necesară o altă verificare funcțională ulterior.

În caz contrar, o placă poate trece un diagnostic de producție și poate părăsi producția cu firmware-ul greșit instalat.

Nu fiecare produs are nevoie de firmware de testare separat. Procesul ar trebui să urmeze produsul real.

Aprovizionare securizată

Unele dispozitive cu securitate-activată necesită imagini semnate sau criptate, setări de pornire-securizate, configurație OTP/eFuse, chei, certificate sau alte date de furnizare controlate.

Când se aplică aceste cerințe, furnizorul OEM și EMS ar trebui să convină cine deține datele sensibile, ce operațiuni este autorizată să efectueze producția și cum sunt aprobate setările ireversibile.

Aceste elemente nu ar trebui să fie tratate ca atașamentele de firmware obișnuite.

Ce se întâmplă dacă firmware-ul se modifică după ce a început programarea?

O nouă imagine de firmware poate fi plasată într-un folder partajat aproape imediat.

Plăcile aflate deja pe etajul de producție nu se schimbă odată cu ea.

Dacă apare o nouă ediție după ce a început programarea, echipa are nevoie de o dispoziție clară pentru:

• unități deja programate cu versiunea anterioară;
• unități deja testate;
• unități în așteptare pentru programare;
• dacă este necesară reprogramarea;
• dacă testarea funcțională este afectată;
• dacă este necesară retestarea;
• unde limita de revizuire se află în lotul de producție.

Nivelul de revizuire ar trebui să urmeze schimbarea.

Un șir de afișare corectat și o modificare a comportamentului de control-putere nu implică același risc de fabricație. Dar niciunul nu ar trebui introdus pur și simplu prin înlocuirea unui fișier și spunând liniei să continue.

Aici controlul versiunilor încetează să mai fie documente și devine control al producției.

 

O scurtă verificare înainte de-producție

Înainte ca prima unitate de producție să fie programată, cumpărătorul și echipa EMS ar trebui să poată răspunde:

• Ce imagine sau ce imagini exacte sunt lansate?
• Ce dispozitiv programabil primește fiecare imagine?
• Pentru ce versiune a plăcii este aprobat firmware-ul?
• Este necesară o adresă de încărcare sau o hartă de memorie?
• Octeții de opțiune, siguranțele sau datele de configurare sunt încorporate sau separate?
• Ce interfață de programare este folosită?
• Accesul de programare necesar este disponibil pe placă?
• Cum este alimentată placa în timpul programării?
• Ce programator, proiect sau configurație aprobată se aplică?
• Sunt necesare date specifice-unității?
• Ce demonstrează că operația de programare a trecut?
• Este necesară testarea funcțională sau un alt control ulterior?
• Proiectul folosește firmware de testare, furnizare securizată sau un alt flux de lucru special?

Dacă aceste răspunsuri sunt clare, pachetul de programare în sine poate conține doar câteva fișiere.

Dacă nu sunt, adăugarea mai multor fișiere rezolvă rareori transferul.

 

Cum acceptă STHL programarea firmware-ului în cadrul producției PCBA

Shenzhen STHL Technology Co., Ltd. (STHL) acceptă programarea MCU, FPGA și EEPROM ca parte a proiectelor de asamblare PCB aplicabile. Programarea poate fi coordonată cu testarea funcțională și cu cerințele specifice de trasabilitate-proiectului, acolo unde este necesar.

Pentru o versiune individuală, analiza de programare poate acoperi imaginea lansată, dispozitivul țintă, revizuirea plăcii, accesul la programare, configurația necesară a dispozitivului, metoda de verificare și orice date specifice unității-furnizate de client.

Programatorul exact, dispozitivul sau cablul, cerințele de securitate, deținerea firmware-ului și înregistrările de producție necesare trebuie convenite pentru proiectul specific, mai degrabă decât presupuse dintr-o declarație generală de capacitate.

Concluzie

Cele mai importante cerințe de programare a firmware-ului PCBA nu sunt definite dacă clientul trimite un fișier HEX, BIN, ELF sau un alt fișier acceptat.

O predare gata de producție-ar trebui să permită echipei de producție să răspundă la patru întrebări de bază:

• Ce date ar trebui programate?
• Cărui dispozitiv și revizuire a plăcii îi aparține?
• Cum ar trebui să programeze producția și să o verifice?
• Ce trebuie să se întâmple înainte ca ansamblul PCB să treacă la următoarea etapă de producție?

Pentru o placă MCU simplă, aceste răspunsuri pot încadra pe o singură pagină. Un produs cu mai multe dispozitive programabile, date unice, mai multe variante de firmware sau cerințe de securitate va avea nevoie în mod natural de mai multe detalii.

Firmware-ul este pregătit pentru fabricație atunci când o echipă de producție calificată poate repeta procesul de programare aprobat din informațiile lansate, mai degrabă decât să se bazeze pe cunoștințele care există doar în capul dezvoltatorului.

Pentru o versiune care necesită programare firmware, includeți fișierele de programare disponibile și instrucțiunile cu BOM, fișierele Gerber, informații despre asamblare, cantitate și cerințe de testare atunci cândtrimiteți detaliile proiectului PCBA.

Pentru întrebări specifice de programare-, contactați STHL lainfo@pcba-china.com.