Hvilke firmwarefiler er nødvendige for PCBA-programmering?

Oversigt

En firmwarefil kan være helt gyldig og stadig ikke være klar til produktion.

Til firmwareprogrammering på en PCB-samling har EMS-teamet brug for det frigivne billede, den nøjagtige målenhed, kortets revision, det gælder for, programmeringsgrænsefladen, enhver påkrævet hukommelsesadresse eller enhedskonfiguration og en defineret måde at verificere resultatet på. Produkter, der også kræver serienumre, MAC-adresser, kalibreringsværdier eller sikkerhedslegitimationsoplysninger, har brug for yderligere håndteringsinstruktioner.

Et nyttigt produktionstjek er enkelt:

Kan en tekniker, der ikke har skrevet firmwaren, programmere kortet korrekt ud fra de frigivne instruktioner?

Hvis ikke, kan softwaren være færdig fra et udviklingssynspunkt, men fremstillingsoverdragelsen er det ikke.

Sæt programmeringsudgivelsen på én side

Firmwarebilledet er kun en del af overdragelsen.

For mange projekter er det mest nyttige ledsagedokument et kort programmeringsudgivelsesark, der fortæller produktionen, hvad der er blevet godkendt, og hvordan det skal bruges.

Det er lige meget, om kunden kalder dette en programmeringsinstruktion, release note, fremstillingsinstruktion eller kontrolleret arbejdsinstruktion. Den vigtige del er, at operatøren ikke behøver at rekonstruere opsætningen fra e-mail-tråde, gamle udviklingsnotater og filnavne.

Et praktisk udgivelsesark kan omfatte:

Et simpelt MCU-kort behøver muligvis kun nogle få af disse elementer. Et produkt med flere programmerbare enheder, flere firmwarevarianter, unikke identifikatorer eller sikkerhedsfunktioner har brug for mere.

Frigivelsesarket holder tekniske beslutninger ude af operatørens hænder. På det tidspunkt, hvor bestyrelsen når programmeringen, burde det godkendte billede, opsætning og verifikationsregel allerede være klar.

Filformat betyder mindre end en klar programmeringsmetode

HEX og BIN er fælles, men heller ikke automatisk det rigtige svar for hvert produkt.

Produktionsprogrammeringsarbejdsgange kan også bruge:

• ELF eller relaterede eksekverbare formater;
• Motorola S-record;
• leverandør-specifikke programmeringsfiler;
• enheds-specifikke konfigurationspakker.

En rå BIN kræver generelt en separat defineret destinationsadresse. Adresse-bærende formater kan indeholde flere af disse oplysninger i filen. Hvorvidt der bruges ELF, HEX, BIN, S-record eller et andet format afhænger af målenheden og den godkendte programmeringsopsætning.

På produktionsgulvet er reglen enklere:

Brug et format, der understøttes af den godkendte programmeringsopsætning, og dokumenter alt, hvad filen selv ikke definerer.

Hvis EMS-omfanget er begrænset til at programmere et godkendt produktionsbillede, er kildekode normalt unødvendig. Kildekode, IDE-projekter og byggemiljøer bliver relevante, når kompilering, fejlretning, firmwareændring eller produktions-billedegenerering er en del af det aftalte omfang.

At sende hele depotet fortæller stadig ikke produktionen, hvilken build der er godkendt.

Programmeringsadgang er også en hardwarebeslutning

For i-systemprogrammering er softwarepakken kun halvdelen af ​​opsætningen.

Produktionsstationen har også brug for fysisk og elektrisk adgang til målenheden.

Afhængigt af produktet kan det være gennem:

• SWD;
• JTAG;
• UART eller en anden bootloader-grænseflade;
• USB DFU;
• SPI;
• et dedikeret programmeringsstik;
• fastgørelses-tilgængelige testpunkter;
• en anden enhedsspecifik-grænseflade.

Programmeringsinstruktionen skal muligvis også definere kortets strømtilstand, stik eller test-punkt-pinout, påkrævet opstartstilstand, programmeringsadapter, nulstillingsadfærd og den forventede sekvens for sletning/programmering/bekræftelse.

Disse detaljer løses bedst, før de samlede plader når programmeringsstationen.

Et utilgængeligt SWD-signal kan ikke rettes ved at sende en bedre HEX-fil.

For produkter, der er afhængige af armaturets adgang eller programmering af testpunkter, er programmeringsparathed delvist et DFT-problem, ikke kun en softwareoverdragelse.

 

Hold firmwarerevision og bestyrelsesrevision sammen

Filer med navnet latest.hex eller final_new_v2.bin kan være helt forståelige for den person, der har oprettet dem. De er dårlige produktionskontroller.

Fremstilling har brug for en pålidelig måde at skelne den godkendte udgivelse fra:

• en forældet version;
• en ingeniørbygning;
• et -kun testbillede;
• en anden produktvariant.

Afhængigt af kundens dokument-kontrolsystem kan den frigivne identitet omfatte firmwarerevisionen, kontrolleret filnavn, udgivelsesdato, gældende bestyrelsesrevision, kundegodkendelsesreference, filstørrelse eller en kontrolsum/hash.

Produktion behøver ikke én universel navngivning eller kontrolsum. Det har brug for en pålidelig måde at skelne den frigivne build fra alt andet i mappen.

Dette bliver endnu vigtigere, når én hardwareplatform understøtter flere softwarevarianter. Pladerne kan se identiske ud, mens de færdige produkter ikke er det.

 

Når programmering omfatter enheds-specifikke data

For mange produkter modtager hvert bord det samme firmwarebillede.

Andre produkter har også brug for enhedsspecifikke-oplysninger såsom:

• serienumre;
• MAC-adresser;
• produkt-id'er;
• kalibreringskoefficienter;
• regional konfiguration;
• kunde-specifikke indstillinger;
• enhedens legitimationsoplysninger.

På det tidspunkt er den fælles firmware og dataene pr.-enhed to forskellige datastrømme.

Produktionen skal vide, hvor de unikke værdier kommer fra, hvor de er skrevet, hvordan hver værdi er knyttet til den korrekte fysiske tavle, og hvordan duplikatopgaver forhindres.

En detalje er let at overse: Hvornår anses en unik værdi for at være forbrugt?

Et serienummer eller MAC-adresse kan betragtes som brugt, når det tildeles, når programmeringen lykkes, eller først efter at enheden har bestået den påkrævede test. Der er ingen enkelt regel for hvert produkt, men der bør være en aftalt regel, før byggeriet starter.

Det samme gælder for fejlslagne enheder. Teamet skal vide, om en tildelt værdi kan genbruges, skal trækkes tilbage eller forbliver knyttet til den fejlbehæftede tavle for sporbarhed.

 

Et programmeringspas er ikke et FCT-pas

Programmeringsbekræftelse og funktionstest kan ske tæt sammen i fremstillingsprocessen, men de besvarer forskellige spørgsmål.

Verifikation af programmering

Programmeringsbekræftelse spørger:

Blev de tilsigtede data skrevet korrekt i henhold til den godkendte programmeringsmetode?

Afhængigt af enheden og opsætningen kan det involvere en programmørs verifikationsfunktion, sammenligning med tilbagelæsning, hvor det er tilladt, CRC, konfigurationsverifikation eller en anden godkendt metode.

Funktionel test

Funktionel test spørger:

Udfører den strømforsynede og programmerede PCB-enhed de funktioner, der kræves af produktet?

Afhængigt af projektet kan dette omfatte:

• power-adfærd;
• meddelelse;
• input/output svar;
• sensor input;
• relæ- eller aktuatorudgang;
• nuværende træk;
• kunde-definerede driftsbetingelser.

En programmør, der viser PASS, bør ikke automatisk behandles som bevis på, at PCB-samlingen har bestået FCT.

For projekter, der kræver indlæsning af firmware for at blive koordineret med validering af tavle-niveau, STHL'sTest og inspektionkapaciteter giver den relevante servicevej.

 

To situationer, der kræver ekstra instruktioner

De fleste programmeringsopgaver kræver ikke en omfattende klargøringsproces. To situationer fortjener ekstra opmærksomhed, når de gælder.

Test firmware og produktionsfirmware

Nogle produkter bruger diagnostisk firmware under fremstillingen og en anden firmwareudgivelse til forsendelse.

Hvis det er tilfældet, skal produktionen vide, hvilket billede der gælder på hvert trin, når testbilledet udskiftes, hvordan den endelige udgivelse bekræftes, og om der efterfølgende er behov for en anden funktionskontrol.

Ellers kan et kort bestå en produktionsdiagnose og stadig forlade produktionen med den forkerte firmware installeret.

Ikke alle produkter har brug for separat testfirmware. Processen skal følge det faktiske produkt.

Sikker levering

Nogle sikkerhedsaktiverede-enheder kræver signerede eller krypterede billeder, sikre-opstartsindstillinger, OTP/eFuse-konfiguration, nøgler, certifikater eller andre kontrollerede klargøringsdata.

Når disse krav gælder, bør OEM- og EMS-udbyderen aftale, hvem der ejer de følsomme data, hvilke operationer produktionen er autoriseret til at udføre, og hvordan irreversible indstillinger godkendes.

Disse elementer bør ikke håndteres som almindelige firmware-vedhæftninger.

Hvad hvis firmwaren ændres efter programmering er startet?

Et nyt firmwarebillede kan placeres i en delt mappe næsten med det samme.

Brædderne, der allerede er på produktionsgulvet, ændrer sig ikke med det.

Hvis en ny udgivelse ankommer efter programmeringen er startet, har teamet brug for en klar disposition for:

• enheder, der allerede er programmeret med den tidligere version;
• enheder allerede testet;
• enheder, der venter på programmering;
• om omprogrammering er påkrævet;
• om funktionstestning er påvirket;
• om gentestning er påkrævet;
• hvor revisionsgrænsen ligger inden for produktionspartiet.

Revisionsniveauet bør følge ændringen.

En korrigeret visningsstreng og en ændring af magt-kontroladfærd indebærer ikke den samme produktionsrisiko. Men ingen af ​​dem bør introduceres blot ved at erstatte en fil og bede linjen om at fortsætte.

Det er her, versionskontrol holder op med at være papirarbejde og bliver produktionskontrol.

 

Et kort før-produktionstjek

Inden den første produktionsenhed programmeres, bør køberen og EMS-teamet være i stand til at svare:

• Hvilket nøjagtigt billede eller hvilke billeder frigives?
• Hvilken programmerbar enhed modtager hvert billede?
• Hvilken boardrevision er firmwaren godkendt til?
• Er en indlæsningsadresse eller et hukommelseskort påkrævet?
• Er option-bytes, sikringer eller konfigurationsdata indlejret eller adskilt?
• Hvilken programmeringsgrænseflade bruges?
• Er den nødvendige programmeringsadgang tilgængelig på tavlen?
• Hvordan får kortet strøm under programmering?
• Hvilken programmør, projekt eller godkendt opsætning gælder?
• Er der behov for enhedsspecifikke-data?
• Hvad beviser, at programmeringsoperationen bestod?
• Er funktionstest eller anden kontrol påkrævet efterfølgende?
• Bruger projektet testfirmware, sikker klargøring eller en anden speciel arbejdsgang?

Hvis disse svar er klare, kan selve programmeringspakken kun indeholde nogle få filer.

Hvis de ikke er det, løser tilføjelse af flere filer sjældent overdragelsen.

 

Hvordan STHL understøtter firmwareprogrammering inden for PCBA-produktion

Shenzhen STHL Technology Co., Ltd. (STHL) understøtter MCU-, FPGA- og EEPROM-programmering som en del af relevante PCB-samlingsprojekter. Programmering kan koordineres med funktionstest og projektspecifikke-sporbarhedskrav, hvor det er nødvendigt.

For en individuel build kan programmeringsgennemgangen dække det frigivne billede, målenhed, boardrevision, programmeringsadgang, påkrævet enhedskonfiguration, verifikationsmetode og alle enhedsspecifikke data leveret af kunden.

Den nøjagtige programmør, armatur eller kabel, sikkerhedskrav, firmware-ejerskab og krævede produktionsregistreringer bør aftales for det specifikke projekt i stedet for at antages fra en generel kapacitetserklæring.

Konklusion

De vigtigste PCBA-firmwareprogrammeringskrav er ikke defineret af, om kunden sender en HEX, BIN, ELF eller en anden understøttet fil.

En produktionsklar-overlevering bør lade produktionsteamet besvare fire grundlæggende spørgsmål:

• Hvilke data skal programmeres?
• Hvilken enheds- og kortrevision tilhører den?
• Hvordan skal produktionen programmeres og verificeres?
• Hvad skal der ske, før PCB-samlingen går videre til næste produktionstrin?

For et simpelt MCU-kort kan disse svar passe på én side. Et produkt med flere programmerbare enheder, unikke data, flere firmwarevarianter eller sikkerhedskrav vil naturligvis have brug for flere detaljer.

Firmware er klar til fremstilling, når et kvalificeret produktionsteam kan gentage den godkendte programmeringsproces fra den frigivne information, i stedet for at stole på viden, der kun eksisterer i udviklerens hoved.

For en build, der kræver firmwareprogrammering, skal du inkludere de tilgængelige programmeringsfiler og instruktioner med styklisten, Gerber-filerne, monteringsoplysninger, mængde og testkrav, når duindsend dine PCBA-projektoplysninger.

For programmeringsspecifikke-spørgsmål, kontakt STHL påinfo@pcba-china.com.