Обновление прошивки LPC2148, реализация firmware updater на KEIL CARM Опции

[Shkn]

Есть задачка: реализовать обновление прошивки LPC2148, например с SD карточки. На данные момент есть полноценная работающая прошивка. Есть код читающий с карточки и записывающий во FLASH. Сдесь работает как ожидается: проверяю что записалось с исходным бинарником - совпадает.
Но возникли трудности с передачей управления в обновляемую часть: передача происходит, выполняется несколько функций и зависает. В качестве примера использовал TN FWU, но он реализован с использованием RV (и других компиляторов). Имеется как __ARM функции, так и __THUMB, а также и __RAM.
Как сделать корректную передачу управления?

Сообщение отредактировал Shkn - Sep 3 2007, 07:55

[etoja]

После программирования процессора сбрось его по watchdog'у.

[Shkn]

После программирования процессора сбрось его по watchdog'у.

Но я же опять вернусь на начало, отработает код прошивалки. В основной проге инициализируется watchdog и сбрасывает все.

[etoja]

Прошивалка должна располагаться в верхних секторах flash и не использовать прерывания.
Актививизировать прошивалку можно по кнопке или факту появления SD карточки в разъёме.
Прошиваемая программа должна располагаться как обычно, по нижним адресам и может использовать прерывания.

[AndreyS]

Добрый день.

Актививизировать прошивалку можно по кнопке или факту появления SD карточки в разъёме.

Не хочу разводить флейм, но.

А если плата располагается удаленно и нажать кнопочку вызова бутзагрузчика нет возможности (карта уже установлена), как тогда произвести апдейт прошивки???

Удачи.

[OlegS]

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

А если плата располагается удаленно и нажать кнопочку вызова бутзагрузчика нет возможности (карта уже установлена), как тогда произвести апдейт прошивки???

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

Так, что предлагаю о способах начала процесса мысль не развивать
А вопрос собственно был в потере управления, насколько я понимаю, из постоянной части в "обновляемую"??? правда остальное не очень понятно, не мог бы уважаемый Shkn поподробнее описать что и как? какая общая задумка была уж очень хочеться узнать .... а то самому надо что-то подобное будет в скором замутить и именно с карточки

[AndreyS]

Добрый день.

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

TN FWU не смотрел, не знаю. Отсюда и предположение.

Удачи.

[Shkn]

Добрый день всем.
Пояснения. TN FWU беру с сайта http://www.tnkernel.com/usb_fw_upgrader.html. Там же расписано как заменять вектора прерывания. Делаю аналогично.
Для чтения с SD-карточки использую efsl, с переделкой кода в __THUMB - так весь загрузчик помещается в адресном пространстве flash с 0х00000000 - 0х00006000. Данный диапазон занимает аккурат первые 6 секторов. Остальные я могу стирать и прошивать не боясь попортить загрузчик.
Для основной (так буду называть программу, которая обнавляется) указано, что она может занимать все остальное адресное пространство, т.е. 0х6000 - 0x7ffff.
В основной сохранен startup.s, в котором вызывается ?C?INIT.
Управление на основную передаю ldr pc, =(0х6020). По 0х6000 - 0х6020 находится дескраптор проги.
Выполнение приходит в main() основной проги, т.к. получаю отладочные сообщения. Как выше писал, основная прога использует смешанный режим __ARM + __THUMB. В какой-то момент написания кода было, что зависание происходило по завершению функции вывода отладочной строки (первое обращение к ней). После я внес ряд изменений в код и програ зашевелилась. Что именно помогло не определил (да и решил заработало - не тронь). Теперь зависание происходит в месте установки обработчика прерывания таймера. Буду вставлять отладочные сообщения и смотреть что именно вредит. Но скорее всего где-то промахнулся с настройкой векторов.

Сообщение отредактировал Shkn - Sep 4 2007, 06:06

[Alechek]

NIT.
Управление на основную передаю ldr pc, =(0х6020). По 0х6000 - 0х6020 находится дескраптор проги.
Выполнение приходит в main() основной проги, т.к. получаю отладочные сообщения.в.

так и не понял, зачем передавать управление в main().
Я передаю управление в
extern __arm void __program_start();
т.е по адресу 0x00000000.

Код

            MEMMAP = 0x02; // Vectors in RAM;
            __program_start();

И пущай основная программа все заново инициализирует.

[Shkn]

Прямой вызов не совсем подходит. Была и такая идея. Т.к. основная прога написана для CARM, а там есть __RAM функции, то необходим вызов функции ?C?INIT (как я понимаю) до основной работы.

[amw]

Так одно - другому не мешает.
Пусть загрузчик инициализирует все что ему надо и прошивает.
Потом загрузчик, вероятно, должен перевести процессор в режим супервизора и стартонуть основную программу, которая выполнит уже свой стартап файл, настроит снова стеки, память, прерывания и все остальное.

[Shkn]

Заработал обработчик прерывания в основной проге.
Проверю работоспособность и после этого выложу на общее обозренее.

[Shkn]

 FWU.ZIP ( 74.18 килобайт ) Кол-во скачиваний: 211
 FWU_Test.zip ( 16.54 килобайт ) Кол-во скачиваний: 197

FWU - сам загрузчик. FWU_Test - тестовая программа.