Перейти к содержанию
    

STM32 установка серийного номера при программировании. Как реализовать ?

15 minutes ago, ViKo said:

А клеит наклейки кто/что?

Руками наклеиваются. Это, конечно, недоработка, но тоже серийность не та :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 часов назад, ViKo сказал:

Я именно так и делаю в ST-Link Utility. А чтобы не путать номера, записываю в текстовый файл. Серийный номер еще и на задней панели прибора пишется, так что требуется строгое соответствие, и автомату этого доверить никак невозможно. Только вручную, в трезвой памяти. 

Покупаете сканер штрих-кодов подключаемый к компу и доверяете это дело ему: наводите его на наклейку -> он посылает номер в порт, программа генерит hex.

Уникальные наклейки заказываете или печатаете сами, массово.

На прошлой работе на серийном производстве так и сделали. До этого периодически натыкались на дубликаты своих устройств. Никакая дисциплина не помогала.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 06.07.2019 в 00:43, Aner сказал:

Чем не устраивает внутренний уникальный ID проца?

Так и не услышал здесь ответа на реальное предложение, которое позволяет не иметь дубликатов в принципе и полностью избавиться от чел. фактора?

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может я пропустил что-то.

J-liink отлично может  по адресу писать с посл. увеличением числа. 

И потом, о каком STM речь, вроде не все имеют ID.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

45 minutes ago, mantech said:

Так и не услышал здесь ответа на реальное предложение, которое позволяет не иметь дубликатов в принципе и полностью избавиться от чел. фактора?

Так сначала определится надо на кой этот серийный номер.
У дивайса в принципе может быть куча серийных номеров для разных назначений. 
Скажем есть: серийный номер проставленный производителем (контрактным сборщиком)  процессорного модуля, потом серийный номер непосредственно процессора из которого генерируются MAC-и для разных медиа, серийный номер платы на который ставится модуль с процессором, серийный номер системы куда ставится плата, серийный номер даваемый на производственном участке и т.д.   и т.п.
 

Каждый из этих номеров появляется на разных жизненных этапах, имеет разные источник происхождения и время жизни. 
Скажем серийник для MAC-ов после ремонтов меняется, серийник производства  тоже меняется и даже еще до поставки может меняться несколько раз в зависимости от того в какую систему компонент ставится или переставляется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, AlexandrY сказал:

Так сначала определится надо на кой этот серийный номер.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У нас, например, каждый девайс, выпущенный производством, проходит контрольное тестирование. Подключается по доступному интерфейсу к ПК, а на ПК установлена тестовая программа с одной кнопкой и индикатором успешно/не успешно. Оператор подключает необходимые разъемы-заглушки или имитаторы интерфейсов к устройству и нажимает кнопку запуска теста. В МК крутится тестовое ПО, разумеется.

Так вот, серийный номер можно формировать на ПК, и после окончания тестирования автоматом давать команду на запись его во внутреннее ПЗУ. Если тестирование успешно, то увеличиваем счетчик серийного номера и отправляем на устройство, попутно пересохранив серийник в файле на ПК. Если же тест провален, то в отдельный файл на ПК записываем этот серийник как отметку сбойного прибора и берем следующее изделие.

Так можно автоматизировать процесс: берем с утра коробас с серийником, например, 100, забиваем его как начальное значение в комп, а дальше по порядку этикеточных номеров тестируем каждый девайс. К вечеру получаем все пронумерованные индивидуальным серийником блоки и блоки, в которых что-то пошло не так. Что конкретно - смотрим логи.

P.S. ИМХО, хранить в программе серийники плат, модулей и прочих прелестей не нужно. Обычно это дело прямо в сборочном цехе краской проставляют. И после ремонта вообще может оказаться, что блок будет состоять из комплектующих таких же доноров. Так зачем хранить в МК эту ненужную инфу, к тому же - кто будет заморачиваться и руками менять эти серийники в МК? Программисты? Не думаю. Цеховики? Тоже мимо: человеческий фактор - он сказал, что все переписал, а на самом деле курить пошел и положил на это все. Серийник, о котором тут идет разговор, ИМХО, нужен для формирования MAC-адресов и т.д., и для того, чтобы в случае багов опознать конкретный девайс (получая некую статистику возможных отказов).

Впрочем, механизм похож на тот, что огласил Сергей Борщ. Только, как я понял, у него в самом конце еще и само рабочее приложение загружается, чтобы девайсы с производства выходили полностью готовые к употреблению.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, Arlleex сказал:

P.S. ИМХО, хранить в программе серийники плат, модулей и прочих прелестей не нужно. Обычно это дело прямо в сборочном цехе краской проставляют.

... а потом, в один прекрасный день оказывается, что написанное краской не соответствует прошитому в устройстве :dash2:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

19 минут назад, jcxz сказал:

... а потом, в один прекрасный день оказывается, что написанное краской не соответствует прошитому в устройстве

Так я и говорю, что не имеет смысла хранить номера самих плат и субмодулей в МК. Так то даже при ремонте этикетку с платы можно содрать и переклеить на новую, никто даже не заметит. И получится, что плата другая, а этикетка с серийником старая осталась. В таком случае, ИМХО, придется вести картотеку анализа отказов, где для каждого сбойного устройства описывается, какие модули в устройстве были, на какие поменяли, какой ремонт был произведен и т.д.

А вот если девайс состоит из множества модулей с программируемыми компонентами, то в каждый модуль должен быть прошит уникальный ID. Тогда одним нажатием кнопки в сервисной программе на ПК можно узнать реальный состав изделия.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 минут назад, Arlleex сказал:

А вот если девайс состоит из множества модулей с программируемыми компонентами, то в каждый модуль должен быть прошит уникальный ID. Тогда одним нажатием кнопки в сервисной программе на ПК можно узнать реальный состав изделия.

Даже если не из разных модулей - всё равно очень часто устройству нужно знать свой серийник. Устройство может стоять в таком месте, что неудобно посмотреть наклейку с серийником, а пользователю нужно обратиться например в тех.поддержку производителя (с указанием сер.номера). Или в сер.номере может быть закодирован вариант аппаратного исполнения устройства (если исполнений много).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

22 минуты назад, jcxz сказал:

Даже если не из разных модулей - всё равно очень часто устройству нужно знать свой серийник.

Так я и не против, серийник должен быть. Речь идет о хранении уже чуть ли не серийных номеров самих плат в изделии, что я уже считаю излишним. Храним некий ID, тот же счетчик, на основе которого девайс будет формировать внутренние адреса для, например, MAC-контроллера, и будет выдавать его пользователю а-ля "я устройство с серийным номером 100500".

А если еще и хранить номера составных изделий (не программируемых отдельно), то девайс по запросу ответит чем-то вроде "я устройство номер 100500, у меня внутри плата с релюхами с серийником 100, а плата с разъемами имеет заводской номер 400". Но эта инфа будет недостоверной, например, если при ремонте плату с реле выкинут и заменят другой с другим серийником, а МК перепрошить (обновить базу серийных номеров) забудут. А рано или поздно действительно забудут. Вот и получится, что девайс выплюнет, что его состав не изменился, а на самом деле он уже тыщу раз переделывался, один процессорный модуль остался:biggrin:

Если уж и нужно как-то отслеживать состав, то на каждом модуле должно быть что-то энергонезависимое - например, дешманская микросхема ПЗУ; или использовать ПЗУ внутри компонентов (как, например, в том же DS18B20). Я думаю, как-то так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21 hours ago, Arlleex said:

не имеет смысла хранить номера самих плат и субмодулей в МК

Случаи разные бывают...

Программно получить номер с этикетки через какой-то интерфейс (экран, провод, интернет) - очень часто пригождается и поддержке, и самим пользователям.

Но вопрос с ремонтом надо предусмотреть сразу, да. Сейчас у нас изделия не очень сложные, и номерной (с гарантийником) только основной блок (можно считать, что он цельный - без паяльника не разбирается). Периферия простенькая, и какие-то номерки на ней в гарантийный талон не попадают (я даже не знаю, являются ли те цифры уникальными).

А вот когда в изделии было две более-менее одинаковые по стоимости части, отдел ремонта регулярно хотел подменить серийник (записан во флешке контроллера, который находится только в одной части; вторая - дорогая, но "тупая"). А вот тут начинались проблемы...

 

В общем, если у вас объемы хоть сколько-то заметны, попробуйте автоматизацию (идеи aaarrr и jcxz не новы, но по-прежнему актуальны). Да, автоматизация ломается, но люди на этой тупой однообразной работе ошибаются чаще.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня в девайсах загрузчик и основная программа зашиваются раздельно. В области загрузчика один из секторов отведен под хранение как раз таких вещей - серийник, версия железа, вариант сборки и т.п. Загрузчик умеет общаться с компом через USB и кроме обновления основной программы (шифрованной) умеет так же выполнять некоторые команды, в том числе обновление серийника. На компе имеется консольная утилита для работы с загрузчиком. В зависимости от параметров в командной строке она умеет заливать прошивку, обновлять серийник, параметры в EPROM и т.д.

Сначала через JFlash заливается загрузчик. А потом прошивка производится через скрипт, вызывающий эту утилиту с различными параметрами и оценивающий результат ее выполнения:
1. Залить прошивку.
2. Залить параметры в EPROM.
3. Взять из файла текущий серийник и залить его в девайс.
4. Добавить в базу данных (SQLite) запись с данными о прошитом девайсе - дата прошивки, тип, серийный номер, UID микроконтроллера и т.п.
5. Увеличить на единицу текущий серийник и сохранить его в файл.

То есть сначала вся новая партия девайсов прошивается загрузчиком через JFlash, а потом каждый девайс подключается по USB и запускается этот скрипт.

После корпусирования девайсов они подключаются по USB, на компе запущенная программа на лету подхватывает подключенный девайс и показывает информацию о нем, и на корпус клеится соответствующий шильдик. Шильдики печатаются в типографии, сразу с серийными номерами. Из базы данных тоже печатаются наклейки с основной информацией текстом и некоторыми подробностями в штрих-коде, эти наклейки потом клеятся на коробки при упаковке.

За несколько лет накладок не было :)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...