[shkn 0]

Есть задачка: реализовать обновление прошивки LPC2148, например с SD карточки. На данные момент есть полноценная работающая прошивка. Есть код читающий с карточки и записывающий во FLASH. Сдесь работает как ожидается: проверяю что записалось с исходным бинарником - совпадает.

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

Как сделать корректную передачу управления?

Изменено 3 сентября, 2007 пользователем Shkn

[etoja 0]

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

[shkn 0]

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

 

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

[etoja 0]

Прошивалка должна располагаться в верхних секторах flash и не использовать прерывания.

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

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

[AndreyS 0]

Добрый день.

 

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

 

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

 

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

 

Удачи.

[OlegS 0]

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

но ежели этот вопрос так актуален :( ...

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

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

 

Так, что предлагаю о способах начала процесса мысль не развивать :)

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

[AndreyS 0]

Добрый день.

 

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

 

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

 

Удачи.

[shkn 0]

Добрый день всем.

Пояснения. 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. В какой-то момент написания кода было, что зависание происходило по завершению функции вывода отладочной строки (первое обращение к ней). После я внес ряд изменений в код и програ зашевелилась. Что именно помогло не определил (да и решил заработало - не тронь). Теперь зависание происходит в месте установки обработчика прерывания таймера. Буду вставлять отладочные сообщения и смотреть что именно вредит. Но скорее всего где-то промахнулся с настройкой векторов.

Изменено 4 сентября, 2007 пользователем Shkn

[Alechek 0]

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 0]

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

[amw 0]

Так одно - другому не мешает.

Пусть загрузчик инициализирует все что ему надо и прошивает.

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

[shkn 0]

Заработал обработчик прерывания в основной проге.

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

[shkn 0]

FWU.ZIPFWU_Test.zip

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