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

    

Arlleex

Участник
  • Публикаций

    589
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Arlleex

  • Звание
    Господин Никто

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

2 346 просмотров профиля
  1. В том и беда, что хотелось бы не читать все байты в блоке. А косвенными методами определить, было ли что-то записано в блоке или нет. Двухэтапное маркирование, приведенное в статье, ИМХО, довольно неплохой метод, при этом также очень похожий на Ваш.
  2. Почитайте начало второй страницы топика... Впрочем, до самого конца. Мы тут только это и обсуждали.
  3. В голос орнул про "надо писать не глючное ПО". Явно троллинг. По поводу алгоритмов записи. Вот есть интересная запись на хабре: https://habr.com/post/262163/ Мне понравилась идея с маркерами, то есть как отследить, что питание вырубилось в процессе записи данных.
  4. Бутлодер для Кинетис

    Ну, наверное, ничего не делать. Одна песня все равно будет - идти и вскрывать, подключаться шнурочком по UART-у или чему-нибудь еще.
  5. Бутлодер для Кинетис

    Жаль, конечно... Плохо, когда что-то уже написали за тебя, при этом никого не спросив. Мне, например, не совсем нравится подход Tiva - потому как он слишком тривиален, и даже в элементарном загрузчике руками можно проверить значение SP на более-менее адекватное значение. Причем как-нибудь более хитро. А тут просто на 0xFFFFFFFF проверили, типа есть там вообще прошивка или нет. А если мне надо прямо в начале Flash разместить свои константные таблицы и данные о прошивке, собственно? Уже Tiva будет в пролете, получается... P.S. BootROM можно как-нибудь аппаратно отключить совсем? Я как-нибудь переживу его отсутствие (чтобы код загрузчика из BootROM не выполнялся)Тем более, время загрузки увеличивает. Это мне сегодня не важно - а завтра будет критически важно, например.
  6. Бутлодер для Кинетис

    Если отбросить все BootROM и посмотреть на работу процессора, в сухом остатке получим, что всегда CPU стартует следующей последовательностью: 1. Загружает слово по адресу 0x00000000 и помещает его в MSP. 2. Загружает слово по адресу 0x00000004 и помещает его в PC. С этого момента выполняется код. То, что в данном конкретном МК может быть реализован нестираемый загрузчик (BootROM и т.д.) всего лишь означает, что CPU сначала будет выполнять код этого загрузчика. И применительно к пользовательскому приложению да, вполне вероятно, что формат образа прошивки диктуется производителем МК, либо разработчиком, если он же сам и пишет этот BootROM. Но изначально процессор всегда и полностью аппаратно выполняет шаги 1 и 2 при сбросе, поэтому в начале образа прошивки (собственный загрузчик, или же BootROM) обязаны быть корректные значения MSP и ResetVector. Остальные - уже по желанию можно будет перемещать как душе заблагорассудится. Также, нужно отметить, что конкретное отображение адресов 0x00000000 и 0x00000004 зависит от настроек системы (BootROM, Flash, RAM и т.д.), например, внешними уровнями на лапках МК. http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf, страница 17: Именно
  7. А я думал тут нет русского языка Уже привык к английской версии... Попробовал удалить куки и всю историю с автозаполнениями на Google Chrome. Предварительно выставил язык движка - русский. После сброса контента - русский и остался...
  8. Бутлодер для Кинетис

    Ну как я понял (приблизительно). 1. Код загрузчика Таблица векторов прерываний, а также самое первое слово в образе ПО загрузчика располагается, как и положено, в самом начале. Постольку-поскольку Cortex-Mx после сброса аппаратно загружает первое слово в MSP, а второе - в PC. 2. Код приложения По сути может иметь любую структуру образа хранения во Flash. Например, можно разместить таблицу служебных данных в самом начале Flash, где будет сказано о размере прошивки, ее контрольной сумме, и, в том числе, значении MSP/PSP, адреса точки входа и адреса начала таблицы векторов (если она вообще есть - ведь она может быть динамически расположена в ОЗУ). 3. Как это работает Почему позволительно расположить какую-то странную таблицу в начале Flash клиентского ПО, когда по идее там должен быть размещен образ таблицы векторов? Потому что в клиентское ПО мы попадаем из загрузчика, где явно есть инструкции установки MSP и точки входа. Соответственно, их положение в образе клиентского ПО может быть абсолютно произвольным в допустимых физических пределах. Вижу это примерно так.
  9. Проблемы были разовые, закономерности не обнаружил. Отпишусь, если удастся повторить, спасибо!
  10. Бутлодер для Кинетис

    Хм... А верно ведь. Но, как правило, в своих проектах я изначально знаю, как будет построена архитектура загрузчика и приложения, а также их взаимодействие. С другой стороны, никто не мешает после настройки в загрузчике перенастроить смещение. Тут палка о двух концах - с какой стороны не ломай, исходов будет много, и возможности разные =)
  11. Бутлодер для Кинетис

    Имеется в виду, видимо, что если лишь слинковать приложение со смещенного адреса, без сдвига таблицы векторов, то установка VTOR в загрузчике поможет. Kabdim, так если бутлоадер все настроил как надо, то в приложении можно так надвигать, что работать ничего не будет, в том числе и программно предусмотренный механизм входа в загрузчик. Я настраиваю все в загрузчике. Приложению остается только быть необходимым собранным с нужного адреса.
  12. Вопрос по C

    Я думаю реально пора закрывать, пока тут не набилось сотни три сообщений с разжеванием этой хитрой конструкции от каждого заходящего...
  13. Вопрос по C

    Полагаю, средствами линкера на этапе статической разметки памяти. Также, как и под обычные переменные при размещении по желаемым областям адресного пространства.
  14. Если МК позволяет, то можно попробовать провернуть фишку как с виртуальной памятью: обращаться в незадействованную память как к MMIO, а по прерыванию читать/писать внешний регистр. Тогда будет, ну почти, как MMIO =)