Pregled
Datoteka firmvera može biti savršeno valjana i još uvijek nije spremna za proizvodnju.
Za programiranje firmvera na PCB sklopu, EMS timu je potrebna objavljena slika, tačan ciljni uređaj, revizija ploče na koju se primjenjuje, programsko sučelje, bilo koja potrebna memorijska adresa ili konfiguracija uređaja i definiran način za provjeru rezultata. Proizvodi koji također zahtijevaju serijske brojeve, MAC adrese, vrijednosti kalibracije ili sigurnosne vjerodajnice trebaju dodatne upute za rukovanje.
Korisna provjera proizvodnje je jednostavna:
Može li tehničar koji nije napisao firmver ispravno programirati ploču iz objavljenih uputstava?
Ako nije, softver može biti završen sa razvojnog stanovišta, ali primopredaja proizvodnje nije.
Stavite Programsko izdanje na jednu stranicu
Slika firmvera je samo jedan dio primopredaje.
Za mnoge projekte, najkorisniji prateći dokument je kratka lista izdanja programiranja koja govori proizvodnji šta je odobreno i kako treba da se koristi.
Nije bitno da li kupac ovo naziva uputstvom za programiranje, napomenom o izdanju, uputstvom za proizvodnju ili uputstvom za kontrolisani rad. Važan dio je da operater ne mora rekonstruirati postavku iz e-mail niti, starih razvojnih bilješki i naziva datoteka.
Praktični list za oslobađanje može uključivati:
|
Release Field |
Šta je potrebno za proizvodnju |
|
Izdanje firmvera |
Tačno odobreni fajl ili fajlovi |
|
Revizija firmvera |
Objavljena verzija softvera |
|
Ciljni uređaj |
Tačan programibilni uređaj |
|
Revizija odbora |
Revizija hardvera odobrena za firmver |
|
Programski interfejs |
SWD, JTAG, UART, USB DFU, SPI ili neki drugi definisani interfejs |
|
Pristup programiranju |
Zaglavlje, konektor,{0}}pristupačne ispitne tačke ili druga metoda |
|
Memorijska destinacija |
Početna adresa ili memorijski region gdje je potrebno |
|
Konfiguracija uređaja |
Bajtovi opcija, konfiguracijske riječi, osigurači, postavke pokretanja ili zaštite gdje je primjenjivo |
|
Podešavanje programiranja |
Odobreni programer, projekt, skripta ili postavke gdje je potrebno |
|
Podaci{0}}specifični za jedinicu |
Serijski broj, MAC adresa, vrijednost kalibracije ili drugi podaci po{0}}jedinici gdje je primjenjivo |
|
Metoda verifikacije |
Kako proizvodnja potvrđuje da je programiranje prošlo |
|
Post{0}}korak programiranja |
Provjera pokretanja, funkcionalno testiranje, označavanje, sljedivost ili druga potrebna radnja |
Jednostavnoj MCU ploči možda treba samo nekoliko od ovih stavki. Proizvod s nekoliko programabilnih uređaja, više varijanti firmvera, jedinstvenim identifikatorima ili sigurnosnim funkcijama trebat će više.
List za oslobađanje drži inžinjerske odluke van ruku operatera. Dok ploča stigne do programiranja, odobrena slika, podešavanje i pravilo verifikacije bi već trebali biti jasni.
Tri načina da ispravna datoteka firmvera i dalje može zaustaviti proizvodnju
Sama datoteka često nije problem. Informacije oko toga su.
BIN je tačan, ali niko nije definisao adresu
Sirova binarna datoteka sadrži podatke koje treba programirati, ali sama po sebi ne govori programeru gdje ti podaci pripadaju.
To se razlikuje od formata-koji sadrže adresu kao što su Intel HEX ili Motorola S{1}}zapis.
.bin datoteka stoga može biti potpuno važeća dok je instrukcija za proizvodnju još nepotpuna. Ako radni tok programiranja zahtijeva početnu adresu ili memorijski region, te informacije moraju doći odnekud osim iz binarne datoteke.
Zbog toga primanje firmvera nije isto što i imati upotrebljivo programsko izdanje.
Firmver je ispravan, ali pripada drugoj reviziji ploče
Revizije firmvera i hardvera često se kontrolišu odvojeno. To je obično u redu sve dok promjena hardvera ne utječe na kompatibilnost.
Razmotrite projekat sa firmverom V1.6, Board Rev.B i Board Rev.C. Sva tri mogu biti važeće objavljene stavke, ali firmver V1.6 je možda odobren samo za Rev.C.
Dvije pojedinačno ispravne revizije još uvijek mogu formirati pogrešnu proizvodnu kombinaciju.
Programsko izdanje treba identificirati primjenjivu reviziju ploče kad god promjena hardvera može utjecati na:
- pin assignments;
- tipovi senzora;
- Memorijski uređaji;
- komunikacijska sučelja;
- konfiguracija pokretanja;
- I/O mapiranje;
- ponašanje kalibracije.
Ne treba očekivati da ime datoteke firmvera nosi tu odluku sam po sebi.
Programer kaže PASS, ali ploča još nije puštena
Zeleni PASS na programatoru govori vam da je korak programiranja ispunio definisano pravilo verifikacije.
Ne govori vam da li sklopljena ploča komunicira ispravno, čita svoje senzore, prebacuje svoje izlaze ili se ponaša ispravno pod opterećenjem.
Ploča može uspješno programirati i još uvijek imati defekt sklopa, pogrešnu konfiguraciju hardvera, problem u komunikaciji, kvar napajanja ili kvar na{0}}nivou aplikacije.
Tada funkcionalno testiranje počinje raditi drugačiji posao.
Verifikacija programiranja potvrđuje operaciju programiranja. Funkcionalno testiranje provjerava ponašanje programiranog sklopa.
Format datoteke je manje važan od jasne metode programiranja
HEX i BIN su uobičajeni, ali ni jedno ni drugo nije automatski pravi odgovor za svaki proizvod.
Radni tokovi proizvodnog programiranja također mogu koristiti:
- ELF ili srodni izvršni formati;
- Motorola S{0}}zapis;
- programske datoteke{0}}specifične za dobavljača;
- konfiguracijski paketi{0}}specifični za uređaj.
Neobrađeni BIN općenito treba posebno definiranu odredišnu adresu. Formati{1}}koji nose adresu mogu nositi više tih informacija unutar fajla. Da li se koristi ELF, HEX, BIN, S- zapis ili drugi format zavisi od ciljnog uređaja i odobrenog programskog podešavanja.
U proizvodnom pogonu pravilo je jednostavnije:
Koristite format koji podržava odobreno programsko podešavanje i dokumentujte sve što sama datoteka ne definiše.
Ako je opseg EMS ograničen na programiranje odobrene produkcijske slike, izvorni kod obično nije neophodan. Izvorni kod, IDE projekti i okruženja za izgradnju postaju relevantni kada je kompajliranje, otklanjanje grešaka, modifikacija firmvera ili proizvodnja{1}}proizvodne slike dio dogovorenog opsega.
Slanje cijelog spremišta još uvijek ne govori produkciji koja je verzija odobrena.
Pristup programiranju je također hardverska odluka
Za-sistemsko programiranje, softverski paket je samo polovina podešavanja.
Proizvodnoj stanici je također potreban fizički i električni pristup ciljnom uređaju.
Ovisno o proizvodu, to može biti kroz:
- SWD;
- JTAG;
- UART ili neko drugo sučelje bootloadera;
- USB DFU;
- SPI;
- namjenski konektor za programiranje;
- fiksiranje{0}}dostupne ispitne tačke;
- drugi uređaj{0}}specifičan interfejs.
Instrukcija za programiranje može također trebati definirati stanje napajanja ploče, pinout konektora ili test{0}}tačke, potrebno stanje pokretanja, programski adapter, ponašanje resetovanja i očekivani redoslijed brisanja/programiranja/verifikacije.
Ovi detalji se najbolje rješavaju prije nego što sastavljene ploče stignu do stanice za programiranje.
Nepristupačan SWD signal se ne može popraviti slanjem bolje HEX datoteke.
Za proizvode koji zavise od pristupa uređaju ili programiranju testnih tačaka, spremnost za programiranje je delimično DFT problem, a ne samo softverska primopredaja.
Držite reviziju firmvera i reviziju ploče zajedno
Datoteke pod nazivom latest.hex ili final_new_v2.bin mogu biti savršeno razumljive osobi koja ih je kreirala. Loše su kontrole proizvodnje.
Za proizvodnju je potreban pouzdan način za razlikovanje odobrenog izdanja od:
- zastarjela verzija;
- inženjerska zgrada;
- slika{0}}samo za testiranje;
- druga varijanta proizvoda.
Ovisno o sistemu kontrole{0}}korisničkog dokumenta, objavljeni identitet može uključivati reviziju firmvera, kontrolirani naziv fajla, datum izdavanja, primjenjivu reviziju ploče, referencu za odobrenje korisnika, veličinu datoteke ili kontrolni zbroj/heš.
Produkciji nije potrebna jedna univerzalna šema imenovanja ili kontrolne sume. Potreban je pouzdan način da razlikuje objavljenu verziju od svega ostalog u fascikli.
Ovo postaje još važnije kada jedna hardverska platforma podržava nekoliko varijanti softvera. Ploče mogu izgledati identične dok gotovi proizvodi nisu.
Kada programiranje uključuje podatke{0}}specifične jedinice
Za mnoge proizvode, svaka ploča dobija istu sliku firmvera.
Za druge proizvode također su potrebne informacije{0}}specifične za jedinicu kao što su:
- serijski brojevi;
- MAC adrese;
- ID proizvoda;
- koeficijenti kalibracije;
- regionalna konfiguracija;
- korisničke{0}}specifične postavke;
- vjerodajnice uređaja.
U tom trenutku, zajednički firmver i podaci po{0}}jedinici su dva različita toka podataka.
Produkcija treba da zna odakle dolaze jedinstvene vrednosti, gde su napisane, kako je svaka vrednost povezana sa ispravnom fizičkom pločom i kako se sprečavaju duplikata dodeljivanja.
Jedan detalj je lako previdjeti: kada se jedinstvena vrijednost smatra potrošenom?
Serijski broj ili MAC adresa može se smatrati korištenim kada je dodijeljen, kada programiranje uspije ili tek nakon što jedinica prođe traženi test. Ne postoji jedno pravilo za svaki proizvod, ali bi trebalo postojati dogovoreno pravilo prije početka izrade.
Isto vrijedi i za neispravne jedinice. Tim treba da zna da li se dodeljena vrednost može ponovo koristiti, mora li biti povučena ili ostaje povezana sa neuspelom tablom radi sledljivosti.
Propusnica za programiranje nije FCT propusnica
Verifikacija programiranja i funkcionalno testiranje mogu se odvijati blizu zajedno u toku proizvodnje, ali odgovaraju na različita pitanja.
Verifikacija programiranja
Programska verifikacija pita:
Da li su željeni podaci ispravno napisani prema odobrenoj metodi programiranja?
U zavisnosti od uređaja i podešavanja, to može uključivati programerovu funkciju verifikacije, poređenje povratnog čitanja gde je dozvoljeno, CRC, verifikaciju konfiguracije ili drugu odobrenu metodu.
Funkcionalno testiranje
Funkcionalno testiranje pita:
Da li napajani i programirani sklop PCB-a obavlja funkcije koje zahtijeva proizvod?
Ovisno o projektu, to može uključivati:
- power{0}}ponašanje;
- komunikacija;
- ulazno/izlazni odgovor;
- senzorski ulaz;
- izlaz releja ili aktuatora;
- trenutno izvlačenje;
- korisnički{0}}definisani uslovi rada.
Programer koji prikazuje PASS ne treba automatski biti tretiran kao dokaz da je sklop PCB prošao FCT.
Za projekte koji zahtijevaju da se učitavanje firmvera koordinira s provjerom -nivoa ploče, STHLTestiranje i inspekcijamogućnosti pružaju relevantnu putanju usluge.
Dvije situacije za koje su potrebna dodatna uputstva
Za većinu programskih poslova nije potreban razrađen proces obezbjeđivanja. Dvije situacije zaslužuju dodatnu pažnju kada se primjenjuju.
Testirajte firmver i proizvodni firmver
Neki proizvodi koriste dijagnostički firmver tokom proizvodnje i drugačiju verziju firmvera za isporuku.
Ako je tako, produkcija mora znati koja se slika primjenjuje u svakoj fazi, kada se probna slika zamijeni, kako je konačno izdanje potvrđeno i da li je nakon toga potrebna još jedna funkcionalna provjera.
U suprotnom, ploča može proći dijagnostiku proizvodnje i dalje napustiti proizvodnju s instaliranim pogrešnim firmverom.
Nije za svaki proizvod potreban poseban firmver za testiranje. Proces bi trebao slijediti stvarni proizvod.
Secure Provisioning
Neki sigurnosni{0}}uređaji zahtijevaju potpisane ili šifrirane slike, sigurne{1}}postavke za pokretanje, OTP/eFuse konfiguraciju, ključeve, certifikate ili druge kontrolirane podatke o obezbjeđivanju.
Kada se ovi zahtjevi primjenjuju, dobavljač OEM-a i EMS-a treba da se dogovore ko posjeduje osjetljive podatke, koje operacije je proizvodnja ovlaštena za obavljanje i kako se odobravaju nepovratna podešavanja.
Ovim stavkama se ne treba rukovati kao sa običnim prilozima za firmver.
Šta ako se firmver promijeni nakon što je programiranje počelo?
Nova slika firmvera može se skoro odmah staviti u zajednički folder.
Ploče koje se već nalaze u proizvodnom podu ne mijenjaju se s njim.
Ako novo izdanje stigne nakon što je programiranje počelo, timu je potrebna jasna dispozicija za:
- jedinice koje su već programirane sa ranijom verzijom;
- jedinice koje su već testirane;
- jedinice koje čekaju na programiranje;
- da li je potrebno reprogramiranje;
- da li je funkcionalno testiranje pogođeno;
- da li je potrebno ponovno testiranje;
- gdje se granica revizije nalazi unutar proizvodne serije.
Nivo pregleda treba da prati promjenu.
Ispravljeni niz prikaza i promjena ponašanja{0}}kontrole napajanja ne nose isti proizvodni rizik. Ali ni jedno ni drugo ne bi trebalo uvoditi jednostavno zamjenom datoteke i navođenjem linije da se nastavi.
Ovdje kontrola verzija prestaje biti papirologija i postaje kontrola proizvodnje.
Kratka pred{0}}proizvodna provjera
Prije nego što se programira prva proizvodna jedinica, kupac i EMS tim bi trebali biti u mogućnosti da odgovore:
- Koja tačna slika ili slike se objavljuju?
- Koji programabilni uređaj prima svaku sliku?
- Za koju reviziju ploče je odobren firmver?
- Da li je potrebna adresa učitavanja ili memorijska mapa?
- Da li su bajtovi opcija, osigurači ili konfiguracijski podaci ugrađeni ili odvojeni?
- Koji programski interfejs se koristi?
- Da li je potreban pristup programiranju dostupan na ploči?
- Kako se ploča napaja tokom programiranja?
- Koji programer, projekat ili odobrena postavka se primjenjuje?
- Da li su potrebni podaci{0}}specifični za jedinicu?
- Šta dokazuje da je operacija programiranja prošla?
- Da li je nakon toga potrebno funkcionalno testiranje ili neka druga provjera?
- Da li projekat koristi probni firmver, sigurno obezbjeđivanje ili neki drugi poseban tok posla?
Ako su ti odgovori jasni, sam programski paket može sadržavati samo nekoliko datoteka.
Ako nisu, dodavanje više datoteka rijetko rješava primopredaju.
Kako STHL podržava programiranje firmvera u proizvodnji PCBA
Shenzhen STHL Technology Co., Ltd. (STHL) podržava MCU, FPGA i EEPROM programiranje kao dio primjenjivih projekata montaže PCB-a. Programiranje se može uskladiti sa funkcionalnim testiranjem i zahtjevima za{3}}specifične sljedivosti projekta gdje je to potrebno.
Za pojedinačnu gradnju, pregled programiranja može obuhvatiti objavljenu sliku, ciljni uređaj, reviziju ploče, pristup programiranju, potrebnu konfiguraciju uređaja, metodu verifikacije i sve podatke{0}}specifične za jedinicu koje je dostavio kupac.
Tačan programator, uređaj ili kabl, sigurnosni zahtjevi, vlasništvo firmvera i potrebni zapisi o proizvodnji trebali bi biti dogovoreni za određeni projekat, a ne pretpostavljeni iz opšte izjave o mogućnostima.
Zaključak
Najvažniji zahtevi za programiranje PCBA firmvera nisu definisani time da li korisnik šalje HEX, BIN, ELF ili neku drugu podržanu datoteku.
Predaja{0}}spremna za proizvodnju trebala bi omogućiti proizvodnom timu da odgovori na četiri osnovna pitanja:
- Koje podatke treba programirati?
- Kojoj reviziji uređaja i ploče pripada?
- Kako treba programirati proizvodnju i to verificirati?
- Šta se mora dogoditi prije nego što sklop PCB-a pređe na sljedeći proizvodni korak?
Za jednostavnu MCU ploču, ti odgovori mogu stati na jednu stranicu. Proizvod s nekoliko programabilnih uređaja, jedinstvenim podacima, više varijanti firmvera ili sigurnosnim zahtjevima će naravno trebati više detalja.
Firmware je spreman za proizvodnju kada kvalifikovani proizvodni tim može ponoviti odobreni proces programiranja iz objavljenih informacija, umjesto da se oslanja na znanje koje postoji samo u glavi programera.
Za izradu koja zahteva programiranje firmvera, uključite dostupne programske datoteke i uputstva sa BOM-om, Gerber fajlovima, informacijama o sklapanju, količinom i zahtevima za testiranje kadadostavite detalje vašeg PCBA projekta.
Za pitanja{0}}specifična za programiranje, kontaktirajte STHL nainfo@pcba-china.com.
