Определение размера 0-го сектора в LPC2000, есть ли какой-нибудь способ без вызова IAP Опции

[Ykidia]

Здравствуйте!

У меня вопрос: есть ли какие-нибудь трюки определения размера 0-го сектора в Philips LPC2000 без вызова IAP?
Например, в LPC2138 размер равен 4k, а в LPC2214 - 8k. Собственно, варианта на данной архитектуре всего два.

Зачем это нужно. Есть большой проект под IAR EWARM 4.41. Там свой cstartup, который располагался, как ему и положено, в 0-м секторе, так что любые изменения обработчиков исключений в cstartup'е соответственно и адекватно отражались на работе всего проекта.
Теперь решили сделать свой загрузчик. Вообще-то, сделан он уже давно, но сейчас решили поместить его в 0-й сектор, а основной проект "подвинуть" на сектор вверх - расположить его с 1-го сектора. Это для того, чтобы при перепрошивке LPC2000 данным загрузчиком не было сбоев, связанных с перепрошивкой 0-го сектора.
Т.е., основной проект получает по Ethernet новую firmware самого себя (простой бинарник, включающий в себя также и загрузчик в 0-м секторе), записывает ее в Data Flash AT45DB161x, взводит сигнатуру в Data Flash и перезапускает контроллер. При перезапуске первым получает управление (после Philips'овского bootloader'а) загрузчик в 0-м секторе, который читает и проверяет сигнатуру из Data Flash на предмет перепрошивки. Если надо перепрошиваться, то проверяется другая сигнатура на предмет использования внешнего прошивальщика. Если нужно использовать внешний, то он загружается из Data Flash во внутренний RAM LPC2000, ему передается управление, далее он перепрошивает контроллер полностью, включая 0-й сектор, обновляет сигнатуру (мол, прошито) и перезапускает контроллер.
Если же внешний прошивальщик использовать не нужно, то загрузчик сам перепрошивает контроллер, но исключая 0-й сектор. Затем он обновляет сигнатуру и передает управление на 1-й сектор, где располагается основной проект.

Такая схема позволяет обойтись без сбоев в режиме перепрошивки без 0-го сектора. Загрузчик запустился, определил ID контроллера, сравнил новую прошивку с текущим содержимым Flash контроллера, составил битовое поле различных секторов, перепрошил только те сектора, которые нуждаются в обновлении, и передал управление дальше, главному проекту. Однако это накладывает некоторые ограничения. Например, обработчики исключений/прерываний теперь находятся в загрузчике, а не в основном проекте (и поэтому его cstartup уже "не катит"). Чтобы передать управление на обработчики основного проекта, нужно знать размер 0-го сектора: 4k или 8k.
Я упомянул, что по старту загрузчика определяется ID контроллера, чтобы знать карту секторов - для перепрошивки и просто для того, чтобы корректно передать управление основному проекту. В конце концов, нужно где-то хранить всего 1 бит, хотя желательно байт (для уверенности, что ID был прочитан), однако неизвестно, как распределяет память основной проект и, соответственно, нет гарантии, что нужный нам байт/бит не будет затерт.
Если делать каждый раз при входе в исключение/прерывание вызов IAP - это долго, да и потом полученный ID надо еще дешифровать, чтобы узнать размер сектора.

Отсюда вопрос - возможно ли как-то сразу при входе в исключение/прерывание узнать, какой размер сектора? Может, где-то есть какой-нибудь битик, либо может его можно где-то хранить?

P.S. Сейчас основной проект использует работу с исключениями при MEMMAP = 2, что освобождает от данного ограничения. Но хотелось бы сделать максимально совместимо (типа задела на будущее).

Сообщение отредактировал Ykidia - Apr 4 2007, 14:09

[Ykidia]

Здравствуйте! Спасибо за подробный ответ.

В начале первого сектора располагается копия векторов приложения, которая будет скопирована в адреса 0x40000000 - 0x40000040 а после MEMMAP = 2 окажется и в адресах 0x00 - 0x3F , причем линкуется она так, чтобы работала после копирования

В том-то и дело, что не хотелось бы привязываться к MEMMAP = 2. Нужно чтобы работало при MEMMAP = 1.

Разработчику основной программы надо помнить только три вещи - линковать вектора указанным выше способом, не трогать memmap, настраивать всю периферию

Обычно умудрялись не запомнить простые вещи - например, что для внешнего прошивальщика необходимо также прописывать св-ва watchdog'а (в зависимости от платы могли быть 3 разных варианта watchdog'а).
Ради того же я потратил немало времени, чтобы используемую в загрузчике периферию перед передачей управления дальше восстанавливать в состояние как после сброса. Особенно проблемы были с выключением PLL и т.п. Оказалось, там есть тонкости, описания которых я нигде не видел...

А размер нулевого сектора вы задаете при компиляции загрузчика (#define APP_START 0x00002000). Вы ведь точно знаете, в какой процессор вы его будете заливать.

А вот и нет! Мне достаточно того, что в файле линкера иногда можно указать границу для уверенности в том, что код загрузчика ее не достигает.

Если хотите, могу скинуть Вам весь проект куда-нибудь. Вдруг пригодится. А то я столько с этим намучился

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

В том-то и дело, что не хотелось бы привязываться к MEMMAP = 2. Нужно чтобы работало при MEMMAP = 1.

Но зачем??? Хотя вопрос риторический, но думаю вы создаете себе лишние трудности.

Обычно умудрялись не запомнить простые вещи - например, что для внешнего прошивальщика необходимо также прописывать св-ва watchdog'а (в зависимости от платы могли быть 3 разных варианта watchdog'а).

А что, прошивка не проходит какое-то тестирование перед отправкой в производство?

Ради того же я потратил немало времени, чтобы используемую в загрузчике периферию перед передачей управления дальше восстанавливать в состояние как после сброса. Особенно проблемы были с выключением PLL и т.п. Оказалось, там есть тонкости, описания которых я нигде не видел...

Вот это было бы интересно - я аналогичное делаю в .mac-файле отладчика по команде reset, но пока не достиг совершенства.

А вот и нет! Мне достаточно того, что в файле линкера иногда можно указать границу для уверенности в том, что код загрузчика ее не достигает.

А что мешает сделать несколько файлов линкера для разных кристаллов?

Если хотите, могу скинуть Вам весь проект куда-нибудь. Вдруг пригодится. А то я столько с этим намучился

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

Да, и идеи насчет определения размера 0-го сектора без вызова IAP продолжают приниматься. Интересно стало.

Сотрите первый сектор и посмотрите что стерлость... хотя это тоже через IAP. А почему без IAP? По первому сообщению я понял, что вы не хотите каждый раз в исключении вызывать IAP. Но что мешает один раз вызвать IAP, сохранить полученное значение и дальше пользовать его? В документации иного способа кроме IAP не описано, поэтому если вы и найдете какое-либо "левое" решение, никаких гарантий что оно будет работать на другом типе кристалла или даже на этом же процессоре другой партии.