Koje su datoteke firmvera potrebne za PCBA programiranje?

Pregled

Datoteka firmvera može biti savršeno valjana, a još uvijek nije spremna za proizvodnju.

Za programiranje firmvera na PCB sklopu, EMS tim treba objavljenu sliku, točan ciljni uređaj, reviziju ploče na koju se odnosi, sučelje za programiranje, bilo koju potrebnu memorijsku adresu ili konfiguraciju 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 firmware ispravno programirati ploču iz objavljenih uputa?

Ako nije, softver može biti dovršen sa stajališta razvoja, ali predaja proizvodnje nije.

Stavite programsko izdanje na jednu stranicu

Slika firmvera samo je jedan dio primopredaje.

Za mnoge projekte, najkorisniji popratni dokument je kratka programska verzija koja govori o tome što je odobreno i kako se to treba koristiti.

Nije važno naziva li kupac ovo uputama za programiranje, uputama za izdavanje, uputama za proizvodnju ili uputama za kontrolirani rad. Važan dio je da operater ne mora rekonstruirati postavke iz niti e-pošte, starih bilješki o razvoju i naziva datoteka.

Praktični list za izdavanje može uključivati:

Jednostavna MCU ploča može trebati samo nekoliko ovih stavki. Proizvod s nekoliko programibilnih uređaja, više varijanti firmvera, jedinstvenim identifikatorima ili sigurnosnim funkcijama trebat će više.

List za izdavanje čuva inženjerske odluke izvan ruku operatera. Dok ploča stigne do programiranja, odobrena slika, postava i pravilo provjere već bi trebali biti jasni.

Format datoteke manje je bitan od jasne metode programiranja

HEX i BIN su uobičajeni, ali nijedno nije automatski pravi odgovor za svaki proizvod.

Tijek rada proizvodnog programiranja također može koristiti:

• ELF ili srodni izvršni formati;
• Motorola S-ploča;
• programske datoteke-specifične za dobavljača;
• konfiguracijski paketi-specifični za uređaj.

Neobrađeni BIN općenito treba posebno definiranu odredišnu adresu. Formati-nosenja adrese mogu sadržavati više tih informacija unutar datoteke. Hoće li se koristiti ELF, HEX, BIN, S-zapis ili neki drugi format ovisi o ciljnom uređaju i odobrenoj postavci programiranja.

U proizvodnji, pravilo je jednostavnije:

Koristite format koji podržava odobreno programiranje i dokumentirajte sve što sama datoteka ne definira.

Ako je opseg EMS-a ograničen na programiranje odobrene proizvodne slike, izvorni kod obično nije potreban. Izvorni kod, IDE projekti i okruženja izgradnje postaju relevantni kada je kompajliranje, otklanjanje pogrešaka, modifikacija firmvera ili proizvodno-generiranje slika dio dogovorenog opsega.

Slanje cijelog repozitorija još uvijek ne govori produkciji koja je verzija odobrena.

Programiranje pristupa također je hardverska odluka

Za-programiranje sustava, softverski paket je samo polovica postavljanja.

Proizvodna stanica također treba fizički i električni pristup ciljnom uređaju.

Ovisno o proizvodu, to može biti putem:

• SWD;
• JTAG;
• UART ili drugo sučelje bootloadera;
• USB DFU;
• SPI;
• namjenski konektor za programiranje;
• učvršćenje-dostupne ispitne točke;
• drugo sučelje-specifično za uređaj.

Uputa za programiranje također može trebati definirati stanje napajanja ploče, pinout konektora ili ispitne-točke, potrebno stanje pokretanja, adapter za programiranje, ponašanje resetiranja i očekivani slijed brisanja/programiranja/potvrde.

Ove detalje najbolje je riješiti prije nego što sastavljene ploče dođu do stanice za programiranje.

Nedostupan SWD signal ne može se popraviti slanjem bolje HEX datoteke.

Za proizvode koji ovise o pristupu učvršćenju ili ispitnim točkama programiranja, spremnost programiranja djelomično je pitanje DFT-a, a ne samo prijenos softvera.

 

Držite zajedno reviziju firmvera i reviziju ploče

Datoteke pod nazivom latest.hex ili final_new_v2.bin mogu biti savršeno razumljive osobi koja ih je stvorila. Loše su kontrole proizvodnje.

Proizvodnja treba pouzdan način da razlikuje odobreno puštanje od:

• zastarjela verzija;
• inženjerska konstrukcija;
• slika samo-za testiranje;
• drugu varijantu proizvoda.

Ovisno o kupčevom-sustavu kontrole dokumenata, objavljeni identitet može uključivati ​​reviziju firmvera, kontrolirani naziv datoteke, datum izdavanja, primjenjivu reviziju ploče, referencu odobrenja korisnika, veličinu datoteke ili kontrolni zbroj/raspršivanje.

Proizvodnja ne treba jedno univerzalno imenovanje ili shemu kontrolne sume. Potreban je pouzdan način da se izdana verzija razlikuje od svega ostalog u mapi.

Ovo postaje još važnije kada jedna hardverska platforma podržava nekoliko softverskih inačica. Ploče mogu izgledati identično dok gotovi proizvodi nisu.

 

Kada programiranje uključuje-podatke specifične za jedinicu

Za mnoge proizvode svaka ploča dobiva istu sliku firmvera.

Ostali proizvodi također trebaju podatke o jedinici-kao što su:

• serijski brojevi;
• MAC adrese;
• ID proizvoda;
• kalibracijski koeficijenti;
• regionalna konfiguracija;
• korisničke-postavke;
• vjerodajnice uređaja.

U tom su trenutku zajednički firmver i podaci po-jedinici dva različita protoka podataka.

Proizvodnja bi trebala znati odakle dolaze jedinstvene vrijednosti, gdje su zapisane, kako je svaka vrijednost povezana s ispravnom fizičkom pločom i kako se sprječavaju duple dodjele.

Jedan detalj je lako previdjeti: kada se jedinstvena vrijednost smatra potrošenom?

Serijski broj ili MAC adresa mogu se smatrati upotrijebljenima kada su dodijeljeni, kada je programiranje uspješno ili tek nakon što jedinica prođe traženi test. Ne postoji jedno pravilo za svaki proizvod, ali mora postojati dogovoreno pravilo prije početka izrade.

Isto vrijedi i za neuspjele jedinice. Tim mora znati može li se dodijeljena vrijednost ponovno upotrijebiti, mora li se povući iz upotrebe ili ostaje povezana s pokvarenom pločom radi sljedivosti.

 

Programska propusnica nije FCT propusnica

Verifikacija programiranja i funkcionalno testiranje mogu se odvijati blizu jedno uz drugo u proizvodnom tijeku, ali odgovaraju na različita pitanja.

Provjera programiranja

Provjera programiranja pita:

Jesu li željeni podaci ispravno napisani u skladu s odobrenom metodom programiranja?

Ovisno o uređaju i postavkama, to može uključivati ​​programerovu funkciju provjere, povratnu usporedbu gdje je dopušteno, CRC, provjeru konfiguracije ili drugu odobrenu metodu.

Funkcionalno testiranje

Funkcionalno testiranje pita:

Obavlja li napajani i programirani PCB sklop funkcije koje zahtijeva proizvod?

Ovisno o projektu, to može uključivati:

• napajanje-ponašanje;
• komunikacija;
• ulazno/izlazni odziv;
• ulaz senzora;
• izlaz releja ili aktuatora;
• povlačenje struje;
• korisnički-definirani radni uvjeti.

Programator koji prikazuje PASS ne bi se trebao automatski smatrati dokazom da je PCB sklop prošao FCT.

Za projekte koji zahtijevaju koordinaciju učitavanja firmvera s validacijom-razine ploče, STHLIspitivanje i inspekcijamogućnosti pružaju relevantan servisni put.

 

Dvije situacije za koje su potrebne dodatne upute

Većina programerskih poslova ne zahtijeva razrađeni proces pružanja usluga. Dvije situacije zaslužuju dodatnu pozornost kada se primjenjuju.

Testirajte firmware i proizvodni firmware

Neki proizvodi koriste dijagnostički firmver tijekom proizvodnje i drugo izdanje firmvera za isporuku.

Ako je tako, proizvodnja mora znati koja se slika primjenjuje u svakoj fazi, kada se testna slika zamjenjuje, kako se potvrđuje konačno izdanje i je li nakon toga potrebna još jedna funkcionalna provjera.

U suprotnom, ploča može proći dijagnostiku proizvodnje i još uvijek napustiti proizvodnju s instaliranim pogrešnim firmverom.

Nije svakom proizvodu potreban poseban test firmware. Proces bi trebao slijediti stvarni proizvod.

Sigurno pružanje usluga

Neki sigurnosni{0}}uređaji zahtijevaju potpisane ili šifrirane slike, sigurnosne-postavke pokretanja, OTP/eFuse konfiguraciju, ključeve, certifikate ili druge kontrolirane podatke za pružanje.

Kada se ovi zahtjevi primjenjuju, OEM i EMS pružatelj trebao bi se dogovoriti tko je vlasnik osjetljivih podataka, koje operacije je proizvodnja ovlaštena izvoditi i kako se nepovratne postavke odobravaju.

Ovim se stavkama ne smije rukovati kao s običnim prilozima firmvera.

Što ako se firmver promijeni nakon što je programiranje počelo?

Nova slika firmvera može se smjestiti u zajedničku mapu gotovo odmah.

Ploče koje su već na proizvodnom podu ne mijenjaju se s njim.

Ako novo izdanje stigne nakon početka programiranja, tim treba jasnu dispoziciju za:

• jedinice koje su već programirane s ranijom verzijom;
• već testirane jedinice;
• jedinice koje čekaju programiranje;
• je li potrebno reprogramiranje;
• utječe li na funkcionalno testiranje;
• je li potrebno ponovno testiranje;
• gdje se granica revizije nalazi unutar proizvodne serije.

Razina pregleda trebala bi pratiti promjenu.

Ispravljeni prikazni niz i promjena ponašanja-kontrole napajanja ne nose isti proizvodni rizik. Ali ni jedno ni drugo ne treba uvoditi jednostavnom zamjenom datoteke i retkom da se nastavi.

Ovdje kontrola verzija prestaje biti papirologija i postaje kontrola proizvodnje.

 

Kratka pro-provjera proizvodnje

Prije nego što se programira prva proizvodna jedinica, kupac i EMS tim trebali bi moći odgovoriti:

• Koja se točno slika ili slike objavljuju?
• Koji programabilni uređaj prima svaku sliku?
• Za koju je reviziju ploče firmware odobren?
• Je li potrebna adresa za učitavanje ili memorijska karta?
• Jesu li opcijski bajtovi, osigurači ili konfiguracijski podaci ugrađeni ili odvojeni?
• Koje se programsko sučelje koristi?
• Je li potreban pristup programiranju dostupan na ploči?
• Kako se ploča napaja tijekom programiranja?
• Koji se programer, projekt ili odobreni postav primjenjuju?
• Jesu li-potrebni podaci specifični za jedinicu?
• Što dokazuje da je operacija programiranja prošla?
• Je li nakon toga potrebno funkcionalno testiranje ili druga provjera?
• Koristi li projekt testni firmware, sigurnu pripremu ili neki drugi poseban tijek rada?

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 unutar PCBA proizvodnje

Shenzhen STHL Technology Co., Ltd. (STHL) podržava MCU, FPGA i EEPROM programiranje kao dio primjenjivih projekata sastavljanja tiskanih ploča. Programiranje se može uskladiti s funkcionalnim testiranjem i-zahtjevima za sljedivost specifičnim za projekt, gdje je to potrebno.

Za pojedinačnu verziju, pregled programiranja može obuhvatiti objavljenu sliku, ciljni uređaj, reviziju ploče, pristup programiranju, potrebnu konfiguraciju uređaja, metodu verifikacije i sve-podatke specifične za jedinicu koje je dostavio korisnik.

Točan programator, uređaj ili kabel, sigurnosni zahtjevi, vlasništvo firmware-a i potrebni proizvodni zapisi trebaju biti dogovoreni za određeni projekt, a ne pretpostavljeni iz opće izjave o mogućnostima.

Zaključak

Najvažniji zahtjevi za programiranje firmvera PCBA nisu definirani šalju li klijenti HEX, BIN, ELF ili drugu podržanu datoteku.

Primopredaja-spremna za proizvodnju trebala bi proizvodnom timu omogućiti odgovor na četiri osnovna pitanja:

• Koje podatke treba programirati?
• Kojoj reviziji uređaja i ploče pripada?
• Kako treba programirati proizvodnju i verificirati je?
• Što se mora dogoditi prije nego što PCB sklop prijeđe na sljedeći proizvodni korak?

Za jednostavnu MCU ploču ti odgovori mogu stati na jednu stranicu. Proizvod s nekoliko programibilnih uređaja, jedinstvenim podacima, više varijanti firmvera ili sigurnosnim zahtjevima prirodno će trebati više detalja.

Firmware je spreman za proizvodnju kada kvalificirani proizvodni tim može ponoviti odobreni proces programiranja iz objavljenih informacija, umjesto da se oslanja na znanje koje postoji samo u glavi programera.

Za međugradnju koja zahtijeva programiranje firmvera, uključite dostupne programske datoteke i upute s BOM-om, Gerber datoteke, informacije o sklapanju, količinu i zahtjeve za testiranje kadapošaljite svoje podatke o PCBA projektu.

Za-pitanja vezana uz programiranje kontaktirajte STHL nainfo@pcba-china.com.