Сергей Борщ 143 24 февраля, 2009 Опубликовано 24 февраля, 2009 · Жалоба будут ли корректно работать прерывания?При возникновении исключения процессор переходит на адреса 0-0x3f. Куда вы положите вектора - ему все равно. Он будет переходить по заложенным в него железно адресам 0...0x3f. Один из возможных вариантов решения вашей проблемы - remap. Читайте про него в документации на ARM7 и ищите по форуму. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TanT 0 26 февраля, 2009 Опубликовано 26 февраля, 2009 · Жалоба Вопрос в продолжении темы IAP: команда 56 - сравнение секторов. насколько быстро и надёжно всё это происходит, например, для сектора в 4кб? Вообще, в принципе какая вероятность записать с ошибкой сектор по IAP? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
etoja 0 26 февраля, 2009 Опубликовано 26 февраля, 2009 · Жалоба Вопрос в продолжении темы IAP: команда 56 - сравнение секторов. насколько быстро и надёжно всё это происходит, например, для сектора в 4кб? Вообще, в принципе какая вероятность записать с ошибкой сектор по IAP? Записывайте в конец сектора свою 32-битную контрольную сумму. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TanT 0 26 февраля, 2009 Опубликовано 26 февраля, 2009 · Жалоба Если сравнение гарантирует 100% выявление ошибок, то за чем лишнии действия? Однако, кто ответит что быстрее и надёжнее - вычисление 32-битной(16-битной) контрольной суммы или стандартная операция сравнения IAP? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KRS 1 26 февраля, 2009 Опубликовано 26 февраля, 2009 · Жалоба Если сравнение гарантирует 100% выявление ошибок, то за чем лишнии действия? Однако, кто ответит что быстрее и надёжнее - вычисление 32-битной(16-битной) контрольной суммы или стандартная операция сравнения IAP? а у IAP есть операция сравнения? Сравнивать надо самим, благо весь флеш доступен на чтение. Контрольную сумму вычислять вообще смысла нет! Потому что все равно надо будет считывать все данные, чем производить с ними операции проще сравнить с оригиналом. Да и скорость обработки данных не сопоставима со скоростью их передачи для прошивки и временем прошивки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
etoja 0 26 февраля, 2009 Опубликовано 26 февраля, 2009 · Жалоба Контрольная сумма нужна обязательно, поскольку в момент программирования может выключиться питание прибора. Но это - для профессионального оборудования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Denisvak 0 26 февраля, 2009 Опубликовано 26 февраля, 2009 · Жалоба Если сравнение гарантирует 100% выявление ошибок, то за чем лишнии действия? Однако, кто ответит что быстрее и надёжнее - вычисление 32-битной(16-битной) контрольной суммы или стандартная операция сравнения IAP? Какая-то у вас тяга к быстрым вычислениям :) Для чего? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TanT 0 2 марта, 2009 Опубликовано 2 марта, 2009 · Жалоба Контрольная сумма нужна обязательно, поскольку в момент программирования может выключиться питание прибора. Но это - для профессионального оборудования. контрольная сумма будет обязательно будет, точнее она есть (16). И данные будут записываться уже достоверные, то есть требуется сличить записанные и записываемые данные. Совет KRS я считаю правильным и не пременно им воспользуюсь. Уцепился сразу за эту команду сравнения IAP, казалось что специально написанная функция должна быть оптимизированна и прочее :) Какая-то у вас тяга к быстрым вычислениям Для чего? Кроме записи по IAP много чего ещё должно работать, и запись далеко не приоритетная задача, и чем меньше времени она будет крутиться тем лучше. Вообще запись данных требуется проводить не заметно для остальных процессов, что сильно затрудняет обязательное требование запрета прерываний. Поэтому и стараюсь точно определить все временные рамки и по возможности их минимизировать, в частности на проверку данных. Большие трудности создаёт возможность неудачной записи (вероятность ошибки, думаю, никому неизвестна) 400 мс для стирания и повторной записи у меня нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
etoja 0 2 марта, 2009 Опубликовано 2 марта, 2009 · Жалоба Большие трудности создаёт возможность неудачной записи (вероятность ошибки, думаю, никому неизвестна) 400 мс для стирания и повторной записи у меня нет. Неудачная запись по вине процессора никогда не встречалась. По вине пропадания питания в момент записи - возможна. Запись во внутреннюю память процессора - монопольный процесс. Если это не устраивает - используйте внешнюю FRAM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HARMHARM 0 2 марта, 2009 Опубликовано 2 марта, 2009 · Жалоба Вообще запись данных требуется проводить не заметно для остальных процессов, что сильно затрудняет обязательное требование запрета прерываний. Запрет прерываний - требование не обязательное. Обязательное требование - отсутствие доступа к 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TanT 0 2 марта, 2009 Опубликовано 2 марта, 2009 · Жалоба Запрет прерываний - требование не обязательное. Обязательное требование - отсутствие доступа к Flash. Прерывания могут спокойно работать в RAM. угу, читал. для меня обязательное :unsure: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Denisvak 0 3 марта, 2009 Опубликовано 3 марта, 2009 · Жалоба Сергей Борщ и etoja Спасибо Вам за помощь все работает :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vesago 0 15 марта, 2009 Опубликовано 15 марта, 2009 · Жалоба Прошу совета по сабжу. Я использую LPC2214. C 0 по 0x1FFF расположен загрузчик, с 0x2000 приложение. Все работате отлично. Решил я написать приложение, которое будет обновлять загрузчик. То есть образ нового загрузчика расположен по адресу 0x6000. После заливки, это приложение через IAP должно стереть сектор где расположен старый загрузчик, т.е. сектор 0 и скопировать туда образ нового загрузчика с адреса 0x6000. При отладке я пробовал копировать в область с адресом 0x8000 - проблем не было. В боевом варианте после стирания сектора 0 система зависает. Если посмотреть память флэш меджиком, видно что сектор 0 стерт. Почему система отваливается, ума не приложу. Вроде все сконфигурировано правильно - в опциях кейла и стартапе задал, что прошивка начинается с адреса 0x2000. Может есть какие-то особенности IAP - типа клинит соседний сектор? JTAG смотрел - показалось, что коллапс наступает после восстановления прерываний. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 15 марта, 2009 Опубликовано 15 марта, 2009 · Жалоба Ну дык если стёрли нулевой сектор, то стёрли и вектора прерываний по адресам 00-3f. Либо делайте ремап на ОЗУ (заполнив вектора 0x40000000-0x4000001f) и уже потом разрешайте прерывания, либо не разрешайте прерывания вообще до окончательной перезаписи нулевого сектора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vesago 0 15 марта, 2009 Опубликовано 15 марта, 2009 · Жалоба Я думал, что если начало прошивки сконфигурировано с адреса 0x2000, то и вектора там же. А как же она работает в обычном режиме? Там же сидит загрузчик как отдельное приложение. Получается для ремапа, мне нужно в начало рамы копирнуть область векторов с 0 флеши и задать ремап? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться