Цитата(Danis @ Mar 23 2012, 21:46)

другого изделия на STM32F1xx. У нас это решено жестко, введен ID код устройства в каждый загрузчик конкретного устройства, и при несовпадающей по ID прошивке идет соответствующее предупреждение. Получается именно так, что для каждого устройства свой отдельный загрузчик.
У нас примерно так и решено - только код не на каждый вид устройства, а на конкретную группу устройств. Причем чаще встречается разделение по коду между заказчиками - чтобы они между собой программами не менялись (получали только те софтовые фичи, за которые заплачено, грубо говоря). Таких кодов не очень много (порядка на два меньше чем типов устройств), и для каждого генерируется свой загрузчик (автоматизировано из одних и тех же исходников). Эти коды не зависят от типа процессора - назначаются фиксированно при появлении новой группы, не меняются десятилетиями, и хорошо известны на память всем вовлеченным сотрудникам - при том что сменилось уже несколько поколений процессоров. Процесс выбора загрузчика выглядит так - берем плату, смотрим тип процеcсора - пусть STM32, потом смотрим документы для кого эта партия плат, допустим "Заказчик 8", идем в папку BOOT/STM32 и берем там файл stm32_08.hex. При этом по факту на плате может быть и 100 и 101 и 103-ий процессор - никого на данном этапе это не заботит. Там же лежат автоматизирующие командные файлы, прошить загрузчик в несоответствующий ему процессор (допустим SAM7 в LPC17) практически нереально - утилиты выругаются.
Прошить не соответствующую рабочую прошивку теоретически возможно, такое даже изредка бывает (при разработке, единичные случаи, потому как в серии на конвеере такое не случается), но фатальных последствий не было за 12 лет использования загрузчиков ни разу. В первых изделиях начали было разводить "зоопарк" загрузчиков про который Вы говорите, и делать так же жестко как у Вас, но облом наступил быстро (темп 20-30 разных проектов в год), как выяснилось на практике последствий от неправильной прошивки обычно никаких, поэтому пришли к унифицированному загрузчику. Рабочий код при инициализации перифериии производит несколько проверок и блокируется "в случае чего" (а уж прошивка Cortex на ARM7TDMI виснет просто сразу, STM32/LPC17 виснут еще на инициализации основного генератора), грамотная схема учитывающая начальное состояние после сброса и с помехоподавляющими резисторами не дает палить порты при вероятных конфликтах, ну и загрузчик "всегда живой" и позволяет стереть зашитое "не то" и записать верную прошивку.
Часть заказчиков вообще покупает только софт - им просто процессоры с загрузчиком поставляются, выпускают они свою номенклатуру изделий самостоятельно. Тут без унифицированного загрузчика печалька была бы - поставляется это относительно крупными партиями (логистический гемор с "зарубежом" еще тот), а дальше заказчик смотрит на свои продажи и динамично регулирует свою номенклатуру.
Кстати, внести уникальный код изделия позволяет утилита, которой шьют загрузчики - банально через ключик командной строки. Не обязательно же идентификатор создавать на этапе компиляции - достаточно место для него выделить. Но это тоже как-то на практике не востребовано (ага, уже представил как я начинаю "грузить" производство требованиями зашивать еще один дополнительный код).
В-общем, победил прагматический принцип минимальной достаточности. Времени и людей всегда не хватает, если можно обойтись без "зоопарка", то это следует сделать.