базовый адрес времени загрузки cortex-m3 bare metal

Для встраиваемых систем с «голым железом», таких как ваша, это достигается путем компиляции/связывания вашего кода как перемещаемого кода, также известного как Независимый код позиции.

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

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

Вы можете найти этот другой вопрос SO ("Попытка загрузить независимый от позиции код на cortex-m3") также полезен.

Вам нужен какой-то способ, чтобы устройство определяло, когда оно сбрасывается, из какого из двух возможных мест оно должно начать выполнение. Но, как правило, «голое железо» имеет только одно начальное местоположение, из которого оно запускается после сброса (некоторые контроллеры могут выбирать из двух или, возможно, более точек входа в зависимости от логического уровня некоторых контактов на устройстве).

У нас было аналогичное требование, и мы разработали следующую схему:

• требуется небольшая программа загрузчика - она ​​построена и связана с программой, которая получает контроль над процессором при перезагрузке
• основной образ программы фактически строится дважды — по одному разу для каждого возможного местоположения. Примечание: два возможных места загрузки фиксированы и известны загрузчику.
• в начале образа программы есть небольшая структура данных, которая содержит несколько битов информации, важной для загрузчика. Среди них адрес точки входа программы и контрольная сумма образа программы

Загрузчик проверяет фиксированные, хорошо известные местоположения для проверки суммы двух возможных образов.

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

Ключ к этому в том, что загрузчик должен быть простым и тупым. Его нелегко обновить, поэтому вы хотите, чтобы он был достаточно глупым, чтобы в нем не было ошибок.

Теперь устройство можно обновить во время его работы, прошив образ в нерабочее место (имеющееся у нас устройство Cortex-M3 позволяет это сделать - если LPC1758 не позволяет этого, тогда вам нужно иметь что-то, что работает из ОЗУ). флеш-обновление). Сброс, и загрузчик подхватывает только что прошитый образ.

Системе требуется небольшая предварительная работа, чтобы загрузчик работал и работал надежно, но как только он заработает, обновления надежны на 100% (если новая прошивка не завершается, старый образ является единственным, который проверяет контрольные суммы, поэтому он побегу при следующем сбросе - кирпичей нет). Главный недостаток — и он большой — заключается в том, что вы фактически теряете половину адресного пространства флэш-памяти для основной программы, поскольку флэш-память должна содержать два конкурирующих образа.