Перейти к содержанию
    

будут ли корректно работать прерывания?
При возникновении исключения процессор переходит на адреса 0-0x3f. Куда вы положите вектора - ему все равно. Он будет переходить по заложенным в него железно адресам 0...0x3f. Один из возможных вариантов решения вашей проблемы - remap. Читайте про него в документации на ARM7 и ищите по форуму.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос в продолжении темы IAP: команда 56 - сравнение секторов. насколько быстро и надёжно всё это происходит, например, для сектора в 4кб? Вообще, в принципе какая вероятность записать с ошибкой сектор по IAP?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос в продолжении темы IAP: команда 56 - сравнение секторов. насколько быстро и надёжно всё это происходит, например, для сектора в 4кб? Вообще, в принципе какая вероятность записать с ошибкой сектор по IAP?

 

Записывайте в конец сектора свою 32-битную контрольную сумму.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если сравнение гарантирует 100% выявление ошибок, то за чем лишнии действия? Однако, кто ответит что быстрее и надёжнее - вычисление 32-битной(16-битной) контрольной суммы или стандартная операция сравнения IAP?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если сравнение гарантирует 100% выявление ошибок, то за чем лишнии действия? Однако, кто ответит что быстрее и надёжнее - вычисление 32-битной(16-битной) контрольной суммы или стандартная операция сравнения IAP?

а у IAP есть операция сравнения? Сравнивать надо самим, благо весь флеш доступен на чтение.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Но это - для профессионального оборудования.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если сравнение гарантирует 100% выявление ошибок, то за чем лишнии действия? Однако, кто ответит что быстрее и надёжнее - вычисление 32-битной(16-битной) контрольной суммы или стандартная операция сравнения IAP?

 

Какая-то у вас тяга к быстрым вычислениям :) Для чего?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Но это - для профессионального оборудования.

контрольная сумма будет обязательно будет, точнее она есть (16). И данные будут записываться уже достоверные, то есть требуется сличить записанные и записываемые данные. Совет KRS я считаю правильным и не пременно им воспользуюсь. Уцепился сразу за эту команду сравнения IAP, казалось что специально написанная функция должна быть оптимизированна и прочее :)

 

Какая-то у вас тяга к быстрым вычислениям Для чего?

Кроме записи по IAP много чего ещё должно работать, и запись далеко не приоритетная задача, и чем меньше времени она будет крутиться тем лучше. Вообще запись данных требуется проводить не заметно для остальных процессов, что сильно затрудняет обязательное требование запрета прерываний. Поэтому и стараюсь точно определить все временные рамки и по возможности их минимизировать, в частности на проверку данных. Большие трудности создаёт возможность неудачной записи (вероятность ошибки, думаю, никому неизвестна) 400 мс для стирания и повторной записи у меня нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Большие трудности создаёт возможность неудачной записи (вероятность ошибки, думаю, никому неизвестна) 400 мс для стирания и повторной записи у меня нет.

 

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

По вине пропадания питания в момент записи - возможна.

Запись во внутреннюю память процессора - монопольный процесс. Если это не устраивает - используйте внешнюю FRAM.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Запрет прерываний - требование не обязательное. Обязательное требование - отсутствие доступа к Flash. Прерывания могут спокойно работать в RAM.

The on-chip flash memory is not accessible during erase/write operations. When the user

application code starts executing the interrupt vectors from the user flash area are active.

The user should either disable interrupts, or ensure that user interrupt vectors are active in

RAM and that the interrupt handlers reside in RAM, before making a flash erase/write IAP

call. The IAP code does not use or disable interrupts.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Запрет прерываний - требование не обязательное. Обязательное требование - отсутствие доступа к Flash. Прерывания могут спокойно работать в RAM.
угу, читал. для меня обязательное :unsure:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Прошу совета по сабжу. Я использую LPC2214. C 0 по 0x1FFF расположен загрузчик, с 0x2000 приложение. Все работате отлично. Решил я написать приложение, которое будет обновлять загрузчик. То есть образ нового загрузчика расположен по адресу 0x6000. После заливки, это приложение через IAP должно стереть сектор где расположен старый загрузчик, т.е. сектор 0 и скопировать туда образ нового загрузчика с адреса 0x6000. При отладке я пробовал копировать в область с адресом 0x8000 - проблем не было. В боевом варианте после стирания сектора 0 система зависает. Если посмотреть память флэш меджиком, видно что сектор 0 стерт. Почему система отваливается, ума не приложу. Вроде все сконфигурировано правильно - в опциях кейла и стартапе задал, что прошивка начинается с адреса 0x2000. Может есть какие-то особенности IAP - типа клинит соседний сектор? JTAG смотрел - показалось, что коллапс наступает после восстановления прерываний.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну дык если стёрли нулевой сектор, то стёрли и вектора прерываний по адресам 00-3f. Либо делайте ремап на ОЗУ (заполнив вектора 0x40000000-0x4000001f) и уже потом разрешайте прерывания, либо не разрешайте прерывания вообще до окончательной перезаписи нулевого сектора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я думал, что если начало прошивки сконфигурировано с адреса 0x2000, то и вектора там же. А как же она работает в обычном режиме? Там же сидит загрузчик как отдельное приложение. Получается для ремапа, мне нужно в начало рамы копирнуть область векторов с 0 флеши и задать ремап?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...