Які файли мікропрограми потрібні для програмування PCBA?

Огляд

Файл мікропрограми може бути абсолютно дійсним і все ще не готовим до виробництва.

Для програмування мікропрограми на друкованій платі команді EMS потрібен опублікований образ, точний цільовий пристрій, версія плати, до якої він застосовується, інтерфейс програмування, будь-яка необхідна адреса пам’яті чи конфігурація пристрою та визначений спосіб перевірки результату. Продукти, для яких також потрібні серійні номери, MAC-адреси, значення калібрування або облікові дані безпеки, потребують додаткових інструкцій щодо поводження.

Корисна перевірка виробництва проста:

Чи може технік, який не писав прошивку, правильно запрограмувати плату з випущеної інструкції?

Якщо ні, програмне забезпечення може бути закінчено з точки зору розробки, але передача виробництва – ні.

Розмістіть програмний випуск на одній сторінці

Образ мікропрограми є лише частиною передачі.

Для багатьох проектів найкориснішим супровідним документом є короткий аркуш випуску програм, який повідомляє виробництву, що було схвалено та як це слід використовувати.

Немає значення, чи клієнт називає це інструкцією з програмування, приміткою про випуск, інструкцією з виробництва чи інструкцією з контрольованої роботи. Важливим є те, що оператору не потрібно реконструювати налаштування з потоків електронної пошти, старих нотаток розробки та імен файлів.

Практичний аркуш випуску може містити:

Проста плата MCU може потребувати лише кількох із цих елементів. Продукту з декількома програмованими пристроями, кількома варіантами прошивки, унікальними ідентифікаторами або функціями безпеки знадобиться більше.

Аркуш випуску не дозволяє оператору приймати інженерні рішення. До моменту, коли плата досягне програмування, затверджене зображення, налаштування та правило перевірки вже мають бути зрозумілими.

Формат файлу має менше значення, ніж чіткий метод програмування

HEX і BIN є поширеними, але жоден з них автоматично не є правильною відповіддю для кожного продукту.

Робочі процеси виробничого програмування також можуть використовувати:

• ELF або схожі виконувані формати;
• Запис Motorola S-;
• файли програм-спеціального постачальника;
• пакети-спеціальної конфігурації пристрою.

Необроблений BIN зазвичай потребує окремо визначеної адреси призначення. Формати адрес-несучі можуть містити більше такої інформації у файлі. Використання запису ELF, HEX, BIN, S{3}}або іншого формату залежить від цільового пристрою та затверджених налаштувань програмування.

На виробництві правило простіше:

Використовуйте формат, який підтримується схваленою системою програмування, і документуйте все, що не визначено самим файлом.

Якщо обсяг EMS обмежується програмуванням затвердженого виробничого образу, вихідний код зазвичай непотрібний. Вихідний код, проекти IDE та середовища збирання стають актуальними, коли компіляція, налагодження, модифікація вбудованого програмного забезпечення або генерація-образу виробництва є частиною узгодженого обсягу.

Надсилання всього сховища все ще не повідомляє продакшн, яка збірка схвалена.

Програмування доступу також є апаратним рішенням

Для-системного програмування пакет програмного забезпечення становить лише половину налаштування.

Виробнича станція також потребує фізичного та електричного доступу до цільового пристрою.

Залежно від продукту це може відбуватися через:

• SWD;
• JTAG;
• UART або інший інтерфейс завантажувача;
• USB DFU;
• SPI;
• спеціальний роз'єм програмування;
• пристосування-доступні контрольні точки;
• інтерфейс-для іншого пристрою.

В інструкції з програмування також може знадобитися визначити стан живлення плати, розводку роз’єму або тестової -точки, необхідний стан завантаження, адаптер програмування, поведінку скидання та очікувану послідовність видалення/програмування/перевірки.

Ці деталі найкраще вирішити до того, як зібрані плати досягнуть станції програмування.

Недоступний сигнал SWD неможливо виправити, надіславши кращий файл HEX.

Для продуктів, які залежать від доступу до кріплення або тестових точок програмування, готовність до програмування є частково проблемою DFT, а не лише передачі програмного забезпечення.

 

Зберігайте версії прошивки та версії плати разом

Файли з іменами latest.hex або final_new_v2.bin можуть бути цілком зрозумілі людині, яка їх створила. Вони погано контролюють виробництво.

Виробництву потрібен надійний спосіб відрізнити схвалений випуск від:

• застаріла версія;
• інженерна споруда;
• лише тестове-зображення;
• інший варіант продукту.

Залежно від системи керування-документами клієнта, видана ідентифікація може включати версію мікропрограми, контрольоване ім’я файлу, дату випуску, відповідну версію плати, посилання на схвалення клієнта, розмір файлу або контрольну суму/хеш.

Виробництву не потрібна одна універсальна схема іменування чи контрольної суми. Їй потрібен надійний спосіб відрізнити випущену збірку від усього іншого в папці.

Це стає ще більш важливим, коли одна апаратна платформа підтримує кілька варіантів програмного забезпечення. Дошки можуть виглядати ідентичними, а готові вироби – ні.

 

Коли програмування включає-специфічні дані

Для багатьох продуктів кожна плата отримує однаковий образ мікропрограми.

Для інших продуктів також потрібна-спеціальна інформація про одиницю, як-от:

• серійні номери;
• MAC-адреси;
• ідентифікатори товарів;
• калібрувальні коефіцієнти;
• регіональна конфігурація;
• індивідуальні-налаштування клієнта;
• облікові дані пристрою.

На цьому етапі загальне мікропрограмне забезпечення та дані на-одиницю є двома різними потоками даних.

Виробництво має знати, звідки надходять унікальні значення, де вони записані, як кожне значення пов’язано з правильною фізичною платою та як запобігти повторюваним призначенням.

Одну деталь легко не помітити: коли унікальна цінність вважається спожитою?

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

Те саме стосується і вийшли з ладу агрегатів. Команда повинна знати, чи можна присвоєне значення використовувати повторно, його потрібно вилучити чи залишається пов’язаним із несправною платою для відстеження.

 

Перепустка на програмування не є перепусткою FCT

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

Перевірка програмування

Перевірка програмування запитує:

Чи правильно були записані заплановані дані відповідно до затвердженого методу програмування?

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

Функціональне тестування

Функціональне тестування запитує:

Чи виконує блок друкованої плати з живленням і програмуванням функції, необхідні для продукту?

Залежно від проекту це може включати:

• поведінка-ввімкнення;
• спілкування;
• відповідь введення/виведення;
• сенсорний вхід;
• релейний або актуаторний вихід;
• споживання струму;
• умови роботи,-визначені клієнтом.

Програматор, який відображає PASS, не повинен автоматично розглядатися як доказ того, що друкована плата пройшла FCT.

Для проектів, які потребують узгодження завантаження мікропрограми з-перевіркою рівня плати, STHLТестування та перевіркаможливості забезпечують відповідний шлях обслуговування.

 

Дві ситуації, які потребують додаткових інструкцій

Більшість завдань програмування не потребують складного процесу підготовки. Дві ситуації дійсно заслуговують на додаткову увагу, коли вони застосовуються.

Тестове мікропрограмне забезпечення та робоче мікропрограмне забезпечення

Деякі продукти використовують діагностичне мікропрограмне забезпечення під час виробництва та іншу версію мікропрограми для доставки.

Якщо так, виробництво має знати, яке зображення застосовується на кожному етапі, коли тестове зображення замінюється, як підтверджується остаточний випуск і чи потрібна ще одна функціональна перевірка після цього.

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

Не кожен продукт потребує окремої тестової мікропрограми. Процес має відповідати фактичному продукту.

Безпечне забезпечення

Для деяких пристроїв із підтримкою-захищеності потрібні підписані чи зашифровані зображення, налаштування-захищеного завантаження, конфігурація OTP/eFuse, ключі, сертифікати чи інші контрольовані дані надання.

Коли застосовуються ці вимоги, постачальник OEM і EMS має домовитися про те, хто володіє конфіденційними даними, які операції має дозвіл на виконання та як затверджуються незворотні налаштування.

Ці елементи не слід обробляти як звичайні вкладені мікропрограми.

Що робити, якщо мікропрограма змінилася після початку програмування?

Новий образ мікропрограми можна практично відразу помістити в спільну папку.

Дошки, які вже знаходяться на виробництві, не змінюються разом з ним.

Якщо новий випуск надійде після початку програмування, команда потребує чіткого планування щодо:

• пристрої, уже запрограмовані з попередньою версією;
• вже перевірені одиниці;
• блоки, що очікують на програмування;
• чи потрібно перепрограмування;
• чи впливає функціональне тестування;
• чи потрібна повторна перевірка;
• де межа перегляду знаходиться в межах виробничої партії.

Рівень перевірки має відповідати зміні.

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

Тут контроль версій перестає бути паперовою справою і стає контролем виробництва.

 

Коротка перевірка перед-виробництвом

Перш ніж запрограмувати першу виробничу одиницю, покупець і команда 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.