Milyen firmware-fájlokra van szükség a PCBA programozáshoz?

Áttekintés

A firmware fájl tökéletesen érvényes lehet, de még mindig nem áll készen a gyártásra.

A PCB-szerelvényen történő firmware programozáshoz az EMS csapatának szüksége van a kiadott képre, a pontos céleszközre, a kártya verziójára, amelyre vonatkozik, a programozói felületre, a szükséges memóriacímekre vagy eszközkonfigurációra, valamint az eredmény ellenőrzésének meghatározott módjára. A sorozatszámokat, MAC-címeket, kalibrációs értékeket vagy biztonsági hitelesítő adatokat is igénylő termékekhez további kezelési utasításokra van szükség.

A hasznos gyártásellenőrzés egyszerű:

Egy technikus, aki nem írta meg a firmware-t, megfelelően programozhatja a kártyát a kiadott utasításokból?

Ha nem, akkor a szoftver fejlesztési szempontból befejeződött, de a gyártási átadás nem.

Helyezze a programozási kiadást egy oldalra

A firmware kép csak egy része az átadásnak.

Számos projekt esetében a leghasznosabb kísérődokumentum egy rövid programozási adatlap, amely elmondja a gyártásnak, hogy mit hagytak jóvá, és hogyan kell azt használni.

Nem mindegy, hogy az ügyfél ezt programozási utasításnak, kiadási megjegyzésnek, gyártási utasításnak vagy ellenőrzött munkautasításnak nevezi. A lényeg az, hogy az operátornak nem kell e-mail szálakból, régi fejlesztési megjegyzésekből és fájlnevekből rekonstruálnia a beállítást.

A gyakorlati kiadási lap a következőket tartalmazhatja:

Egy egyszerű MCU kártyának csak néhány elemre van szüksége ezek közül. Több programozható eszközzel, több firmware-változattal, egyedi azonosítóval vagy biztonsági funkcióval rendelkező termékhez többre van szükség.

A kiadási lap távol tartja a mérnöki döntéseket a kezelő kezétől. Mire a tábla eléri a programozást, már világosnak kell lennie a jóváhagyott képnek, beállításnak és ellenőrzési szabálynak.

A fájlformátum kevésbé számít, mint az egyértelmű programozási módszer

A HEX és a BIN gyakori, de egyik sem jelenti automatikusan a megfelelő választ minden termékre.

A gyártási programozási munkafolyamatok a következőket is használhatják:

• ELF vagy kapcsolódó végrehajtható formátumok;
• Motorola S{0}}rekord;
• szállító-specifikus programozási fájlok;
• eszközspecifikus konfigurációs csomagok-.

A nyers BIN-nek általában külön meghatározott célcímre van szüksége. A cím{1}}hordozó formátumok több információt hordozhatnak a fájlban. Az, hogy ELF, HEX, BIN, S-rekordot vagy más formátumot használ, a céleszköztől és a jóváhagyott programozási beállításoktól függ.

A termelési szinten a szabály egyszerűbb:

Használjon a jóváhagyott programozási beállítás által támogatott formátumot, és dokumentálja mindazt, amit maga a fájl nem határoz meg.

Ha az EMS hatóköre egy jóváhagyott éles lemezkép programozására korlátozódik, a forráskód általában szükségtelen. A forráskód, az IDE-projektek és az építési környezetek akkor válnak relevánssá, ha a fordítás, hibakeresés, firmware-módosítás vagy éles{1}}képgenerálás a megállapodás hatálya alá tartozik.

A teljes lerakat elküldése továbbra sem jelzi a termelésnek, hogy melyik buildet hagyták jóvá.

A programozási hozzáférés szintén hardveres döntés

A rendszeren belüli-programozáshoz a szoftvercsomag csak a fele a beállításnak.

A gyártóállomásnak fizikai és elektromos hozzáférésre is szüksége van a céleszközhöz.

A terméktől függően ez történhet:

• SWD;
• JTAG;
• UART vagy más rendszerbetöltő interfész;
• USB DFU;
• SPI;
• dedikált programozási csatlakozó;
• fixture{0}}elérhető tesztpontok;
• egy másik eszköz{0}}specifikus interfész.

Előfordulhat, hogy a programozási utasításnak meg kell határoznia a kártya tápellátási állapotát, a csatlakozót vagy a teszt-pont kivezetését, a szükséges rendszerindítási állapotot, a programozási adaptert, a visszaállítási viselkedést és a várt törlési/programozási/ellenőrzési sorrendet.

Ezeket a részleteket a legjobb megoldani, mielőtt az összeszerelt táblák elérnék a programozó állomást.

A hozzáférhetetlen SWD jel nem javítható jobb HEX fájl küldésével.

Azon termékek esetében, amelyek a fixture hozzáféréstől vagy a programozási tesztpontoktól függenek, a programozási készenlét részben DFT-probléma, nem csupán szoftveres átadás.

 

Tartsa együtt a firmware-verziót és az alaplap-revíziót

A latest.hex vagy final_new_v2.bin nevű fájlok tökéletesen érthetőek lehetnek az őket létrehozó személy számára. Rossz a gyártásellenőrzés.

A gyártásnak megbízható módszerre van szüksége ahhoz, hogy megkülönböztesse a jóváhagyott kiadást:

• elavult verzió;
• mérnöki építmény;
• egy teszt{0}}kép;
• egy másik termékváltozat.

Az ügyfél dokumentum{0}}ellenőrző rendszerétől függően a kiadott identitás tartalmazhatja a firmware-verziót, a szabályozott fájlnevet, a kiadás dátumát, a vonatkozó tábla verzióját, az ügyfél jóváhagyási hivatkozását, a fájlméretet vagy az ellenőrző összeget/kivonatot.

A termeléshez nincs szükség egyetlen univerzális elnevezési vagy ellenőrző összeg sémára. Megbízható módszerre van szüksége ahhoz, hogy megkülönböztesse a kiadott buildet a mappában lévő összes többitől.

Ez még fontosabbá válik, ha egy hardverplatform több szoftverváltozatot is támogat. A táblák azonosnak tűnhetnek, míg a késztermékek nem.

 

Ha a programozás egység{0}}specifikus adatokat tartalmaz

Sok termék esetében minden kártya ugyanazt a firmware-képet kapja.

Más termékeknek is szükségük van egység-{0}}specifikus információkra, például:

• sorozatszámok;
• MAC-címek;
• termékazonosítók;
• kalibrációs együtthatók;
• regionális konfiguráció;
• ügyfél--specifikus beállítások;
• eszköz hitelesítő adatai.

Ekkor a közös firmware és az egységenkénti-adatok két különböző adatfolyam.

A gyártásnak tudnia kell, hogy az egyedi értékek honnan származnak, hova vannak írva, hogyan kapcsolódnak az egyes értékek a megfelelő fizikai táblához, és hogyan akadályozzák meg az ismétlődő hozzárendeléseket.

Egy részletet könnyű figyelmen kívül hagyni: mikor számít egy egyedi érték elfogyasztottnak?

A sorozatszám vagy MAC-cím használatának tekinthető, ha hozzá van rendelve, ha a programozás sikeres, vagy csak akkor, ha az egység átment a szükséges teszten. Nincs egységes szabály minden termékre, de az összeállítás megkezdése előtt meg kell határozni egy elfogadott szabályt.

Ugyanez vonatkozik a meghibásodott egységekre is. A csapatnak tudnia kell, hogy egy hozzárendelt érték újrafelhasználható-e, ki kell-e vonni, vagy a nyomon követhetőség érdekében továbbra is a meghibásodott táblához kapcsolódik.

 

A programozási bérlet nem FCT bérlet

A programozás ellenőrzése és a funkcionális tesztelés a gyártási folyamatban egymáshoz közel is megtörténhet, de különböző kérdésekre válaszolnak.

Programozás ellenőrzése

A programozás ellenőrzése a következőket kérdezi:

A tervezett adat helyesen lett megírva a jóváhagyott programozási módszer szerint?

Az eszköztől és a beállítástól függően ez magában foglalhat egy programozói ellenőrzési funkciót, visszaolvasási összehasonlítást, ahol megengedett, CRC-t, konfiguráció-ellenőrzést vagy más jóváhagyott módszert.

Funkcionális tesztelés

A funkcionális tesztelés a következőket kérdezi:

Az árammal ellátott és programozott NYÁK-szerelvény ellátja a termék által megkívánt funkciókat?

A projekttől függően ez a következőket foglalhatja magában:

• teljesítmény{0}}viselkedés;
• kommunikáció;
• bemeneti/kimeneti válasz;
• érzékelő bemenet;
• relé vagy működtető kimenet;
• aktuális lehívás;
• az ügyfelek-meghatározott működési feltételei.

A PASS-t megjelenítő programozót nem szabad automatikusan annak bizonyítékaként kezelni, hogy a PCB-szerelvény megfelelt az FCT-nek.

Azoknál a projekteknél, amelyeknél a firmware-betöltést a táblaszintű{0}}ellenőrzéssel, az STHL-lel kell összehangolniTesztelés és ellenőrzésképességek biztosítják a megfelelő szolgáltatási utat.

 

Két olyan helyzet, amely további utasításokat igényel

A legtöbb programozási feladat nem igényel bonyolult kiépítési folyamatot. Két helyzet érdemel különös figyelmet, amikor alkalmazzák.

Firmware és gyártási firmware tesztelése

Egyes termékek diagnosztikai firmware-t használnak a gyártás során, és egy másik firmware kiadást a szállításhoz.

Ha igen, a gyártásnak tudnia kell, hogy melyik kép vonatkozik az egyes szakaszokra, mikor cserélik ki a tesztképet, hogyan történik a végleges kiadás megerősítése, és hogy szükség van-e ezt követően újabb működési ellenőrzésre.

Ellenkező esetben egy tábla átmenhet a gyártási diagnosztikán, és továbbra is rossz firmware-rel távozhat a gyártásból.

Nem minden termékhez szükséges külön teszt firmware. A folyamatnak követnie kell a tényleges terméket.

Biztonságos kiépítés

Egyes biztonsági{0}}eszközökhöz aláírt vagy titkosított képek, biztonságos-indítási beállítások, OTP/eFuse konfiguráció, kulcsok, tanúsítványok vagy más ellenőrzött hozzáférési adatok szükségesek.

Amikor ezek a követelmények érvényesek, az OEM-nek és az EMS-szolgáltatónak meg kell állapodnia, hogy kié a bizalmas adatok, mely műveletek elvégzésére jogosult a termelés, és hogyan hagyják jóvá a visszafordíthatatlan beállításokat.

Ezeket az elemeket nem szabad úgy kezelni, mint a szokásos firmware-mellékleteket.

Mi a teendő, ha a firmware megváltozik a programozás megkezdése után?

Az új firmware-kép szinte azonnal elhelyezhető egy megosztott mappában.

A gyári szinten már lévő táblák nem változnak vele.

Ha egy új kiadás a programozás megkezdése után érkezik, a csapatnak egyértelmű beosztásra van szüksége:

• a korábbi verzióval már programozott egységek;
• már tesztelt egységek;
• programozásra váró egységek;
• szükség van-e átprogramozásra;
• hatással van-e a funkcionális tesztelésre;
• szükség van-e ismételt tesztelésre;
• ahol a felülvizsgálati határ a gyártási tételen belül van.

A felülvizsgálat szintjének követnie kell a változást.

A kijavított megjelenítési karakterlánc és a teljesítményszabályozási viselkedés megváltoztatása-nem jár ugyanazzal a gyártási kockázattal. De egyiket sem szabad úgy bevezetni, hogy lecserélünk egy fájlt, és azt mondjuk a sornak, hogy folytassuk.

Ez az a hely, ahol a verziókezelés megszűnik a papírmunka helyett, és gyártásirányítássá válik.

 

Rövid gyártás előtti{0}}ellenőrzés

Az első gyártóegység programozása előtt a vevőnek és az EMS-csapatnak tudnia kell válaszolni:

• Pontosan milyen képet vagy képeket adnak ki?
• Melyik programozható eszköz fogadja az egyes képeket?
• Melyik kártyaverzióhoz engedélyezett a firmware?
• Betöltési cím vagy memóriatérkép szükséges?
• Beágyazott vagy különálló opciós bájtok, biztosítékok vagy konfigurációs adatok?
• Melyik programozási felületet használják?
• A szükséges programozási hozzáférés elérhető a táblán?
• Hogyan működik a tábla a programozás során?
• Melyik programozó, projekt vagy jóváhagyott beállítás vonatkozik rá?
• Szükség van-e egység{0}}adatokra?
• Mi bizonyítja, hogy a programozási művelet sikeres volt?
• Szükséges-e funkcionális tesztelés vagy más ellenőrzés utólag?
• Használ a projekt teszt firmware-t, biztonságos kiépítést vagy más speciális munkafolyamatot?

Ha ezek a válaszok egyértelműek, akkor maga a programcsomag csak néhány fájlt tartalmazhat.

Ha nem, további fájlok hozzáadása ritkán oldja meg az átadást.

 

Hogyan támogatja az STHL a firmware programozást a PCBA gyártáson belül?

A Shenzhen STHL Technology Co., Ltd. (STHL) támogatja az MCU, FPGA és EEPROM programozást a vonatkozó PCB-összeállítási projektek részeként. A programozás koordinálható funkcionális teszteléssel és projektspecifikus nyomonkövetési követelményekkel, ahol szükséges.

Egyedi összeállítás esetén a programozási áttekintés kiterjedhet a kiadott képre, a céleszközre, a kártya verziójára, a programozási hozzáférésre, a szükséges eszközkonfigurációra, az ellenőrzési módszerre és az ügyfél által biztosított bármely egységspecifikus adatra.

A pontos programozót, szerelvényt vagy kábelt, a biztonsági követelményeket, a firmware tulajdonjogát és a szükséges gyártási rekordokat az adott projekthez kell egyeztetni, nem pedig általános képességnyilatkozatból feltételezni.

Következtetés

A legfontosabb PCBA firmware programozási követelményeket nem az határozza meg, hogy az ügyfél HEX, BIN, ELF vagy más támogatott fájlt küld-e.

A termelésre{0}}kész átadásnak lehetővé kell tennie a gyártó csapat számára, hogy négy alapvető kérdésre válaszoljon:

• Milyen adatokat kell programozni?
• Melyik eszköz és kártya verzióhoz tartozik?
• Hogyan kell a gyártást programozni és ellenőrizni?
• Minek kell történnie, mielőtt a PCB-szerelvény a következő gyártási lépésre lép?

Egy egyszerű MCU tábla esetén ezek a válaszok elférnek egy oldalon. A több programozható eszközzel, egyedi adatokkal, több firmware-változattal vagy biztonsági követelményekkel rendelkező termék esetében természetesen több részletre van szükség.

A firmware készen áll a gyártásra, ha egy képzett gyártócsapat meg tudja ismételni a jóváhagyott programozási folyamatot a kiadott információkból, ahelyett, hogy olyan tudásra hagyatkozna, amely csak a fejlesztő fejében létezik.

A firmware-programozást igénylő összeállítások esetén adja meg a rendelkezésre álló programozási fájlokat és utasításokat a BOM-hoz, a Gerber-fájlokhoz, az összeállítási információkhoz, a mennyiséghez és a tesztelési követelményekhez.küldje el a PCBA projekt részleteit.

Programozási{0}}specifikus kérdéseivel forduljon az STHL-hez a következő telefonszámoninfo@pcba-china.com.