Плата собрана и успешно проходит электрическую проверку, но готовый прибор ведёт себя не так, как опытный образец. Причина может быть не в пайке: на часть изделий попала прежняя прошивка, некоторые платы вовсе не программировали, а отдельные после ремонта вернули в поток без повторной проверки. Для серийного выпуска нужен воспроизводимый процесс загрузки программного обеспечения. Он начинается с выбора файла и заканчивается подтверждением работы конкретного устройства.
Какие данные подготовить до начала сборки
Производству недостаточно передать файл с именем «firmware_final». Для каждой аппаратной ревизии указывают разрешённую версию программы, контрольную сумму файла, порядок загрузки, требования к питанию, адреса или настройки программатора и критерий успешного завершения. Если у изделия несколько микроконтроллеров, отдельно описывают, что загружать в каждый из них и в какой последовательности. Все эти сведения должны относиться к одному согласованному выпуску документации.
Следует разделить обычную прошивку, заводские калибровки, серийные номера и индивидуальные настройки заказчика. Общий бинарный образ может быть одинаковым для партии, а параметры отличаться между экземплярами. Их потеря при повторном программировании способна сделать исправную плату неработоспособной. Архитектуру ПО и доступ к памяти стоит обсуждать ещё при разработке программного обеспечения.
Как связать образ с аппаратной ревизией
Механическое совпадение разъёма для программирования не гарантирует совместимости. В новой ревизии платы могли поменять датчик, распиновку выхода или объём памяти. Если загрузчик позволяет, стенд читает идентификатор платы и сверяет его с таблицей совместимости до начала записи. Когда аппаратного идентификатора нет, оператор сканирует маркировку изделия, а программа берёт разрешённый образ из задания на партию.
Файл для загрузки берут из контролируемого хранилища, а не с рабочего стола сотрудника. После копирования проверяют его контрольную сумму. В журнале оставляют сведения не только о «версии 2.1», но и о конкретном образе: одинаковая строка версии иногда встречается у двух пересобранных файлов. Правила обновления особенно важны при замене компонентов. Эту часть процесса удобно согласовывать вместе с изменениями BOM и платы.
Каким должен быть рабочий цикл программатора
- Считать идентификатор изделия и проверить, что для него открыто производственное задание.
- Проверить аппаратную ревизию и назначить утверждённый образ.
- Установить питание и надёжный контакт с интерфейсом программирования.
- Записать программу, затем выполнить проверку записи доступным для платформы способом.
- Считать версию из работающего устройства, проверить важные параметры и записать результат в журнал.
Программатор должен явно сообщать, в каком состоянии находится плата: «не обработана», «идёт запись», «ошибка», «прошла проверку». Одного зелёного индикатора на корпусе прибора мало, если сотрудник не понимает, к какому серийному номеру относится результат. Для снижения ошибок оснастку делают с устойчивой фиксацией платы и контактами, к которым можно подойти без риска повредить компоненты. Подробнее о планировании доступа к узлам написано в материале «DFT, тестовые точки и JTAG».
Почему проверка записи не заменяет функциональный тест
Проверенная контрольная сумма означает, что нужные данные попали в память. Она не доказывает, что устройство правильно запускается с установленной периферией и в заданных режимах. После прошивки имеет смысл проверить критические функции: старт, связь с интерфейсом, показания датчиков, реакцию выходов, сохранение настроек. Объём проверки зависит от назначения изделия и цены пропущенного дефекта.
Если программа записывается до окончательной сборки, часть операций после установки в корпус может повредить плату или изменить настройки. Поэтому в маршрутной карте указывают, на каком этапе выполняется окончательная функциональная проверка. В отдельной статье сайта разобрано, как подготовить электронное устройство к испытаниям на производстве.
Что делать после сбоя и повторной загрузки
Если связь с платой оборвалась, питание пропало или проверка завершилась ошибкой, изделие переводят в отдельный статус. Оператор не должен возвращать его в общую тару, ориентируясь только на то, что программа «вроде запустилась». Для повторной операции задают инструкцию: можно ли очищать память, нужно ли сохранить калибровку и ключи, какие тесты повторить. После доработки журнал хранит оба результата, а не стирает первую ошибку.
При работе с индивидуальными ключами или идентификаторами их подготовку, доступ и хранение согласуют отдельно. Копирование одного серийного номера на несколько изделий может привести к конфликтам при работе сети и обслуживании. Чувствительные данные не размещают в общедоступных файлах заказа; при этом производству нужна проверяемая процедура выдачи параметров конкретной плате.
Что запросить у разработчика перед тиражом
Попросите матрицу совместимости аппаратных и программных версий, утверждённый образ с контрольной суммой, инструкцию по подключению и повторному программированию, список индивидуальных данных, сценарий приёмки и правила идентификации изделий. На пилотной партии проверьте процесс с ошибками: неверная ревизия платы, обрыв контакта, повторное сканирование номера и сбой питания. Эти случаи покажут, способен ли стенд остановить неудачную операцию, не передав изделие дальше.
Как проверить процесс перед передачей на линию
Проведите несколько намеренно нештатных сценариев на тестовых изделиях. Подключите плату неподходящей ревизии, подайте питание ниже допустимого для программирования, разорвите контакт во время проверки, повторите запись того же серийного номера. Исправный производственный процесс должен дать оператору понятный отказ и не записывать изделие как успешно обработанное. После восстановления контакта проверьте, можно ли безопасно повторить операцию и остаются ли индивидуальные данные в нужном состоянии.
Отдельно оцените время цикла: запись, проверка образа, чтение версии и функциональная проверка занимают разное время. Если одно место программирования становится узким участком, несколько параллельных стендов должны пользоваться одинаковым утверждённым образом и единым журналом. Копирование файла вручную между рабочими станциями создаёт риск расхождения версий. Лучше проверять контрольную сумму на каждом стенде до начала производственного задания.
«Электроника+» занимается разработкой ПО для электронных устройств и разработкой и производством электроники. Чтобы обсудить прошивку изделий на линии и её связь с испытаниями, отправьте описание проекта на Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript. или позвоните +7 903 888-66-64. Материалы по теме: проектирование тестовых точек и функциональные испытания.
