Visió general
Un fitxer de microprogramari pot ser perfectament vàlid i encara no estar preparat per a la producció.
Per a la programació del microprogramari en un conjunt de PCB, l'equip EMS necessita la imatge publicada, el dispositiu de destinació exacte, la revisió de la placa a la qual s'aplica, la interfície de programació, qualsevol adreça de memòria o configuració del dispositiu necessària i una manera definida de verificar el resultat. Els productes que també requereixen números de sèrie, adreces MAC, valors de calibratge o credencials de seguretat necessiten instruccions de gestió addicionals.
Un control de producció útil és senzill:
Un tècnic que no va escriure el microprogramari pot programar la placa correctament a partir de les instruccions publicades?
Si no, el programari pot estar acabat des del punt de vista del desenvolupament, però el lliurament de fabricació no ho és.
Posa la versió de programació en una pàgina
La imatge del firmware és només una part del lliurament.
Per a molts projectes, el document complementari més útil és un full de llançament de programació breu que indica a la producció què s'ha aprovat i com s'ha d'utilitzar.
No importa si el client l'anomena instrucció de programació, nota de llançament, instrucció de fabricació o instrucció de treball controlat. La part important és que l'operador no ha de reconstruir la configuració a partir de fils de correu electrònic, notes de desenvolupament antigues i noms de fitxers.
Un full d'alliberament pràctic pot incloure:
|
Camp d'alliberament |
Què necessita la producció |
|
Alliberament de firmware |
Fitxer o fitxers aprovats exactes |
|
Revisió de firmware |
Versió de programari llançada |
|
Dispositiu objectiu |
Dispositiu programable exacte |
|
Revisió de la junta |
Revisió de maquinari aprovada per al firmware |
|
Interfície de programació |
SWD, JTAG, UART, USB DFU, SPI o una altra interfície definida |
|
Accés a la programació |
Capçalera, connector, punts de prova accessibles-dispositius o un altre mètode |
|
Destinació de la memòria |
Adreça d'inici o regió de memòria quan sigui necessari |
|
Configuració del dispositiu |
Bytes d'opció, paraules de configuració, fusibles, paràmetres d'arrencada o protecció si escau |
|
Configuració de programació |
Programador, projecte, script o configuració aprovats quan sigui necessari |
|
Dades específiques de la unitat- |
Número de sèrie, adreça MAC, valor de calibratge o altres dades per-unitat, si escau |
|
Mètode de verificació |
Com la producció confirma que la programació va passar |
|
Post-pas de programació |
Comprovació d'arrencada, proves funcionals, etiquetatge, traçabilitat o una altra acció necessària |
Una placa MCU senzilla pot necessitar només alguns d'aquests elements. Un producte amb diversos dispositius programables, múltiples variants de microprogramari, identificadors únics o funcions de seguretat necessitarà més.
El full d'alliberament manté les decisions d'enginyeria fora de les mans de l'operador. Quan el tauler arribi a la programació, la imatge aprovada, la configuració i la regla de verificació ja haurien d'estar clares.
Tres maneres en què un fitxer de firmware correcte encara pot aturar la producció
El fitxer en si no és sovint el problema. La informació al seu voltant és.
El BIN és correcte, però ningú no ha definit l'adreça
Un fitxer binari en brut conté les dades que s'han de programar, però de manera inherent no indica al programador on pertanyen aquestes dades.
Això és diferent dels formats de -adreces com ara Intel HEX o Motorola S-record.
Per tant, un fitxer .bin pot ser completament vàlid mentre la instrucció de producció encara estigui incompleta. Si el flux de treball de programació requereix una adreça d'inici o una regió de memòria, aquesta informació ha de provenir d'un lloc diferent del fitxer binari.
És per això que rebre el firmware no és el mateix que tenir una versió de programació utilitzable.
El firmware és correcte, però pertany a una revisió de la placa diferent
Les revisions de firmware i maquinari sovint es controlen per separat. Això sol estar bé fins que un canvi de maquinari afecta la compatibilitat.
Penseu en un projecte amb el firmware V1.6, Board Rev.B i Board Rev.C. És possible que els tres siguin articles publicats vàlids, però és possible que el firmware V1.6 només s'hagi aprovat per a Rev.C.
Dues revisions individualment correctes encara poden formar la combinació de producció incorrecta.
La versió de programació hauria d'identificar la revisió de la placa aplicable sempre que un canvi de maquinari pugui afectar:
- assignacions de pins;
- tipus de sensors;
- dispositius de memòria;
- interfícies de comunicació;
- configuració d'arrencada;
- mapeig d'E/S;
- comportament de calibratge.
No s'ha d'esperar que el nom del fitxer del microprogramari porti aquesta decisió per si mateix.
El programador diu APROBAT, però la Junta encara no s'ha alliberat
Una PASS verda al programador us indica que el pas de programació va complir la regla de verificació definida.
No us diu si la placa muntada es comunica correctament, llegeix els seus sensors, commuta les seves sortides o es comporta correctament sota càrrega.
Una placa pot programar correctament i encara tenir un defecte de muntatge, una configuració de maquinari incorrecta, un problema de comunicació, una fallada d'alimentació o una fallada{0}}a nivell d'aplicació.
Allà és on les proves funcionals comencen a fer una feina diferent.
La verificació de programació confirma l'operació de programació. La prova funcional comprova el comportament del conjunt programat.
El format de fitxer és menys important que un mètode de programació clar
HEX i BIN són comuns, però cap dels dos és automàticament la resposta correcta per a cada producte.
Els fluxos de treball de programació de producció també poden utilitzar:
- ELF o formats executables relacionats;
- Motorola S-record;
- fitxers de programació específics del proveïdor{0};
- dispositius-paquets de configuració específics.
Un BIN en brut necessita generalment una adreça de destinació definida per separat. Els formats d'adreça-poden portar més informació dins del fitxer. Si s'utilitza ELF, HEX, BIN, S-record o un altre format depèn del dispositiu de destinació i de la configuració de programació aprovada.
A la planta de producció, la regla és més senzilla:
Utilitzeu un format compatible amb la configuració de programació aprovada i documenteu qualsevol cosa que el fitxer no defineixi.
Si l'abast de l'EMS es limita a programar una imatge de producció aprovada, el codi font normalment no és necessari. El codi font, els projectes IDE i els entorns de compilació esdevenen rellevants quan la compilació, la depuració, la modificació del microprogramari o la generació d'imatges-forma part de l'abast acordat.
L'enviament de tot el repositori encara no indica a la producció quina construcció està aprovada.
L'accés a la programació també és una decisió de maquinari
Per a la programació del-sistema, el paquet de programari és només la meitat de la configuració.
L'estació de producció també necessita accés físic i elèctric al dispositiu objectiu.
Depenent del producte, això pot ser a través de:
- SWD;
- JTAG;
- UART o una altra interfície del carregador d'arrencada;
- USB DFU;
- SPI;
- un connector de programació dedicat;
- punts de prova accessibles-fixtures;
- una altra interfície-específica del dispositiu.
És possible que la instrucció de programació també hagi de definir l'estat d'alimentació de la placa, el connector o el punt{0}}de prova, l'estat d'arrencada necessari, l'adaptador de programació, el comportament de restabliment i la seqüència d'esborrat/programació/verificació esperada.
Aquests detalls es resolen millor abans que les plaques muntades arribin a l'estació de programació.
Un senyal SWD inaccessible no es pot solucionar enviant un fitxer HEX millor.
Per als productes que depenen de l'accés a l'aparell o dels punts de prova de programació, la preparació per a la programació és en part un problema de DFT, no només una transferència de programari.
Mantingueu junts la revisió del firmware i la revisió de la placa
Els fitxers anomenats latest.hex o final_new_v2.bin poden ser perfectament comprensibles per a la persona que els va crear. Són mals controls de producció.
La fabricació necessita una manera fiable de distingir el llançament aprovat de:
- una versió obsoleta;
- una construcció d'enginyeria;
- una imatge-només de prova;
- una altra variant del producte.
En funció del sistema de control de documents-del client, la identitat publicada pot incloure la revisió del microprogramari, el nom del fitxer controlat, la data de llançament, la revisió de la placa aplicable, la referència d'aprovació del client, la mida del fitxer o una suma de comprovació/hash.
La producció no necessita un esquema de denominació o suma de control universal. Necessita una manera fiable de distingir la compilació llançada de tota la resta de la carpeta.
Això esdevé encara més important quan una plataforma de maquinari admet diverses variants de programari. Els taulers poden semblar idèntics mentre que els productes acabats no ho són.
Quan la programació inclou dades específiques de la unitat-
Per a molts productes, cada placa rep la mateixa imatge de microprogramari.
Altres productes també necessiten informació específica de la unitat-com ara:
- números de sèrie;
- adreces MAC;
- identificadors de producte;
- coeficients de calibratge;
- configuració regional;
- configuració específica del client{0};
- credencials del dispositiu.
En aquest moment, el microprogramari comú i les dades per{0}}unitat són dos fluxos de dades diferents.
La producció ha de saber d'on provenen els valors únics, on s'escriuen, com s'associa cada valor amb el tauler físic correcte i com s'evita les assignacions duplicades.
Un detall és fàcil de passar per alt: quan es considera consumit un valor únic?
Es pot considerar que s'utilitza un número de sèrie o una adreça MAC quan s'assigna, quan la programació té èxit o només després que la unitat superi la prova requerida. No hi ha una regla única per a cada producte, però hi hauria d'haver-hi una norma acordada abans de començar la construcció.
El mateix s'aplica a les unitats fallides. L'equip ha de saber si un valor assignat es pot reutilitzar, s'ha de retirar o roman vinculat al tauler fallit per a la traçabilitat.
Un passi de programació no és un pas FCT
La verificació de programació i les proves funcionals poden passar molt juntes en el flux de fabricació, però responen a preguntes diferents.
Verificació de la programació
La verificació de programació demana:
Les dades previstes es van escriure correctament segons el mètode de programació aprovat?
Depenent del dispositiu i de la configuració, això pot implicar la funció de verificació d'un programador, comparació de lectura quan es permeti, CRC, verificació de configuració o un altre mètode aprovat.
Prova funcional
Les proves funcionals demanen:
El conjunt de PCB alimentat i programat realitza les funcions requerides pel producte?
Depenent del projecte, això pot incloure:
- comportament d'engegada{0};
- comunicació;
- resposta d'entrada/sortida;
- entrada del sensor;
- sortida de relé o actuador;
- el consum actual;
- condicions de funcionament-definides pel client.
Un programador que mostri PASS no s'ha de tractar automàticament com una prova que el conjunt de PCB ha superat FCT.
Per als projectes que requereixen que la càrrega del microprogramari estigui coordinada amb la validació del nivell-de la placa, STHLProva i inspecciócapacitats proporcionen la ruta de servei rellevant.
Dues situacions que necessiten instruccions addicionals
La majoria de treballs de programació no necessiten un procés de subministrament elaborat. Dues situacions mereixen una atenció addicional quan s'apliquen.
Prova el firmware i el firmware de producció
Alguns productes utilitzen firmware de diagnòstic durant la fabricació i una versió de firmware diferent per a l'enviament.
Si és així, la producció ha de saber quina imatge s'aplica a cada etapa, quan es substitueix la imatge de prova, com es confirma el llançament final i si es requereix una altra comprovació funcional després.
En cas contrari, una placa pot passar un diagnòstic de fabricació i encara deixar la producció amb el microprogramari incorrecte instal·lat.
No tots els productes necessiten un firmware de prova independent. El procés ha de seguir el producte real.
Aprovisionament segur
Alguns dispositius amb seguretat-demanen imatges signades o encriptades, configuració d'arrencada-segura, configuració OTP/eFuse, claus, certificats o altres dades de subministrament controlat.
Quan s'apliquen aquests requisits, l'OEM i el proveïdor d'EMS haurien d'acordar qui és el propietari de les dades sensibles, quines operacions està autoritzada a realitzar la producció i com s'aprova la configuració irreversible.
Aquests elements no s'han de manejar com fitxers adjunts de microprogramari normals.
Què passa si el firmware canvia després d'haver començat la programació?
Una imatge de microprogramari nova es pot col·locar en una carpeta compartida gairebé immediatament.
Els taulers que ja estan a la planta de producció no canvien amb això.
Si arriba una versió nova després d'haver començat la programació, l'equip necessita una disposició clara per:
- unitats ja programades amb la versió anterior;
- unitats ja provades;
- unitats en espera de programació;
- si és necessària la reprogramació;
- si les proves funcionals es veuen afectades;
- si cal tornar a provar;
- on el límit de revisió es troba dins del lot de producció.
El nivell de revisió ha de seguir el canvi.
Una cadena de visualització corregida i un canvi en el comportament del control{0}}de potència no comporten el mateix risc de fabricació. Però cap dels dos s'hauria d'introduir simplement substituint un fitxer i dient a la línia que continuï.
Aquí és on el control de versions deixa de ser paperassa i es converteix en control de producció.
Un breu control de pre-producció
Abans de programar la primera unitat de producció, el comprador i l'equip d'EMS haurien de poder respondre:
- Quina imatge o imatges exactes es publiquen?
- Quin dispositiu programable rep cada imatge?
- Per a quina revisió de la placa està aprovat el microprogramari?
- Cal una adreça de càrrega o un mapa de memòria?
- Els bytes d'opció, els fusibles o les dades de configuració estan incrustats o separats?
- Quina interfície de programació s'utilitza?
- Hi ha l'accés a la programació requerit disponible al tauler?
- Com s'alimenta la placa durant la programació?
- Quin programador, projecte o configuració aprovada s'aplica?
- Es requereixen dades específiques de la unitat-?
- Què demostra que l'operació de programació va passar?
- Es requereix una prova funcional o una altra comprovació posterior?
- El projecte utilitza firmware de prova, subministrament segur o un altre flux de treball especial?
Si aquestes respostes són clares, el propi paquet de programació pot contenir només uns quants fitxers.
Si no ho són, afegir més fitxers poques vegades resol el traspàs.
Com STHL admet la programació de firmware dins de la fabricació de PCBA
Shenzhen STHL Technology Co., Ltd. (STHL) admet la programació MCU, FPGA i EEPROM com a part dels projectes de muntatge de PCB aplicables. La programació es pot coordinar amb proves funcionals i requisits de traçabilitat específics del projecte-si cal.
Per a una compilació individual, la revisió de programació pot incloure la imatge publicada, el dispositiu de destinació, la revisió de la placa, l'accés a la programació, la configuració necessària del dispositiu, el mètode de verificació i qualsevol dada específica de la unitat-subministrada pel client.
El programador exacte, l'aparell o el cable, els requisits de seguretat, la propietat del microprogramari i els registres de producció necessaris s'han d'acordar per al projecte específic en lloc d'assumir-se a partir d'una declaració de capacitat general.
Conclusió
Els requisits de programació de microprogramari PCBA més importants no es defineixen segons si el client envia un fitxer HEX, BIN, ELF o un altre fitxer compatible.
Un lliurament-preparat per a la producció hauria de permetre que l'equip de fabricació respongui quatre preguntes bàsiques:
- Quines dades s'han de programar?
- A quina revisió del dispositiu i de la placa pertany?
- Com s'ha de programar i verificar la producció?
- Què ha de passar abans que el conjunt de PCB passi al següent pas de producció?
Per a una placa MCU senzilla, aquestes respostes poden cabre en una pàgina. Un producte amb diversos dispositius programables, dades úniques, múltiples variants de microprogramari o requisits de seguretat, naturalment, necessitarà més detalls.
El firmware està preparat per a la fabricació quan un equip de producció qualificat pot repetir el procés de programació aprovat a partir de la informació publicada, en lloc de confiar en el coneixement que només existeix al cap del desenvolupador.
Per a una compilació que requereixi programació de microprogramari, incloeu els fitxers de programació disponibles i les instruccions amb la BOM, els fitxers Gerber, la informació de muntatge, la quantitat i els requisits de prova quanenvia els detalls del teu projecte PCBA.
Per a preguntes específiques de programació-, poseu-vos en contacte amb STHL ainfo@pcba-china.com.
