Cortex-M3 от ST, Как программно узнать размер страницы флеша Опции

[shreck]

Добрый день.
Требуется программно определять размер страницы флеш-памяти у Cortex-M3 процессоров от ST, в частности у семейства STM32F103.
Вот смотрю документацию и вижу, что есть регистр, хранящий общий размер памяти на кристалле. А есть ли какой способ узнать размер страницы памяти?

[Danis]

Требуется программно определять размер страницы флеш-памяти у Cortex-M3 процессоров от ST.... А есть ли какой способ узнать размер страницы памяти?

Интересно, а можно поинтересоваться, для чего это нужно и что это дает? По сути, например, мне нужно писать во flash когда я обновляю память программ или память данных flash через свой шифрованных загрузчик(в микроконтроллере), приспособленный под конкретную марку МК, и кабы тут уж все изначально понятно, сколько и какого объема сектора в чипе.

[VslavX]

flash когда я обновляю память программ или память данных flash через свой шифрованных загрузчик(в микроконтроллере), приспособленный под конкретную марку МК, и кабы тут уж все изначально понятно, сколько и какого объема сектора в чипе.

Да много чего дает, например единый загрузчик - у нас применяются 100, 101 и 103 в разных изделиях, с буквами от 'C' (256К флеша) до 'G' (1M флеша в двух банках). Причем в одно и то же изделие (на ту же печатную плату) , в зависимости от целевого заказчика, могут ставиться разные чипы. Объяснять производству куда какой загрузчик записывать, держать целую базу разных загрузчиков - это все издержки, вероятность ошибок и прочее.
Также есть набор софтовых-кубиков, например стек USB, прошитый в 100-ый, прочтет ID и аккуратно скажет что "ошиблись адресом" вместо исключения/зависания. В-общем, при имеющейся унификации по софту и железу, определять тип процессора во время исполнения отнюдь не вредно.

[Danis]

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

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

[VslavX]

другого изделия на STM32F1xx. У нас это решено жестко, введен ID код устройства в каждый загрузчик конкретного устройства, и при несовпадающей по ID прошивке идет соответствующее предупреждение. Получается именно так, что для каждого устройства свой отдельный загрузчик.

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

Прошить не соответствующую рабочую прошивку теоретически возможно, такое даже изредка бывает (при разработке, единичные случаи, потому как в серии на конвеере такое не случается), но фатальных последствий не было за 12 лет использования загрузчиков ни разу. В первых изделиях начали было разводить "зоопарк" загрузчиков про который Вы говорите, и делать так же жестко как у Вас, но облом наступил быстро (темп 20-30 разных проектов в год), как выяснилось на практике последствий от неправильной прошивки обычно никаких, поэтому пришли к унифицированному загрузчику. Рабочий код при инициализации перифериии производит несколько проверок и блокируется "в случае чего" (а уж прошивка Cortex на ARM7TDMI виснет просто сразу, STM32/LPC17 виснут еще на инициализации основного генератора), грамотная схема учитывающая начальное состояние после сброса и с помехоподавляющими резисторами не дает палить порты при вероятных конфликтах, ну и загрузчик "всегда живой" и позволяет стереть зашитое "не то" и записать верную прошивку.

Часть заказчиков вообще покупает только софт - им просто процессоры с загрузчиком поставляются, выпускают они свою номенклатуру изделий самостоятельно. Тут без унифицированного загрузчика печалька была бы - поставляется это относительно крупными партиями (логистический гемор с "зарубежом" еще тот), а дальше заказчик смотрит на свои продажи и динамично регулирует свою номенклатуру.

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

В-общем, победил прагматический принцип минимальной достаточности. Времени и людей всегда не хватает, если можно обойтись без "зоопарка", то это следует сделать.