Pregled
Datoteka vdelane programske opreme je lahko popolnoma veljavna in še vedno ni pripravljena za proizvodnjo.
Za programiranje vdelane programske opreme na sklopu tiskanega vezja ekipa EMS potrebuje izdano sliko, natančno ciljno napravo, revizijo plošče, na katero se nanaša, vmesnik za programiranje, kateri koli zahtevani pomnilniški naslov ali konfiguracijo naprave in definiran način za preverjanje rezultata. Izdelki, ki zahtevajo tudi serijske številke, naslove MAC, vrednosti umerjanja ali varnostne poverilnice, potrebujejo dodatna navodila za ravnanje.
Uporabno preverjanje proizvodnje je preprosto:
Ali lahko tehnik, ki ni napisal firmware-a, pravilno programira ploščo iz izdanih navodil?
Če ne, je programska oprema morda dokončana z razvojnega vidika, predaja proizvodnje pa ne.
Postavite programsko izdajo na eno stran
Slika vdelane programske opreme je le en del predaje.
Za mnoge projekte je najbolj uporaben spremljevalni dokument kratek programski izdajni list, ki pove proizvodnji, kaj je bilo odobreno in kako naj se uporablja.
Ni pomembno, ali stranka to imenuje navodilo za programiranje, obvestilo o izdaji, navodilo za proizvodnjo ali navodilo za nadzorovano delo. Pomemben del je, da operaterju ni treba rekonstruirati nastavitev iz e-poštnih niti, starih razvojnih opomb in imen datotek.
Praktični izdajni list lahko vključuje:
|
Polje sprostitve |
Kaj potrebuje proizvodnja |
|
Izdaja vdelane programske opreme |
Natančna odobrena datoteka ali datoteke |
|
Revizija vdelane programske opreme |
Izdana različica programske opreme |
|
Ciljna naprava |
Natančna programabilna naprava |
|
Revizija plošče |
Odobrena revizija strojne opreme za vdelano programsko opremo |
|
Programski vmesnik |
SWD, JTAG, UART, USB DFU, SPI ali drug definiran vmesnik |
|
Dostop do programiranja |
Glava, priključek,-napeljava, dostopne preskusne točke ali druga metoda |
|
Spominska destinacija |
Začetni naslov ali območje pomnilnika, kjer je potrebno |
|
Konfiguracija naprave |
Opcijski bajti, konfiguracijske besede, varovalke, nastavitve zagona ali zaščite, kjer je primerno |
|
Nastavitev programiranja |
Potrjen programer, projekt, skript ali nastavitve, kjer je to potrebno |
|
Podatki-specifični za enoto |
Serijska številka, naslov MAC, vrednost umerjanja ali drugi podatki na-enoto, kjer je primerno |
|
Način preverjanja |
Kako produkcija potrjuje, da je programiranje uspešno |
|
Po-korak programiranja |
Preverjanje zagona, funkcionalno testiranje, označevanje, sledljivost ali drugo zahtevano dejanje |
Preprosta plošča MCU morda potrebuje le nekaj teh elementov. Izdelek z več programirljivimi napravami, več različicami vdelane programske opreme, edinstvenimi identifikatorji ali varnostnimi funkcijami bo potreboval več.
Izdajni list preprečuje inženirske odločitve iz rok operaterja. Ko plošča doseže programiranje, bi moralo biti odobrena slika, nastavitev in pravilo preverjanja že jasno.
Trije načini, kako lahko pravilna datoteka vdelane programske opreme še vedno ustavi proizvodnjo
Datoteka sama pogosto ni problem. Informacije okoli tega so.
BIN je pravilen, vendar nihče ni določil naslova
Neobdelana binarna datoteka vsebuje podatke, ki jih je treba programirati, vendar programerju sama po sebi ne pove, kam ti podatki spadajo.
To se razlikuje od formatov-naslovov, kot sta Intel HEX ali Motorola S-record.
Datoteka .bin je torej lahko popolnoma veljavna, medtem ko so produkcijska navodila še nepopolna. Če delovni tok programiranja zahteva začetni naslov ali območje pomnilnika, morajo te informacije priti od nekje drugje kot iz binarne datoteke.
Zato prejem vdelane programske opreme ni isto kot imeti uporabno programsko izdajo.
Vdelana programska oprema je pravilna, vendar pripada drugi reviziji plošče
Revizije vdelane in strojne opreme se pogosto nadzorujejo ločeno. To je običajno v redu, dokler sprememba strojne opreme ne vpliva na združljivost.
Razmislite o projektu z vdelano programsko opremo V1.6, Board Rev.B in Board Rev.C. Vsi trije so morda veljavni izdani elementi, vendar je bila vdelana programska oprema V1.6 morda odobrena samo za Rev.C.
Dve posamično pravilni reviziji lahko še vedno tvorita napačno proizvodno kombinacijo.
Izdaja programiranja mora identificirati veljavno revizijo plošče, kadar koli lahko sprememba strojne opreme vpliva na:
- dodelitev žebljičkov;
- vrste senzorjev;
- pomnilniške naprave;
- komunikacijski vmesniki;
- konfiguracija zagona;
- V/I preslikava;
- kalibracijsko obnašanje.
Ne bi smeli pričakovati, da bo ime datoteke vdelane programske opreme samo po sebi nosilo to odločitev.
Programer pravi PASS, vendar tabla še ni izdana
Zelena oznaka PASS na programatorju vam pove, da je korak programiranja izpolnil definirano pravilo preverjanja.
Ne pove vam, ali sestavljena plošča pravilno komunicira, bere svoje senzorje, preklaplja svoje izhode ali se pravilno obnaša pod obremenitvijo.
Plošča se lahko uspešno programira in ima še vedno napako pri sestavljanju, nepravilno konfiguracijo strojne opreme, komunikacijsko težavo, napako pri napajanju ali napako-na ravni aplikacije.
Tam začne funkcionalno testiranje opravljati drugačno nalogo.
Preverjanje programiranja potrdi operacijo programiranja. Funkcionalno testiranje preveri obnašanje programiranega sklopa.
Format datoteke je manj pomemben kot jasna metoda programiranja
HEX in BIN sta pogosta, vendar nobeden ni samodejno pravi odgovor za vsak izdelek.
Delovni tokovi proizvodnega programiranja lahko uporabljajo tudi:
- ELF ali sorodni izvršljivi formati;
- zapis Motorola S-;
- programske datoteke-specifične za prodajalca;
- konfiguracijski paketi-za napravo.
Neobdelani BIN na splošno potrebuje ločeno določen ciljni naslov. Formati, ki nosijo-naslov, lahko v datoteki prenesejo več teh informacij. Ali se uporablja ELF, HEX, BIN, S{3}}zapis ali drug format, je odvisno od ciljne naprave in odobrene nastavitve programiranja.
V proizvodnem prostoru je pravilo preprostejše:
Uporabite obliko, ki jo podpira odobrena programska nastavitev, in dokumentirajte vse, česar datoteka sama ne definira.
Če je obseg EMS omejen na programiranje odobrene proizvodne slike, izvorna koda običajno ni potrebna. Izvorna koda, projekti IDE in okolja gradnje postanejo pomembni, ko je prevajanje, odpravljanje napak, spreminjanje vdelane programske opreme ali ustvarjanje produkcijske-slike del dogovorjenega obsega.
Pošiljanje celotnega repozitorija še vedno ne pove produkciji, katera zgradba je odobrena.
Programiranje dostopa je tudi odločitev o strojni opremi
Za-sistemsko programiranje je programski paket le polovica namestitve.
Proizvodna postaja potrebuje tudi fizični in električni dostop do ciljne naprave.
Odvisno od izdelka je to lahko prek:
- SWD;
- JTAG;
- UART ali drug vmesnik zagonskega nalagalnika;
- USB DFU;
- SPI;
- namenski konektor za programiranje;
- vpenjanje-dostopne testne točke;
- drug vmesnik,-specifičen za napravo.
Navodilo za programiranje bo morda moralo definirati tudi stanje napajanja plošče, priključek ali testno-točko, zahtevano stanje zagona, adapter za programiranje, vedenje ponastavitve in pričakovano zaporedje brisanja/programiranja/preverjanja.
Te podrobnosti je najbolje razrešiti, preden sestavljene plošče dosežejo postajo za programiranje.
Nedostopnega signala SWD ni mogoče popraviti s pošiljanjem boljše datoteke HEX.
Pri izdelkih, ki so odvisni od dostopa do napeljave ali testnih točk programiranja, je pripravljenost na programiranje delno vprašanje DFT, ne le predaja programske opreme.
Revizijo vdelane programske opreme in revizijo plošče hranite skupaj
Datoteke z imenom latest.hex ali final_new_v2.bin so lahko popolnoma razumljive osebi, ki jih je ustvarila. So slabe kontrole proizvodnje.
Proizvodnja potrebuje zanesljiv način za razlikovanje odobrene sprostitve od:
- zastarela različica;
- inženirska zgradba;
- samo testna-slika;
- druga različica izdelka.
Odvisno od strankinega nadzornega-sistema dokumentov lahko izdana identiteta vključuje revizijo vdelane programske opreme, nadzorovano ime datoteke, datum izdaje, veljavno revizijo plošče, sklic na odobritev stranke, velikost datoteke ali kontrolno vsoto/zgoščeno vrednost.
Proizvodnja ne potrebuje enega univerzalnega poimenovanja ali sheme kontrolne vsote. Potrebuje zanesljiv način za razlikovanje izdane gradnje od vsega drugega v mapi.
To postane še toliko bolj pomembno, ko ena strojna platforma podpira več različic programske opreme. Plošče so lahko videti enake, medtem ko končni izdelki niso.
Ko programiranje vključuje-specifične podatke za enoto
Pri številnih izdelkih vsaka plošča prejme isto sliko vdelane programske opreme.
Tudi drugi izdelki potrebujejo-informacije, specifične za enoto, kot so:
- serijske številke;
- MAC naslovi;
- ID izdelkov;
- kalibracijski koeficienti;
- regionalna konfiguracija;
- nastavitve,-specifične za stranke;
- poverilnice naprave.
Na tej točki sta skupna vdelana programska oprema in podatki na-enoto dva različna toka podatkov.
Produkcija mora vedeti, od kod prihajajo edinstvene vrednosti, kje so zapisane, kako je vsaka vrednost povezana s pravilno fizično ploščo in kako se preprečijo podvojene dodelitve.
Eno podrobnost je enostavno spregledati: kdaj se edinstvena vrednost šteje za porabljeno?
Serijska številka ali naslov MAC se lahko šteje za uporabljenega, ko je dodeljen, ko je programiranje uspešno ali šele potem, ko enota opravi zahtevani preizkus. Za vsak izdelek ni enotnega pravila, vendar mora obstajati dogovorjeno pravilo pred začetkom gradnje.
Enako velja za propadle enote. Ekipa mora vedeti, ali je dodeljeno vrednost mogoče ponovno uporabiti, ali jo je treba umakniti ali ostane povezana z okvarjeno ploščo zaradi sledljivosti.
Prepustnica za programiranje ni prepustnica FCT
Preverjanje programiranja in funkcionalno testiranje se lahko zgodita blizu skupaj v proizvodnem toku, vendar odgovarjata na različna vprašanja.
Preverjanje programiranja
Preverjanje programiranja sprašuje:
Ali so bili predvideni podatki pravilno zapisani v skladu z odobreno metodo programiranja?
Odvisno od naprave in nastavitev lahko to vključuje programatorjevo funkcijo preverjanja, primerjavo povratnega branja, kjer je dovoljeno, CRC, preverjanje konfiguracije ali drugo odobreno metodo.
Funkcionalno testiranje
Funkcionalno testiranje sprašuje:
Ali napajani in programirani sklop PCB opravlja funkcije, ki jih zahteva izdelek?
Odvisno od projekta lahko to vključuje:
- vedenje-pri vklopu;
- komuniciranje;
- vhodno/izhodni odziv;
- senzorski vhod;
- izhod releja ali aktuatorja;
- poraba toka;
- pogoji delovanja,-ki jih določi stranka.
Programatorja, ki prikazuje PASS, ne bi smeli samodejno obravnavati kot dokaz, da je sklop PCB opravil FCT.
Za projekte, ki zahtevajo, da je nalaganje vdelane programske opreme usklajeno s-preverjanjem ravni plošče, STHLTestiranje in pregledzmogljivosti zagotavljajo ustrezno servisno pot.
Dve situaciji, ki potrebujeta dodatna navodila
Večina programskih opravil ne potrebuje podrobnega postopka zagotavljanja. Dve situaciji si zaslužita dodatno pozornost, ko se uporabljata.
Preizkusite vdelano programsko opremo in produkcijsko vdelano programsko opremo
Nekateri izdelki uporabljajo diagnostično vdelano programsko opremo med proizvodnjo in drugo izdajo vdelane programske opreme za pošiljanje.
Če je tako, mora produkcija vedeti, katera slika se uporablja na vsaki stopnji, kdaj se preskusna slika zamenja, kako se potrdi končna izdaja in ali je po tem potrebno še eno funkcionalno preverjanje.
V nasprotnem primeru lahko plošča opravi diagnostiko proizvodnje in še vedno zapusti proizvodnjo z nameščeno napačno vdelano programsko opremo.
Vsak izdelek ne potrebuje ločene preskusne vdelane programske opreme. Postopek mora slediti dejanskemu izdelku.
Varno zagotavljanje
Nekatere varnostne{0}}naprave zahtevajo podpisane ali šifrirane slike, varne-nastavitve zagona, konfiguracijo OTP/eFuse, ključe, potrdila ali druge nadzorovane podatke o zagotavljanju.
Ko veljajo te zahteve, se morata ponudnik OEM in EMS dogovoriti, kdo je lastnik občutljivih podatkov, za katere operacije je produkcija pooblaščena in kako se odobrijo nepreklicne nastavitve.
S temi elementi ne bi smeli ravnati kot z navadnimi prilogami vdelane programske opreme.
Kaj pa, če se vdelana programska oprema spremeni po začetku programiranja?
Novo sliko vdelane programske opreme lahko skoraj takoj postavite v skupno mapo.
Deske, ki so že v proizvodnem nadstropju, se z njim ne spreminjajo.
Če po začetku programiranja pride nova izdaja, potrebuje ekipa jasno razpoloženje za:
- enote, ki so že programirane s prejšnjo različico;
- že testirane enote;
- enote, ki čakajo na programiranje;
- ali je potrebno reprogramiranje;
- ali je prizadeto funkcionalno testiranje;
- ali je potrebno ponovno testiranje;
- kjer je meja revizije znotraj proizvodne serije.
Stopnja pregleda mora slediti spremembi.
Popravljen prikazni niz in sprememba vedenja-nadzora napajanja ne predstavljata enakega proizvodnega tveganja. Toda ne enega ne drugega ne bi smeli uvesti preprosto z zamenjavo datoteke in ukazom, naj se vrstica nadaljuje.
Tukaj nadzor različic preneha biti papirologija in postane nadzor proizvodnje.
Kratek pregled pred-produkcijo
Preden se programira prva proizvodna enota, bi morala biti kupec in ekipa EMS sposobna odgovoriti:
- Kakšna natančna slika ali slike so objavljene?
- Katera programabilna naprava sprejme vsako sliko?
- Za katero revizijo plošče je vdelana programska oprema odobrena?
- Ali je potreben naslov za nalaganje ali zemljevid pomnilnika?
- Ali so opcijski bajti, varovalke ali konfiguracijski podatki vdelani ali ločeni?
- Kateri programski vmesnik se uporablja?
- Ali je na plošči na voljo potreben dostop do programiranja?
- Kako se napaja plošča med programiranjem?
- Kateri programer, projekt ali odobrena nastavitev velja?
- Ali so potrebni-podatki za enoto?
- Kaj dokazuje, da je operacija programiranja uspela?
- Ali je pozneje potrebno funkcionalno testiranje ali drugo preverjanje?
- Ali projekt uporablja preskusno vdelano programsko opremo, varno zagotavljanje ali drug poseben potek dela?
Če so ti odgovori jasni, lahko sam programski paket vsebuje le nekaj datotek.
Če niso, dodajanje več datotek redko reši predajo.
Kako STHL podpira programiranje vdelane programske opreme znotraj proizvodnje PCBA
Shenzhen STHL Technology Co., Ltd. (STHL) podpira programiranje MCU, FPGA in EEPROM kot del ustreznih projektov sestavljanja PCB. Programiranje je mogoče uskladiti s funkcionalnim testiranjem in-specifičnimi projektnimi zahtevami glede sledljivosti, kjer je to potrebno.
Za posamezno zgradbo lahko pregled programiranja zajema izdano sliko, ciljno napravo, revizijo plošče, dostop do programiranja, zahtevano konfiguracijo naprave, metodo preverjanja in vse podatke,-specifične za enoto, ki jih zagotovi stranka.
Natančen programer, napeljava ali kabel, varnostne zahteve, lastništvo vdelane programske opreme in zahtevani proizvodni zapisi se morajo dogovoriti za določen projekt, namesto da bi jih predvidevali iz splošne izjave o zmogljivosti.
Zaključek
Najpomembnejše zahteve za programiranje vdelane programske opreme PCBA niso opredeljene glede na to, ali stranka pošlje HEX, BIN, ELF ali drugo podprto datoteko.
Predaja,-pripravljena na proizvodnjo, bi morala proizvodni skupini omogočiti odgovor na štiri osnovna vprašanja:
- Katere podatke je treba programirati?
- Kateri napravi in reviziji plošče pripada?
- Kako programirati proizvodnjo in jo preveriti?
- Kaj se mora zgoditi, preden se sklop PCB premakne na naslednji proizvodni korak?
Za preprosto ploščo MCU se lahko ti odgovori prilegajo eni strani. Izdelek z več programirljivimi napravami, edinstvenimi podatki, več različicami vdelane programske opreme ali varnostnimi zahtevami bo seveda potreboval več podrobnosti.
Vdelana programska oprema je pripravljena za proizvodnjo, ko lahko usposobljena produkcijska ekipa ponovi odobren proces programiranja na podlagi objavljenih informacij, namesto da se zanaša na znanje, ki obstaja le v glavi razvijalca.
Za gradnjo, ki zahteva programiranje vdelane programske opreme, vključite razpoložljive programske datoteke in navodila z BOM, datoteke Gerber, informacije o sestavu, količino in zahteve za testiranje, kooddajte podrobnosti o projektu PCBA.
Za vprašanja o-programiranju se obrnite na STHL nainfo@pcba-china.com.
