Aké súbory firmvéru sú potrebné na programovanie PCBA?

Prehľad

Súbor firmvéru môže byť dokonale platný a stále nie je pripravený na výrobu.

Na programovanie firmvéru na zostave PCB potrebuje tím EMS uvoľnený obrázok, presné cieľové zariadenie, revíziu dosky, na ktorú sa vzťahuje, programovacie rozhranie, akúkoľvek požadovanú adresu pamäte alebo konfiguráciu zariadenia a definovaný spôsob overenia výsledku. Produkty, ktoré tiež vyžadujú sériové čísla, MAC adresy, kalibračné hodnoty alebo bezpečnostné poverenia, potrebujú ďalšie pokyny na manipuláciu.

Užitočná kontrola výroby je jednoduchá:

Dokáže technik, ktorý nenapísal firmware, správne naprogramovať dosku z vydaného návodu?

Ak nie, softvér môže byť dokončený z hľadiska vývoja, ale odovzdanie výroby nie.

Umiestnite vydanie programovania na jednu stranu

Obrázok firmvéru je len jednou časťou odovzdania.

Pre mnohé projekty je najužitočnejším sprievodným dokumentom krátky hárok s uvoľnením programovania, ktorý hovorí, čo bolo schválené a ako by sa to malo používať.

Nezáleží na tom, či to zákazník nazýva programovací pokyn, poznámka k uvoľneniu, výrobný pokyn alebo riadený pracovný pokyn. Dôležité je, že operátor nemusí rekonštruovať nastavenie z e-mailových vlákien, starých poznámok k vývoju a názvov súborov.

Praktický uvoľňovací list môže obsahovať:

Jednoduchá doska MCU môže potrebovať len niekoľko z týchto položiek. Produkt s niekoľkými programovateľnými zariadeniami, viacerými variantmi firmvéru, jedinečnými identifikátormi alebo bezpečnostnými funkciami bude potrebovať viac.

Uvoľňovací list chráni technické rozhodnutia mimo rúk operátora. Keď doska dosiahne programovanie, schválený obrázok, nastavenie a pravidlo overenia by už malo byť jasné.

Na formáte súboru záleží menej ako na jasnej metóde programovania

HEX a BIN sú bežné, ale ani jedno nie je automaticky správna odpoveď pre každý produkt.

Pracovné postupy produkčného programovania môžu využívať aj:

• ELF alebo súvisiace spustiteľné formáty;
• Motorola S-rekord;
• konkrétne programové súbory-dodávateľa;
• konfiguračné balíky-pre konkrétne zariadenie.

Neupravený BIN vo všeobecnosti potrebuje samostatne definovanú cieľovú adresu. Formáty-s adresami môžu v súbore obsahovať viac týchto informácií. Či sa použije ELF, HEX, BIN, S-záznam alebo iný formát, závisí od cieľového zariadenia a schváleného nastavenia programovania.

Na úrovni výroby je pravidlo jednoduchšie:

Použite formát podporovaný schváleným nastavením programovania a zdokumentujte všetko, čo samotný súbor nedefinuje.

Ak je rozsah EMS obmedzený na programovanie schváleného produkčného obrazu, zdrojový kód je zvyčajne nepotrebný. Zdrojový kód, projekty IDE a zostavovacie prostredia sa stávajú relevantnými, keď je súčasťou dohodnutého rozsahu kompilácia, ladenie, úprava firmvéru alebo produkčné{1}}obrázky.

Odoslanie celého úložiska stále nehovorí produkcii, ktorá stavba je schválená.

Prístup k programovaniu je tiež hardvérovým rozhodnutím

Pre in{0}}systémové programovanie predstavuje softvérový balík iba polovicu nastavenia.

Výrobná stanica tiež potrebuje fyzický a elektrický prístup k cieľovému zariadeniu.

V závislosti od produktu to môže byť:

• SWD;
• JTAG;
• UART alebo iné rozhranie zavádzača;
• USB DFU;
• SPI;
• vyhradený programovací konektor;
• upevniť-dostupné testovacie body;
• iné rozhranie{0}}špecifické pre zariadenie.

Inštrukcia programovania môže tiež vyžadovať zadefinovanie stavu napájania dosky, konektora alebo testovacieho{0}}bodu, požadovaný stav zavádzania, programovací adaptér, správanie pri resetovaní a očakávanú sekvenciu vymazania/programovania/overenia.

Tieto detaily je najlepšie vyriešiť skôr, než sa zostavené dosky dostanú do programovacej stanice.

Neprístupný signál SWD nemožno opraviť odoslaním lepšieho HEX súboru.

Pre produkty, ktoré závisia od prístupu k zariadeniu alebo od programovania testovacích bodov, je pripravenosť na programovanie čiastočne problémom DFT, nie iba odovzdaním softvéru.

 

Udržujte revíziu firmvéru a revíziu dosky spolu

Súbory s názvom last.hex alebo final_new_v2.bin môžu byť úplne zrozumiteľné pre osobu, ktorá ich vytvorila. Sú to zlé výrobné kontroly.

Výroba potrebuje spoľahlivý spôsob, ako rozlíšiť schválené uvoľnenie od:

• zastaraná verzia;
• inžinierska stavba;
• skúšobný-obrázok;
• iný variant produktu.

V závislosti od systému{0}} kontroly dokumentov zákazníka môže uvoľnená identita zahŕňať revíziu firmvéru, riadený názov súboru, dátum vydania, príslušnú revíziu dosky, referenciu na schválenie zákazníka, veľkosť súboru alebo kontrolný súčet/hash.

Výroba nepotrebuje jednu univerzálnu schému pomenovania alebo kontrolného súčtu. Potrebuje spoľahlivý spôsob, ako rozlíšiť vydanú zostavu od všetkého ostatného v priečinku.

To sa stáva ešte dôležitejším, keď jedna hardvérová platforma podporuje niekoľko softvérových variantov. Dosky môžu vyzerať identicky, zatiaľ čo hotové výrobky nie sú.

 

Keď programovanie zahŕňa{0}}údaje špecifické pre jednotku

Pri mnohých produktoch dostáva každá doska rovnaký obraz firmvéru.

Iné produkty tiež potrebujú{0}}špecifické informácie o jednotke, ako napríklad:

• sériové čísla;
• MAC adresy;
• ID produktov;
• kalibračné koeficienty;
• regionálna konfigurácia;
• zákaznícke-nastavenia špecifické;
• poverenia zariadenia.

V tomto bode sú spoločný firmvér a údaje na{0}}jednotku dva rôzne dátové toky.

Výroba by mala vedieť, odkiaľ jedinečné hodnoty pochádzajú, kde sú zapísané, ako je každá hodnota spojená so správnou fyzickou doskou a ako sa predchádza duplicitným priradeniam.

Jeden detail sa dá ľahko prehliadnuť: kedy sa jedinečná hodnota považuje za spotrebovanú?

Sériové číslo alebo MAC adresa sa môžu považovať za použité, keď sú priradené, keď je programovanie úspešné, alebo až potom, čo jednotka prejde požadovaným testom. Pre každý produkt neexistuje jediné pravidlo, ale pred začatím zostavovania by malo existovať dohodnuté pravidlo.

To isté platí pre neúspešné jednotky. Tím potrebuje vedieť, či je možné priradenú hodnotu znova použiť, či ju treba vyradiť alebo či zostáva prepojená s chybnou tabuľou kvôli vysledovateľnosti.

 

Programovací preukaz nie je preukaz FCT

Overenie programovania a funkčné testovanie môžu prebiehať blízko seba vo výrobnom toku, ale odpovedajú na rôzne otázky.

Overenie programovania

Overenie programovania sa pýta:

Boli zamýšľané údaje napísané správne podľa schválenej metódy programovania?

V závislosti od zariadenia a nastavenia to môže zahŕňať overovaciu funkciu programátora, spätné porovnanie, ak je to povolené, CRC, overenie konfigurácie alebo inú schválenú metódu.

Funkčné testovanie

Funkčné testovanie sa pýta:

Vykonáva napájaná a naprogramovaná zostava PCB funkcie požadované produktom?

V závislosti od projektu to môže zahŕňať:

• správanie pri{0}}napájaní;
• komunikácia;
• odozva vstupu/výstupu;
• vstup snímača;
• výstup relé alebo ovládača;
• odber prúdu;
• prevádzkové podmienky definované zákazníkom-.

Programátor zobrazujúci PASS by sa nemal automaticky považovať za dôkaz, že zostava PCB prešla FCT.

Pre projekty, ktoré vyžadujú načítanie firmvéru, aby bolo koordinované s overením{0}}úrovne dosky, STHLTestovanie a kontrolaschopnosti poskytujú príslušnú cestu služby.

 

Dve situácie, ktoré si vyžadujú ďalšie pokyny

Väčšina programovacích úloh nepotrebuje komplikovaný proces poskytovania. Dve situácie si zaslúžia osobitnú pozornosť, keď sa uplatňujú.

Testovanie firmvéru a produkčného firmvéru

Niektoré produkty používajú diagnostický firmvér počas výroby a iné vydanie firmvéru na prepravu.

Ak áno, produkcia potrebuje vedieť, ktorý obrázok sa použije v každej fáze, keď sa nahradí testovací obrázok, ako sa potvrdí konečné vydanie a či je potom potrebná ďalšia kontrola funkčnosti.

V opačnom prípade môže doska prejsť výrobnou diagnostikou a napriek tomu opustiť výrobu s nainštalovaným nesprávnym firmvérom.

Nie každý produkt potrebuje samostatný testovací firmvér. Proces by mal nasledovať skutočný produkt.

Zabezpečené poskytovanie

Niektoré zariadenia s -povoleným zabezpečením vyžadujú podpísané alebo šifrované obrázky, bezpečné{1}}nastavenia spustenia, konfiguráciu OTP/eFuse, kľúče, certifikáty alebo iné kontrolované údaje o poskytovaní.

Keď platia tieto požiadavky, poskytovateľ OEM a EMS by sa mali dohodnúť, kto je vlastníkom citlivých údajov, aké operácie má výroba oprávnená vykonávať a ako sa schvaľujú nezvratné nastavenia.

S týmito položkami by sa nemalo zaobchádzať ako s bežnými prílohami firmvéru.

Čo ak sa firmvér zmení po spustení programovania?

Nový obraz firmvéru je možné umiestniť do zdieľaného priečinka takmer okamžite.

Dosky už na výrobnej podlahe sa s ním nemenia.

Ak po spustení programovania príde nové vydanie, tím potrebuje jasné dispozície pre:

• jednotky už naprogramované staršou verziou;
• už testované jednotky;
• jednotky čakajúce na programovanie;
• či je potrebné preprogramovanie;
• či je ovplyvnené funkčné testovanie;
• či je potrebné opätovné testovanie;
• kde sa hranica revízie nachádza v rámci výrobnej šarže.

Úroveň kontroly by mala nasledovať po zmene.

Opravený zobrazovaný reťazec a zmena správania-ovládania napájania nepredstavujú rovnaké výrobné riziko. Ale ani jedno by sa nemalo zaviesť jednoducho nahradením súboru a prikázaním riadku pokračovať.

Toto je miesto, kde kontrola verzií prestáva byť papierovaním a stáva sa riadením výroby.

 

Krátka pred{0}}produkčná kontrola

Pred naprogramovaním prvej výrobnej jednotky by kupujúci a tím EMS mali byť schopní odpovedať:

• Aký presný obrázok alebo obrázky sú zverejnené?
• Ktoré programovateľné zariadenie prijíma každý obrázok?
• Pre akú revíziu dosky je schválený firmvér?
• Vyžaduje sa adresa načítania alebo mapa pamäte?
• Sú voliteľné bajty, poistky alebo konfiguračné údaje vložené alebo oddelené?
• Aké programovacie rozhranie sa používa?
• Je na doske dostupný požadovaný programovací prístup?
• Ako je doska napájaná počas programovania?
• Ktorý programátor, projekt alebo schválené nastavenie platí?
• Vyžadujú sa-údaje špecifické pre jednotku?
• Čo dokazuje, že operácia programovania prebehla?
• Vyžaduje sa funkčné testovanie alebo iná kontrola?
• Používa projekt testovací firmvér, zabezpečené poskytovanie alebo iný špeciálny pracovný postup?

Ak sú tieto odpovede jasné, samotný programovací balík môže obsahovať len niekoľko súborov.

Ak nie sú, pridanie ďalších súborov zriedka vyrieši odovzdanie.

 

Ako STHL podporuje programovanie firmvéru v rámci výroby PCBA

Shenzhen STHL Technology Co., Ltd. (STHL) podporuje programovanie MCU, FPGA a EEPROM ako súčasť použiteľných projektov montáže PCB. V prípade potreby je možné programovanie koordinovať s funkčným testovaním a špecifickými{3}}požiadavkami na sledovateľnosť projektu.

V prípade individuálnej zostavy sa kontrola programovania môže týkať uvoľneného obrazu, cieľového zariadenia, revízie dosky, prístupu k programovaniu, požadovanej konfigurácie zariadenia, spôsobu overenia a akýchkoľvek údajov špecifických pre jednotku-, ktoré poskytne zákazník.

Presný programátor, zariadenie alebo kábel, bezpečnostné požiadavky, vlastníctvo firmvéru a požadované výrobné záznamy by sa mali dohodnúť pre konkrétny projekt a nie predpokladať zo všeobecného vyhlásenia o spôsobilosti.

Záver

Najdôležitejšie požiadavky na programovanie firmvéru PCBA nie sú definované tým, či zákazník pošle HEX, BIN, ELF alebo iný podporovaný súbor.

Odovzdanie-pripravenej na výrobu by malo výrobnému tímu umožniť odpovedať na štyri základné otázky:

• Aké údaje treba naprogramovať?
• Do ktorého zariadenia a revízie dosky patrí?
• Ako by mal výrobný program naprogramovať a overiť?
• Čo sa musí stať, kým sa zostava DPS presunie do ďalšieho výrobného kroku?

Pre jednoduchú dosku MCU sa tieto odpovede zmestia na jednu stránku. Produkt s niekoľkými programovateľnými zariadeniami, jedinečnými údajmi, viacerými variantmi firmvéru alebo bezpečnostnými požiadavkami bude prirodzene potrebovať viac detailov.

Firmvér je pripravený na výrobu, keď kvalifikovaný produkčný tím môže zopakovať schválený proces programovania z uvoľnených informácií, namiesto toho, aby sa spoliehal na znalosti, ktoré existujú iba v hlave vývojára.

V prípade zostavy, ktorá vyžaduje programovanie firmvéru, zahrňte dostupné programovacie súbory a pokyny s kusovníkom, súbormi Gerber, informáciami o zostave, množstvom a požiadavkami na testovanie, keďodošlite podrobnosti o svojom projekte PCBA.

V prípade otázok týkajúcich sa programovania-kontaktujte STHL na adreseinfo@pcba-china.com.