Концепции загрузки STM32F4 и перемещение векторной таблицы


8

Есть некоторые вещи, которые я не понимаю в процессе загрузки микроконтроллера STM32F4.

Мое понимание таково:

  1. Загрузки ARM Cortex-M4 ожидают, что значение инициализации указателя стека и векторы прерываний включены 0x00000000 + SCB->VTOR, тогда SCB->VTORкак очищается при сбросе.
  2. Там нет памяти в этом месте. Флэш-память начинается с 0x08000000, SRAM в 0x20000000.
  3. Чтобы сделать возможной загрузку, микроконтроллер может сопоставить диапазон памяти флэш-памяти или SRAM 0x00000000. Диапазон памяти для отображения определяется состоянием загрузочных штифтов.

Мои вопросы:

  1. Почему в справочном руководстве STM32F4 на стр. 69 говорится, что

    Когда устройство загружается из SRAM, в коде инициализации приложения необходимо переместить таблицу векторов в SRAM, используя таблицу исключений NVIC и регистр смещения.

    ? На мой взгляд, в этом нет необходимости, поскольку вся область памяти в любом случае перекрывается. Интересно, что это не требуется, когда область флэш-памяти переназначается в 0x0пространство.

  2. Я думаю, что единственное использование для загрузки из SRAM - это сокращение циклов записи на флэш-память во время разработки. Прежде чем освободить микроконтроллер от сброса, вы записываете программу в SRAM с помощью отладчика и затем загружаетесь оттуда. Однако, поскольку у вас есть доступ к отладчику, никаких ограничений на загрузку не будет. Так зачем иметь эту функцию?

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


Вы можете загрузить из оперативной памяти, чтобы выполнить обновление прошивки. Код ОЗУ выполняется и повторно мигает содержимое флэш-памяти. После завершения обновления вы сбрасываете снова выполнить с Flash.
Фотис

Ответы:


5

Вопрос 1:

Я не могу определенно ответить на ваш первый вопрос. Но в руководстве по программированию, где описывается регистр VTOR ( стр. 212 ), говорится, что бит 29 используется для определения того, где находится таблица векторов, либо в области кода (0), либо в области SRAM (1).

Теперь я не понимаю, почему это нужно делать по той же причине, по которой вы заявляете, что SRAM получает псевдоним 0x0, так почему же нужно устанавливать это смещение?

Единственное предположение, которое у меня есть, изложено на цитированной вами странице 69. Они говорят:

область кода начинается с адреса 0x0000 0000 (доступ через шины ICode / DCode)

область данных (SRAM) начинается с адреса 0x2000 0000 (доступ через системную шину)

Cortex ® -M4 с процессором FPU всегда выбирает вектор сброса на шине ICode

Возможно, при прерывании используется шина ICode, которая не может получить доступ к SRAM, даже если переотображена (я не знаю, правда ли это). Это объясняет, почему этот бит должен быть установлен соответствующим образом, сообщая ядру об использовании системной шины и доступе к SRAM.

Вопрос 2:

Хотя это может быть правдой, что SRAM пуст при первой загрузке устройства, это не обязательно для последующих загрузок. Таким образом, вы можете создать что-то вроде устройства с батарейным питанием, которое запрограммирует свою SRAM во время производства, а затем будет работать до полной разрядки батареи, что очистит ее от SRAM. Я думаю, это сделало бы реинжиниринг устройства немного сложнее.

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

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

Не очень убедительное приложение, чтобы исправить все проблемы, чтобы переназначить SRAM.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.