[esaulenka 7]

Дохожу в загрузчике до JumpAppl() и улетаю незнамо куда, в 0xBFFFXXXX.

Кайл умеет ходить шагами по дизассемблеру. Рекомендую, сразу будет видно, ОТКУДА улетает.

[ViKo 1]

Кайл умеет ходить шагами по дизассемблеру. Рекомендую, сразу будет видно, ОТКУДА улетает.

Да вот оттуда и улетает, как JumpAppl() жму. Больше же нет ничего для дизассемблера, проект кончается.

[SSerge 4]

Дохожу в загрузчике до JumpAppl() и улетаю незнамо куда, в 0xBFFFXXXX.

Надо смотреть куда линкер таблицу векторов засунул, похоже она осталась на прежнем месте.

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

[Сергей Борщ 130]

Да вот оттуда и улетает, как JumpAppl() жму.

Вот прямо в дизассемблере так и написано JumpAppl()? У меня там обычно что-то вроде BL R0 и чуть выше можно увидеть, откуда в R0 вдруг оказался неправильный адрес перехода.

 

[ViKo 1]

Надо смотреть куда линкер таблицу векторов засунул, похоже она осталась на прежнем месте.

Я ее (их обеих) вижу в окнах Memory в отладчике. Все, как надо: адрес стека, адрес по сбросу...

 

Вот прямо в дизассемблере так и написано JumpAppl()? У меня там обычно что-то вроде BL R0 и чуть выше можно увидеть, откуда в R0 вдруг оказался неправильный адрес перехода.

У меня тоже, естественно. BL R1. И адрес в нем правильный, из таблицы, что находится по адресу 0x08004004.

А дальше - то, что описал.

 

Здесь вот какая штука - в основной программе использую Keil RTX RTOS. Может, она и меняет что-то, например, VTOR. Надо посмотреть в несдвинутом проекте.

[ViKo 1]

Из программы-загрузчика по стартовому адресу основной программы 0x08004000 переходит. Начинает обнулять переменные и когда обращается к внешнему ОЗУ, впадает в HardFault. Устанавливается бит Imprecise data access violation, и всё.

Если же основную программу скомпилировать с адреса 0x08000000, то работает.

 

Складывается впечатление, что нужно сконфигурировать ExtMem. Что делается в кейловской SystemInit, вместе с установкой рабочей частоты, еще до обнуления переменных в __main.

Я SystemInit использую свою, контроллер внешней памяти программирую потом. Почему же программа не висла до этого?

 

Еще вижу в отладчике для сдвинутой программы в панели NVIC VTO=0x08004000 (как и должно быть), и TBLOFF=0x100080 (а это что за хрень?). В несдвинутой программе последнее - по нулям.

[ViKo 1]

Перенес инициализацию FSMC (заодно и всего остального) в SystemInit. Как и предполагал, переход из загрузчика заработал. И как только до этого инициализировались переменные (массивы-буферы), ума не приложу.

Вот только просто ждать таймаута для перехода - не по человечески. Можно по кнопке оставаться в загрузчике. Так ее еще передать и принять нужно...

[jcxz 216]

Судя по рисунку, STM32F20X может выполнять программу из внешней памяти. А также и из внутренней OTP Flash, наверное.

...

То есть, можно команды выбирать откуда хочешь!? :rolleyes:

Должен выполнять, но возможно нужно настроить MPU предварительно.

По-крайней мере для LPC1788 в UM указано:

Default memory space permissions for the Cortex-M3 do not allow program

execution from the address range that includes the dynamic memory chip selects.

These permissions can be changed by programming the MPU

В реальности если запустить код в SDRAM, то при шагании JTAG видно, что несколько команд (с десяток) код выполняется нормально, но на некоторой команде вдруг улетает в

Memory Management Fault (MMFSR.IACCVIOL = 1).

Я только что прописал конфигурирование MPU и после этого всё заработало - теперь программа нормально выполняется из SDRAM (LPC1788).

[ViKo 1]

Хочу спросить... Что-то не могу после прошивки новой программы перескочить в основную. Если после сброса, и таймер отсчитал 2 с - переходит нормально. За эти 2 с я должен нажать кнопку на панели, тогда дается таймер в 16 с для приема кода прошивки. Так вот, если кода не пришло, тоже не могу перейти в основную программу. Как будто, что-то переинициализировать нужно.

 

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

Сразу после программирования диод не пыхает, т.е., не обнаруживается зашитая прошивка. После сброса - нормально проходит, после 2 с ожидания в загрузчике. Если нажму кнопку в это время, после 16 с светодиод тоже пыхает, но перехода нет. Чудо.

Запросы от USART стираю. Больше никакими прерываниями не пользуюсь.

P.S. Я, собственно, прерываниями от USART не пользуюсь. Проверяю состояние. Постирал pending биты запросов. Еще забыл про таймер. От него тоже стер. Всё то же.

[ViKo 1]

А в отладчике после 16 с перескакивает в основную программу и работает. И после обновления прошивки тоже перескакивает. Что-то я пасую.

Похоже, перескакивает он всегда, только работать, как надо, не хочет.

 

А еще у меня Keil пишет "*** error 34, line 32: undefined identifier" на строку G, main в файле инициализации отладчика. Конкретно, на main. ?

[ViKo 1]

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

 

Про кэши ART почитал.

To limit the time lost due to jumps, it is possible to retain 64 lines of 128 bits in an instruction cache memory.

...

data cache ... feature works like the instruction cache memory, but the retained data size is limited to 8 rows of 128 bits.

Неслабые такие кэши? Но в загрузчике я их не включаю. И prefetch тоже.

 

[Сергей Борщ 130]

Выходите через сброс (я выхожу через сброс по собаке). При вашем подходе потом замучаетесь в приложении приводить в исходное состояние использованную в загрузчике периферию.

[ViKo 1]

Все, исправил. Кнопка от панели передается двумя байтами, да еще и нажатое и отпущенное состояния. Лезло ненужное в основную программу.

Сбрасываю флаг USART_SR_RXNE, основная программа перестала улетать в прерывание.

 

Теперь задача - зашифровать-расшифровать прошивку. Думаю, не задействовать ли вычислитель CRC в мк.

[veteq 0]

Есть проблема со входом в бутлоадер STM32L051 (cortex m0+) из тела программы, микроконтроллер сбрасывается. Тот же код только с другими адресами прекрасно работает на STM32L151 и STM32L401 (cortex m3/m4). Подскажите в чем может быть проблема?

 

void (*SysMemBootJump)(void);

SysMemBootJump = (void (*)(void)) (*((unsigned int*) 0x1FF00004));

__disable_irq();
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;

__set_MSP(0x20001000);
SysMemBootJump();

Изменено 19 марта, 2015 пользователем veteq

[ViKo 1]

Теперь задача - зашифровать-расшифровать прошивку.

Попробовал XTEA. Пока только закодировал. :rolleyes: Не знаю, сколько времени будет декодироваться в микроконтроллере.

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

 

Сделал и декодирование, все по https://ru.wikipedia.org/wiki/XTEA#cite_note-report-1

Декодируется быстро, практически, мгновенно.

Фактически, имеется 4 32-битовых ключа, и количество итераций тоже можно выбрать на свой вкус.