Определение размера 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]

вы создаете себе лишние трудности.

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

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

Проходит, еще как, вот оттуда и выяснилось, хотя когда Вы посмотрите исходники, то увидите, что это не мешает загрузчику доделать свое дело до конца (при условии, что период watchdog'а находится в пределах нескольких секунд).

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

Они есть. Только неизвестно, что и как повернется потом.

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

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

Но что мешает один раз вызвать IAP, сохранить полученное значение и дальше пользовать его

Сохранить куда? Только во flash, в известное место в своем секторе, а это по сути то же самое. Уславливаться с разработчиком о выделенном месте в ОЗУ? Тогда мне проще оставить все как есть.

В документации иного способа кроме IAP не описано, поэтому если вы и найдете какое-либо "левое" решение, никаких гарантий что оно будет работать на другом типе кристалла или даже на этом же процессоре другой партии.

Вы правы. Но я подумал, вдруг чего упустил или есть какие-нибудь косвенные методы определения применяемой flash?