Какви файлове на фърмуера са необходими за програмиране на PCBA?

Преглед

Файлът на фърмуера може да бъде напълно валиден и все още да не е готов за производство.

За програмиране на фърмуер на модул на печатна платка, екипът на EMS се нуждае от издаденото изображение, точното целево устройство, ревизията на платката, към която се прилага, интерфейса за програмиране, всеки необходим адрес на паметта или конфигурация на устройството и дефиниран начин за проверка на резултата. Продукти, които също изискват серийни номера, MAC адреси, стойности за калибриране или идентификационни данни за сигурност, се нуждаят от допълнителни инструкции за работа.

Полезната производствена проверка е проста:

Може ли техник, който не е написал фърмуера, да програмира правилно платката от пуснатите инструкции?

Ако не, софтуерът може да бъде завършен от гледна точка на разработката, но предаването на производството не е.

Поставете изданието за програмиране на една страница

Изображението на фърмуера е само една част от предаването.

За много проекти най-полезният придружаващ документ е кратък лист за програмиране, който казва на производството какво е одобрено и как трябва да се използва.

Няма значение дали клиентът нарича това инструкция за програмиране, бележка за изданието, инструкция за производство или инструкция за контролирана работа. Важната част е, че операторът не трябва да реконструира настройката от имейл нишки, стари бележки за разработка и имена на файлове.

Практическият лист за освобождаване може да включва:

Една проста MCU платка може да се нуждае само от няколко от тези елементи. Продукт с няколко програмируеми устройства, множество варианти на фърмуер, уникални идентификатори или функции за сигурност ще се нуждае от повече.

Листът за освобождаване предпазва инженерните решения от ръцете на оператора. Докато платката достигне до програмиране, одобреното изображение, настройката и правилото за проверка вече трябва да са ясни.

Файловият формат има по-малко значение от ясния метод на програмиране

HEX и BIN са често срещани, но нито един от тях не е автоматично правилният отговор за всеки продукт.

Работните процеси за програмиране на производството могат също да използват:

• ELF или сродни изпълними формати;
• Motorola S-запис;
• програмни файлове-специфични за доставчика;
• специфични за устройството-пакети за конфигурация.

Суровият BIN обикновено се нуждае от отделно дефиниран адрес на местоназначение. Адресните-формати могат да носят повече от тази информация във файла. Дали се използва ELF, HEX, BIN, S-запис или друг формат зависи от целевото устройство и одобрената настройка за програмиране.

На производствения етаж правилото е по-просто:

Използвайте формат, поддържан от одобрената програмна настройка, и документирайте всичко, което самият файл не дефинира.

Ако обхватът на EMS е ограничен до програмиране на одобрен производствен образ, изходният код обикновено не е необходим. Изходният код, IDE проектите и средите за компилиране стават уместни, когато компилирането, отстраняването на грешки, модификацията на фърмуера или генерирането на производствено-изображение е част от договорения обхват.

Изпращането на цялото хранилище все още не казва на производството коя компилация е одобрена.

Програмирането на достъпа също е хардуерно решение

За вътрешно{0}}системно програмиране софтуерният пакет е само половината от настройката.

Производствената станция също се нуждае от физически и електрически достъп до целевото устройство.

В зависимост от продукта, това може да стане чрез:

• SWD;
• JTAG;
• UART или друг интерфейс на буутлоудъра;
• USB DFU;
• SPI;
• специален конектор за програмиране;
• приспособление-достъпни тестови точки;
• друг специфичен за{0}}устройство интерфейс.

Инструкцията за програмиране може също така да трябва да дефинира състоянието на захранване на платката, разводката на конектора или тестовата -точка, необходимото състояние на зареждане, адаптера за програмиране, поведението при нулиране и очакваната последователност за изтриване/програмиране/проверка.

Тези детайли се разрешават най-добре преди сглобените платки да достигнат до станцията за програмиране.

Недостъпен SWD сигнал не може да бъде коригиран чрез изпращане на по-добър HEX файл.

За продукти, които зависят от достъпа до приспособленията или тестовите точки за програмиране, готовността за програмиране е отчасти проблем с DFT, а не само софтуерно предаване.

 

Съхранявайте версията на фърмуера и версията на платката заедно

Файловете с имена latest.hex или final_new_v2.bin може да са напълно разбираеми за човека, който ги е създал. Те са лош производствен контрол.

Производството се нуждае от надежден начин за разграничаване на одобреното освобождаване от:

• остаряла версия;
• инженерна конструкция;
• изображение само за тест-;
• друг вариант на продукта.

В зависимост от системата за{0}}контрол на документа на клиента, освободената самоличност може да включва версия на фърмуера, контролирано име на файл, дата на пускане, приложима версия на платката, справка за одобрение от клиента, размер на файла или контролна сума/хеш.

Производството не се нуждае от едно универсално именуване или схема за контролна сума. Нуждае се от надежден начин да различи издадената компилация от всичко останало в папката.

Това става още по-важно, когато една хардуерна платформа поддържа няколко софтуерни варианта. Дъските може да изглеждат идентични, докато готовите продукти не са.

 

Когато програмирането включва-специфични данни за единица

За много продукти всяка платка получава едно и също изображение на фърмуера.

Други продукти също се нуждаят от-специфична информация за единица като:

• серийни номера;
• MAC адреси;
• идентификатори на продукти;
• коефициенти на калибриране;
• регионална конфигурация;
• специфични за клиента-настройки;
• идентификационни данни на устройството.

В този момент общият фърмуер и данните за-единица са два различни потока от данни.

Производството трябва да знае откъде идват уникалните стойности, къде са записани, как всяка стойност е свързана с правилната физическа платка и как се предотвратяват дублиращи се присвоявания.

Една подробност е лесна за пренебрегване: кога една уникална стойност се счита за консумирана?

Сериен номер или MAC адрес може да се считат за използвани, когато са присвоени, когато програмирането е успешно или само след като устройството премине необходимия тест. Няма едно правило за всеки продукт, но трябва да има съгласувано правило преди началото на изграждането.

Същото важи и за неуспешните единици. Екипът трябва да знае дали присвоената стойност може да се използва повторно, трябва да бъде оттеглена или остава свързана с неуспешната платка за проследимост.

 

Пропускът за програмиране не е пропуск за FCT

Проверката на програмирането и функционалното тестване може да се случват близо едно до друго в производствения поток, но отговарят на различни въпроси.

Проверка на програмирането

Проверката на програмирането пита:

Предназначените данни бяха ли записани правилно в съответствие с одобрения метод на програмиране?

В зависимост от устройството и настройката, това може да включва функция за проверка на програмиста, сравнение на обратно четене, когато е разрешено, CRC, проверка на конфигурацията или друг одобрен метод.

Функционално тестване

Функционалното тестване пита:

Изпълнява ли захранваният и програмиран комплект печатни платки функциите, изисквани от продукта?

В зависимост от проекта това може да включва:

• поведение при-захранване;
• комуникация;
• входно/изходна реакция;
• сензорен вход;
• релеен или задвижващ изход;
• ток теглене;
• дефинирани{0}}от клиента условия на работа.

Програматор, показващ PASS, не трябва автоматично да се третира като доказателство, че модулът на PCB е преминал FCT.

За проекти, които изискват зареждането на фърмуера да бъде координирано с валидиране-на нивото на платката, STHLТестване и инспекциявъзможностите осигуряват съответния сервизен път.

 

Две ситуации, които се нуждаят от допълнителни инструкции

Повечето работни места за програмиране не се нуждаят от сложен процес на осигуряване. Две ситуации заслужават допълнително внимание, когато се прилагат.

Тествайте фърмуера и производствения фърмуер

Някои продукти използват диагностичен фърмуер по време на производството и различно издание на фърмуера за доставка.

Ако е така, производството трябва да знае кое изображение се прилага на всеки етап, кога тестовото изображение се заменя, как се потвърждава окончателното издание и дали е необходима друга функционална проверка след това.

В противен случай платката може да премине производствена диагностика и пак да напусне производството с инсталиран грешен фърмуер.

Не всеки продукт се нуждае от отделен тестов фърмуер. Процесът трябва да следва действителния продукт.

Сигурно осигуряване

Някои устройства с активирана-защита изискват подписани или шифровани изображения, настройки за защитено-зареждане, OTP/eFuse конфигурация, ключове, сертификати или други контролирани данни за осигуряване.

Когато се прилагат тези изисквания, доставчикът на OEM и EMS трябва да се споразумеят кой притежава чувствителните данни, кои производствени операции е упълномощено да извършва и как се одобряват необратими настройки.

Тези елементи не трябва да се третират като обикновени прикачени файлове към фърмуера.

Какво става, ако фърмуерът се промени след стартиране на програмирането?

Ново изображение на фърмуера може да бъде поставено в споделена папка почти веднага.

Дъските, които вече са на производствения етаж, не се променят с него.

Ако пристигне нова версия след като програмирането е започнало, екипът се нуждае от ясно разположение за:

• единици, които вече са програмирани с по-ранната версия;
• вече тествани единици;
• единици, чакащи за програмиране;
• дали е необходимо препрограмиране;
• дали функционалното тестване е засегнато;
• дали е необходимо повторно тестване;
• където границата на ревизията се намира в производствената партида.

Нивото на преглед трябва да следва промяната.

Коригираният низ за показване и промяната в поведението-на управление на захранването не носят същия производствен риск. Но нито едно от двете не трябва да се въвежда просто чрез замяна на файл и казване на реда да продължи.

Това е мястото, където контролът на версиите престава да бъде документация и се превръща в производствен контрол.

 

Кратка пред{0}}производствена проверка

Преди да бъде програмирана първата производствена единица, купувачът и екипът на EMS трябва да могат да отговорят:

• Какво точно изображение или изображения се публикуват?
• Кое програмируемо устройство получава всяко изображение?
• За коя версия на платката е одобрен фърмуерът?
• Изисква ли се адрес за зареждане или карта на паметта?
• Байтове за опции, предпазители или данни за конфигурация вградени ли са или отделни?
• Кой програмен интерфейс се използва?
• Наличен ли е необходимият достъп за програмиране на платката?
• Как се захранва платката по време на програмиране?
• Кой програмист, проект или одобрена настройка се прилагат?
• Необходими ли са-специфични данни за единица?
• Какво доказва, че операцията по програмиране е преминала?
• Изисква ли се след това функционално тестване или друга проверка?
• Проектът използва ли тестов фърмуер, защитено осигуряване или друг специален работен процес?

Ако тези отговори са ясни, самият програмен пакет може да съдържа само няколко файла.

Ако не са, добавянето на още файлове рядко решава прехвърлянето.

 

Как STHL поддържа програмиране на фърмуер в рамките на производството на PCBA

Shenzhen STHL Technology Co., Ltd. (STHL) поддържа програмиране на MCU, FPGA и EEPROM като част от приложими проекти за монтаж на печатни платки. Програмирането може да се координира с функционално тестване и специфични за проекта-изисквания за проследяване, когато е необходимо.

За индивидуална компилация прегледът на програмирането може да обхваща издаденото изображение, целевото устройство, ревизията на платката, достъпа до програмиране, необходимата конфигурация на устройството, метода за потвърждение и всички специфични за модул-данни, предоставени от клиента.

Точният програматор, приспособление или кабел, изискванията за сигурност, собствеността на фърмуера и необходимите производствени записи трябва да бъдат договорени за конкретния проект, а не да се приемат от обща декларация за възможности.

Заключение

Най-важните изисквания за програмиране на фърмуера на PCBA не се определят от това дали клиентът изпраща HEX, BIN, ELF или друг поддържан файл.

Готовото за производство -предаване трябва да позволи на производствения екип да отговори на четири основни въпроса:

• Какви данни трябва да бъдат програмирани?
• Към кое устройство и ревизия на платка принадлежи?
• Как трябва да се програмира производството и да се провери?
• Какво трябва да се случи, преди монтажът на печатни платки да премине към следващата производствена стъпка?

За обикновена MCU платка тези отговори може да се поберат на една страница. Продукт с няколко програмируеми устройства, уникални данни, множество варианти на фърмуер или изисквания за сигурност естествено ще се нуждае от повече подробности.

Фърмуерът е готов за производство, когато квалифициран производствен екип може да повтори одобрения процес на програмиране от публикуваната информация, вместо да разчита на знания, които съществуват само в главата на разработчика.

За компилация, която изисква програмиране на фърмуер, включете наличните програмни файлове и инструкции с BOM, Gerber файлове, информация за сглобяване, количество и изисквания за тестване, когатоизпратете подробностите за вашия PCBA проект.

За-специфични въпроси относно програмирането се свържете със STHL наinfo@pcba-china.com.