Vilka firmware-filer behövs för PCBA-programmering?

Översikt

En firmwarefil kan vara helt giltig och fortfarande inte vara redo för produktion.

För programmering av firmware på en PCB-enhet behöver EMS-teamet den släppta bilden, den exakta målenheten, kortets revision den gäller, programmeringsgränssnittet, eventuell minnesadress eller enhetskonfiguration och ett definierat sätt att verifiera resultatet. Produkter som också kräver serienummer, MAC-adresser, kalibreringsvärden eller säkerhetsuppgifter behöver ytterligare hanteringsinstruktioner.

En användbar produktionskontroll är enkel:

Kan en tekniker som inte har skrivit fast programvaran programmera kortet korrekt från de släppta instruktionerna?

Om inte, kan programvaran vara färdig ur utvecklingssynpunkt, men tillverkningsöverlämningen är det inte.

Lägg programmeringsversionen på en sida

Firmwarebilden är bara en del av handoffen.

För många projekt är det mest användbara följedokumentet ett kort programversionsblad som berättar för produktionen vad som har godkänts och hur det ska användas.

Det spelar ingen roll om kunden kallar detta en programmeringsinstruktion, release note, tillverkningsinstruktion eller kontrollerad arbetsinstruktion. Den viktiga delen är att operatören inte behöver rekonstruera installationen från e-posttrådar, gamla utvecklingsanteckningar och filnamn.

Ett praktiskt releaseblad kan innehålla:

Ett enkelt MCU-kort behöver kanske bara ett fåtal av dessa artiklar. En produkt med flera programmerbara enheter, flera firmwarevarianter, unika identifierare eller säkerhetsfunktioner kommer att behöva mer.

Frigöringsbladet håller ingenjörsbeslut ur operatörens händer. När kortet når programmeringen bör den godkända bilden, inställningarna och verifieringsregeln redan vara klar.

Filformat spelar mindre roll än en tydlig programmeringsmetod

HEX och BIN är vanliga, men det är inte heller automatiskt det rätta svaret för varje produkt.

Arbetsflöden för produktionsprogrammering kan också använda:

• ELF eller relaterade körbara format;
• Motorola S-rekord;
• leverantörs-specifika programmeringsfiler;
• enhetsspecifika-konfigurationspaket.

En rå BIN behöver i allmänhet en separat definierad destinationsadress. Adress-bärande format kan innehålla mer av den informationen i filen. Om ELF, HEX, BIN, S-record eller annat format används beror på målenheten och den godkända programmeringsinställningen.

På produktionsgolvet är regeln enklare:

Använd ett format som stöds av den godkända programmeringsinställningen och dokumentera allt som filen själv inte definierar.

Om EMS-omfattningen är begränsad till att programmera en godkänd produktionsbild, är källkod vanligtvis onödig. Källkod, IDE-projekt och byggmiljöer blir relevanta när kompilering, felsökning, modifiering av fast programvara eller produktions-bildgenerering är en del av den överenskomna omfattningen.

Att skicka hela förvaret talar fortfarande inte om för produktionen vilken konstruktion som är godkänd.

Programmeringsåtkomst är också ett hårdvarubeslut

För i-systemprogrammering är programvarupaketet bara hälften av installationen.

Produktionsstationen behöver också fysisk och elektrisk åtkomst till målenheten.

Beroende på produkten kan det vara genom:

• SWD;
• JTAG;
• UART eller annat gränssnitt för bootloader;
• USB DFU;
• SPI;
• en dedikerad programmeringskontakt;
• fixtur-tillgängliga testpunkter;
• ett annat enhetsspecifikt-gränssnitt.

Programmeringsinstruktionen kan också behöva definiera kortets strömtillstånd, anslutnings- eller testpunkt-pinout, obligatoriskt startläge, programmeringsadapter, återställningsbeteende och den förväntade raderings-/programmerings-/verifieringssekvensen.

Dessa detaljer löses bäst innan sammansatta kort når programmeringsstationen.

En otillgänglig SWD-signal kan inte fixas genom att skicka en bättre HEX-fil.

För produkter som är beroende av fixturåtkomst eller programmering av testpunkter är programmeringsberedskap delvis ett DFT-problem, inte bara en mjukvaruhandoff.

 

Håll Firmware Revision och Board Revision tillsammans

Filer som heter latest.hex eller final_new_v2.bin kan vara fullt förståeliga för personen som skapade dem. De är dåliga produktionskontroller.

Tillverkning behöver ett tillförlitligt sätt att skilja den godkända utgåvan från:

• en föråldrad version;
• en ingenjörsbyggnad;
• en{0}}endast testbild;
• en annan produktvariant.

Beroende på kundens dokument-kontrollsystem kan den släppta identiteten inkludera firmwareversionen, kontrollerat filnamn, releasedatum, tillämplig styrelseversion, kundgodkännandereferens, filstorlek eller en kontrollsumma/hash.

Produktionen behöver inte ett universellt namn- eller kontrollsummaschema. Det behöver ett tillförlitligt sätt att skilja den släppta versionen från allt annat i mappen.

Detta blir ännu viktigare när en hårdvaruplattform stöder flera mjukvaruvarianter. Skivorna kan se identiska ut medan de färdiga produkterna inte är det.

 

När programmering inkluderar enhets-specifika data

För många produkter får varje kort samma firmwarebild.

Andra produkter behöver också enhetsspecifik-information som:

• serienummer;
• MAC-adresser;
• produkt-ID:n;
• kalibreringskoefficienter;
• regional konfiguration;
• kundspecifika-inställningar;
• enhetens autentiseringsuppgifter.

Vid den tidpunkten är den vanliga firmwaren och data per-enhet två olika dataflöden.

Produktionen ska veta var de unika värdena kommer ifrån, var de är skrivna, hur varje värde är associerat med rätt fysiska tavla och hur duplicerade uppdrag förhindras.

En detalj är lätt att förbise: när anses ett unikt värde vara förbrukat?

Ett serienummer eller MAC-adress kan anses användas när det tilldelas, när programmeringen lyckas eller först efter att enheten klarat det erforderliga testet. Det finns ingen enskild regel för varje produkt, men det bör finnas en överenskommen regel innan bygget startar.

Detsamma gäller för misslyckade enheter. Teamet måste veta om ett tilldelat värde kan återanvändas, måste avvecklas eller förbli kopplat till den misslyckade styrelsen för spårbarhet.

 

Ett programmeringspass är inte ett FCT-pass

Programmeringsverifiering och funktionstestning kan ske nära varandra i tillverkningsflödet, men de svarar på olika frågor.

Programmeringsverifiering

Programmeringsverifiering frågar:

Var de avsedda uppgifterna skrivna korrekt enligt den godkända programmeringsmetoden?

Beroende på enhet och inställning kan det innebära en programmerares verifieringsfunktion, jämförelse av återläsning där det är tillåtet, CRC, konfigurationsverifiering eller annan godkänd metod.

Funktionstestning

Funktionstestning frågar:

Utför den drivna och programmerade PCB-enheten de funktioner som produkten kräver?

Beroende på projektet kan detta inkludera:

• uppstartsbeteende-;
• kommunikation;
• input/output svar;
• sensoringång;
• relä- eller ställdonutgång;
• strömdragning;
• kunddefinierade-driftsvillkor.

En programmerare som visar PASS ska inte automatiskt behandlas som ett bevis på att PCB-enheten har klarat FCT.

För projekt som kräver laddning av firmware för att samordnas med validering på kort-nivå, STHL:sProvning och inspektionkapacitet ger den relevanta tjänstevägen.

 

Två situationer som kräver extra instruktioner

De flesta programmeringsjobb behöver inte en komplicerad provisioneringsprocess. Två situationer förtjänar extra uppmärksamhet när de gäller.

Testa firmware och produktionsfirmware

Vissa produkter använder diagnostisk firmware under tillverkningen och en annan firmwareversion för leverans.

Om så är fallet behöver produktionen veta vilken bild som gäller i varje steg, när testbilden byts ut, hur den slutliga releasen bekräftas och om ytterligare en funktionskontroll krävs i efterhand.

Annars kan ett kort passera en tillverkningsdiagnostik och ändå lämna produktionen med fel firmware installerad.

Inte varje produkt behöver separat testfirmware. Processen bör följa den faktiska produkten.

Säker provisionering

Vissa säkerhetsaktiverade-enheter kräver signerade eller krypterade bilder, säkra-startinställningar, OTP/eFuse-konfiguration, nycklar, certifikat eller annan kontrollerad administrationsdata.

När dessa krav gäller bör OEM- och EMS-leverantören komma överens om vem som äger den känsliga informationen, vilka operationer produktionen är auktoriserad att utföra och hur oåterkalleliga inställningar godkänns.

Dessa artiklar ska inte hanteras som vanliga fast programvara.

Vad händer om firmware ändras efter att programmeringen har startat?

En ny firmware-bild kan placeras i en delad mapp nästan omedelbart.

Skivorna som redan finns på produktionsgolvet förändras inte med det.

Om en ny release kommer efter att programmeringen har startat behöver teamet en tydlig disposition för:

• enheter som redan programmerats med den tidigare versionen;
• redan testade enheter;
• enheter som väntar på programmering;
• om omprogrammering krävs;
• huruvida funktionstestning påverkas;
• om testning krävs;
• där revisionsgränsen ligger inom produktionspartiet.

Granskningsnivån bör följa förändringen.

En korrigerad visningssträng och en ändring av strömkontroll-medför inte samma tillverkningsrisk. Men ingendera bör införas genom att bara ersätta en fil och säga till linjen att fortsätta.

Det är här versionskontroll slutar vara pappersarbete och blir produktionskontroll.

 

En kort för-produktionskontroll

Innan den första produktionsenheten programmeras bör köparen och EMS-teamet kunna svara:

• Vilken exakt bild eller vilka bilder släpps?
• Vilken programmerbar enhet tar emot varje bild?
• Vilken styrelseversion är den fasta programvaran godkänd för?
• Krävs en laddningsadress eller minneskarta?
• Är tillvalsbyte, säkringar eller konfigurationsdata inbäddade eller separata?
• Vilket programmeringsgränssnitt används?
• Finns den nödvändiga programmeringsåtkomsten tillgänglig på kortet?
• Hur drivs kortet under programmering?
• Vilken programmerare, projekt eller godkänd installation gäller?
• Krävs enhetsspecifik-data?
• Vad bevisar att programmeringsoperationen gick igenom?
• Krävs funktionstestning eller annan kontroll efteråt?
• Använder projektet testfirmware, säker provisionering eller något annat speciellt arbetsflöde?

Om dessa svar är tydliga kan själva programmeringspaketet bara innehålla ett fåtal filer.

Om de inte är det löser det sällan handoffen att lägga till fler filer.

 

Hur STHL stöder firmware-programmering inom PCBA-tillverkning

Shenzhen STHL Technology Co., Ltd. (STHL) stöder MCU-, FPGA- och EEPROM-programmering som en del av tillämpliga PCB-monteringsprojekt. Programmering kan koordineras med funktionstestning och projektspecifika-spårbarhetskrav där det behövs.

För en enskild version kan programmeringsgranskningen täcka den släppta bilden, målenheten, kortets revision, programmeringsåtkomst, nödvändig enhetskonfiguration, verifieringsmetod och eventuell enhetsspecifik-data som tillhandahålls av kunden.

Den exakta programmeraren, fixturen eller kabeln, säkerhetskraven, äganderätten till den fasta programvaran och nödvändiga produktionsposter bör överenskommas för det specifika projektet snarare än antas från en allmän kapacitetsförklaring.

Slutsats

De viktigaste PCBA-firmware-programmeringskraven definieras inte av om kunden skickar en HEX, BIN, ELF eller annan fil som stöds.

En produktionsklar-handoff bör låta tillverkningsteamet svara på fyra grundläggande frågor:

• Vilka data ska programmeras?
• Vilken enhet och kortrevision tillhör den?
• Hur ska produktionen programmeras och verifieras?
• Vad måste hända innan PCB-enheten går till nästa produktionssteg?

För ett enkelt MCU-kort kan dessa svar rymmas på en sida. En produkt med flera programmerbara enheter, unika data, flera firmwarevarianter eller säkerhetskrav kommer naturligtvis att behöva mer detaljer.

Firmware är redo för tillverkning när ett kvalificerat produktionsteam kan upprepa den godkända programmeringsprocessen från den släppta informationen, snarare än att förlita sig på kunskap som bara finns i utvecklarens huvud.

För en konstruktion som kräver programmering av firmware, inkludera tillgängliga programmeringsfiler och instruktioner med BOM, Gerber-filer, monteringsinformation, kvantitet och testkrav när duskicka in dina PCBA-projektdetaljer.

För programmeringsspecifika-frågor, kontakta STHL påinfo@pcba-china.com.