Jaké soubory firmwaru jsou potřebné pro programování PCBA?

Přehled

Soubor firmwaru může být dokonale platný a přesto nemusí být připraven k výrobě.

Pro programování firmwaru na sestavě PCB potřebuje tým EMS uvolněný obrázek, přesné cílové zařízení, revizi desky, na kterou se vztahuje, programovací rozhraní, jakoukoli požadovanou adresu paměti nebo konfiguraci zařízení a definovaný způsob ověření výsledku. Produkty, které také vyžadují sériová čísla, MAC adresy, kalibrační hodnoty nebo bezpečnostní pověření, potřebují další pokyny pro manipulaci.

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

Dokáže technik, který nenapsal firmware desku správně naprogramovat z vydaného návodu?

Pokud ne, software může být dokončen z hlediska vývoje, ale předání výroby nikoli.

Umístěte vydání programování na jednu stránku

Obraz firmwaru je pouze jednou částí předávání.

Pro mnoho projektů je nejužitečnějším doprovodným dokumentem krátký programovací list, který říká, co bylo schváleno a jak by se to mělo používat.

Nezáleží na tom, zda to zákazník nazývá programovací instrukce, poznámka k verzi, výrobní instrukce nebo řízená pracovní instrukce. Důležité je, že operátor nemusí rekonstruovat nastavení z e-mailových vláken, starých poznámek k vývoji a názvů souborů.

Praktický uvolňovací list může obsahovat:

Jednoduchá deska MCU může potřebovat jen několik z těchto položek. Produkt s několika programovatelnými zařízeními, více variantami firmwaru, jedinečnými identifikátory nebo bezpečnostními funkcemi bude potřebovat více.

Uvolňovací list udržuje technická rozhodnutí mimo ruce operátora. Než deska dosáhne programování, schválený obrázek, nastavení a ověřovací pravidlo by již mělo být jasné.

Formát souboru záleží méně než jasná metoda programování

HEX a BIN jsou běžné, ale ani jedno není automaticky správná odpověď pro každý produkt.

Pracovní postupy produkčního programování mohou také používat:

• ELF nebo související spustitelné formáty;
• Motorola S-rekord;
• programové soubory-specifické pro dodavatele;
• konfigurační balíčky-pro konkrétní zařízení.

Nezpracovaný BIN obecně potřebuje samostatně definovanou cílovou adresu. Formáty-s adresou mohou v souboru nést více těchto informací. Zda se použije ELF, HEX, BIN, S-záznam nebo jiný formát, závisí na cílovém zařízení a schváleném nastavení programování.

Na úrovni výroby je pravidlo jednodušší:

Použijte formát podporovaný schváleným nastavením programování a zdokumentujte vše, co samotný soubor nedefinuje.

Pokud je rozsah EMS omezen na programování schváleného produkčního obrazu, zdrojový kód je obvykle zbytečný. Zdrojový kód, projekty IDE a prostředí sestav se stávají relevantními, když je součástí dohodnutého rozsahu kompilace, ladění, úprava firmwaru nebo generování produkčního obrazu-.

Odeslání celého úložiště stále neříká produkci, která stavba je schválena.

Programování přístupu je také hardwarové rozhodnutí

Pro in{0}}systémové programování je softwarový balíček pouze polovinou nastavení.

Produkční stanice také potřebuje fyzický a elektrický přístup k cílovému zařízení.

V závislosti na produktu to může být prostřednictvím:

• SWD;
• JTAG;
• UART nebo jiné rozhraní bootloaderu;
• USB DFU;
• SPI;
• vyhrazený programovací konektor;
• zařízení-dostupné testovací body;
• rozhraní pro jiné zařízení-.

Instrukce programování může také vyžadovat definování stavu napájení desky, konektoru nebo pinu testovacího-bodu, požadovaný stav spouštění, programovací adaptér, chování při resetování a očekávanou sekvenci vymazání/programování/ověření.

Tyto detaily je nejlépe vyřešit předtím, než se sestavené desky dostanou do programovací stanice.

Nepřístupný signál SWD nelze opravit odesláním lepšího HEX souboru.

U produktů, které jsou závislé na přístupu k zařízení nebo na programování testovacích bodů, je připravenost na programování částečně problémem DFT, nikoli pouze předáním softwaru.

 

Udržujte revize firmwaru a revize desky pohromadě

Soubory s názvem nejnovější.hex nebo final_new_v2.bin mohou být dokonale srozumitelné osobě, která je vytvořila. Jsou to špatné výrobní kontroly.

Výroba potřebuje spolehlivý způsob, jak odlišit schválené vydání od:

• zastaralá verze;
• inženýrská stavba;
• zkušební-obrázek;
• jiná varianta produktu.

V závislosti na systému řízení dokumentů- zákazníka může uvolněná identita zahrnovat revizi firmwaru, kontrolovaný název souboru, datum vydání, příslušnou revizi desky, odkaz na schválení zákazníka, velikost souboru nebo kontrolní součet/hash.

Výroba nepotřebuje jedno univerzální schéma pojmenování nebo kontrolního součtu. Potřebuje spolehlivý způsob, jak rozeznat vydané sestavení od všeho ostatního ve složce.

To se stává ještě důležitější, když jedna hardwarová platforma podporuje několik softwarových variant. Desky mohou vypadat identicky, zatímco hotové výrobky nejsou.

 

Když programování zahrnuje{0}}specifická data jednotky

U mnoha produktů dostává každá deska stejný obraz firmwaru.

Jiné produkty také potřebují informace specifické pro jednotku-, například:

• sériová čísla;
• MAC adresy;
• ID produktů;
• kalibrační koeficienty;
• regionální konfigurace;
• zákaznická-nastavení specifická;
• přihlašovací údaje zařízení.

V tomto okamžiku jsou společný firmware a data na{0}}jednotku dva různé datové toky.

Produkce by měla vědět, odkud jedinečné hodnoty pocházejí, kde jsou zapsány, jak je každá hodnota spojena se správnou fyzickou deskou a jak je zabráněno duplicitnímu přiřazení.

Jeden detail lze snadno přehlédnout: kdy je jedinečná hodnota považována za spotřebovanou?

Sériové číslo nebo MAC adresa mohou být považovány za použité, když jsou přiřazeny, když je programování úspěšné, nebo až poté, co jednotka projde požadovaným testem. Pro každý produkt neexistuje jediné pravidlo, ale před zahájením sestavení by mělo existovat dohodnuté pravidlo.

Totéž platí pro neúspěšné jednotky. Tým potřebuje vědět, zda může být přiřazená hodnota znovu použita, musí být vyřazena nebo zůstává propojena s chybnou tabulí kvůli sledovatelnosti.

 

Programovací průkaz není průkaz FCT

Ověření programování a funkční testování se mohou ve výrobním toku odehrávat blízko sebe, ale odpovídají na různé otázky.

Ověření programování

Ověření programování se ptá:

Byla zamýšlená data zapsána správně podle schválené metody programování?

V závislosti na zařízení a nastavení to může zahrnovat ověřovací funkci programátora, zpětné porovnání, je-li povoleno, CRC, ověření konfigurace nebo jinou schválenou metodu.

Funkční testování

Funkční testování se ptá:

Plní napájená a naprogramovaná sestava PCB funkce požadované produktem?

V závislosti na projektu to může zahrnovat:

• chování při zapnutí-;
• sdělení;
• vstupní/výstupní odezva;
• vstup senzoru;
• výstup relé nebo akčního členu;
• odběr proudu;
• provozní podmínky definované zákazníkem-.

Programátor zobrazující PASS by neměl být automaticky považován za důkaz, že sestava PCB prošla FCT.

U projektů, které vyžadují koordinaci načítání firmwaru s ověřením-úrovně desky, STHLTestování a inspekceschopnosti poskytují příslušnou servisní cestu.

 

Dvě situace, které vyžadují další pokyny

Většina programovacích úloh nepotřebuje komplikovaný proces zajišťování. Dvě situace si zasluhují zvláštní pozornost, když platí.

Testování firmwaru a produkčního firmwaru

Některé produkty používají diagnostický firmware během výroby a jiné vydání firmwaru pro přepravu.

Pokud ano, produkce potřebuje vědět, který obrázek se použije v každé fázi, kdy je testovací obrázek nahrazen, jak je potvrzeno konečné vydání a zda je následně vyžadována další kontrola funkčnosti.

V opačném případě může deska projít výrobní diagnostikou a přesto opustit výrobu s nainstalovaným nesprávným firmwarem.

Ne každý produkt potřebuje samostatný testovací firmware. Proces by měl sledovat skutečný produkt.

Zabezpečené poskytování

Některá zařízení s povoleným zabezpečením-vyžadují podepsané nebo šifrované obrázky, bezpečné{1}}nastavení spouštění, konfiguraci OTP/eFuse, klíče, certifikáty nebo jiná řízená zřizovací data.

Pokud platí tyto požadavky, měli by se poskytovatelé OEM a EMS dohodnout, kdo vlastní citlivá data, jaké operace je produkce oprávněna provádět a jak se schvalují nevratná nastavení.

S těmito položkami by se nemělo zacházet jako s běžnými přílohami firmwaru.

Co když se po zahájení programování změní firmware?

Nový obraz firmwaru lze téměř okamžitě umístit do sdílené složky.

Desky již na výrobní podlaze se s ním nemění.

Pokud nové vydání přijde po zahájení programování, tým potřebuje jasné dispozice pro:

• jednotky již naprogramované v dřívější verzi;
• již testované jednotky;
• jednotky čekající na programování;
• zda je nutné přeprogramování;
• zda je ovlivněno funkční testování;
• zda je vyžadováno opakované testování;
• kde hranice revize leží v rámci výrobní šarže.

Úroveň kontroly by měla následovat po změně.

Opravený zobrazovaný řetězec a změna chování-ovládání napájení nenesou stejné výrobní riziko. Ale ani jedno by nemělo být zavedeno jednoduše nahrazením souboru a příkazem řádku pokračovat.

To je místo, kde kontrola verzí přestává být papírováním a stává se řízením výroby.

 

Krátká před{0}}produkční kontrola

Před naprogramováním první výrobní jednotky by kupující a tým EMS měli být schopni odpovědět:

• Jaký přesný obrázek nebo obrázky jsou zveřejněny?
• Které programovatelné zařízení přijímá každý obrázek?
• Pro jakou revizi desky je firmware schválen?
• Je vyžadována adresa zatížení nebo mapa paměti?
• Jsou bajty voleb, pojistky nebo konfigurační data vloženy nebo odděleny?
• Jaké programovací rozhraní se používá?
• Je na desce k dispozici požadovaný přístup k programování?
• Jak je deska napájena během programování?
• Který programátor, projekt nebo schválené nastavení platí?
• Jsou vyžadována-specifická data jednotky?
• Co dokazuje, že operace programování proběhla úspěšně?
• Je následně vyžadováno funkční testování nebo jiná kontrola?
• Používá projekt testovací firmware, zabezpečené zřizování nebo jiný speciální pracovní postup?

Pokud jsou tyto odpovědi jasné, může samotný programový balíček obsahovat pouze několik souborů.

Pokud tomu tak není, přidání dalších souborů zřídka vyřeší předání.

 

Jak STHL podporuje programování firmwaru v rámci výroby PCBA

Shenzhen STHL Technology Co., Ltd. (STHL) podporuje programování MCU, FPGA a EEPROM jako součást použitelných projektů montáže PCB. Programování lze v případě potřeby koordinovat s funkčním testováním a projektovými-požadavky na sledovatelnost.

U jednotlivého sestavení může kontrola naprogramování zahrnovat uvolněný obraz, cílové zařízení, revizi desky, přístup k programování, požadovanou konfiguraci zařízení, metodu ověření a jakákoliv -specifická data dodaná zákazníkem.

Přesný programátor, zařízení nebo kabel, požadavky na zabezpečení, vlastnictví firmwaru a požadované záznamy o výrobě by měly být dohodnuty pro konkrétní projekt, nikoli převzaty z obecného prohlášení o způsobilosti.

Závěr

Nejdůležitější požadavky na programování firmwaru PCBA nejsou definovány tím, zda zákazník zašle HEX, BIN, ELF nebo jiný podporovaný soubor.

Předání-produkce by mělo výrobnímu týmu umožnit odpovědět na čtyři základní otázky:

• Jaká data by měla být naprogramována?
• Ke kterému zařízení a revizi desky patří?
• Jak by měl výrobní program a ověření?
• Co se musí stát, než se sestava DPS přesune k dalšímu výrobnímu kroku?

U jednoduché desky MCU se tyto odpovědi vejdou na jednu stránku. Produkt s několika programovatelnými zařízeními, jedinečnými daty, více variantami firmwaru nebo bezpečnostními požadavky bude přirozeně potřebovat více podrobností.

Firmware je připraven k výrobě, když kvalifikovaný produkční tým může zopakovat schválený proces programování z uvolněných informací, místo aby se spoléhal na znalosti, které existují pouze v hlavě vývojáře.

U sestavení, která vyžaduje naprogramování firmwaru, zahrňte dostupné programovací soubory a pokyny s kusovníkem, soubory Gerber, informacemi o sestavě, množstvím a požadavky na testování, kdyžodešlete podrobnosti o svém projektu PCBA.

S dotazy ohledně programování-kontaktujte STHL na adreseinfo@pcba-china.com.