2016-05-19 8 views
0

Я работаю над встроенным устройством, которое использует Aurix TC234. Программное обеспечение My (AUTOSAR), которое работает на нем, должно выполнить некоторые проверки во время запуска в определенном диапазоне адресов ПЗУ.Встраиваемый: доступ к неписаному содержимому ROM-адреса

Данные, которые необходимо проверить, не записываются во время мигания моего программного файла hex. Это означает, что диапазон адресов должен быть записан до того, как мое программное обеспечение будет мигать на этом устройстве.

В худшем случае: Кто-то забывает высветить этот диапазон адресов. Мое программное обеспечение мигает, и во время запуска происходит доступ к памяти. В этом случае возникает ловушка.

Мой вопрос: Есть ли безопасный способ проверить этот конкретный диапазон адресов ПЗУ, если он был написан или нет? Можно ли обрабатывать такой ловушку?

+0

есть ли причина не добавлять дополнительный раздел, который будет охватывать диапазон требуемых адресов с флэш-содержимым по умолчанию? и позже написать дополнительные данные? – Blueman

+0

@Blueman Порядок мигания фиксирован. Первые данные должны быть свернуты, а не программное обеспечение. По умолчанию флэш-контент в моем программном обеспечении перезаписывал правильно свернутые дополнительные данные. Я не знаком с исправлениями ECC. Возможно ли повлиять на ECC? Могу ли я деактивировать его для определенного диапазона адресов в ПЗУ? – Ferhat

+0

Я не знаком с этой версией микропрограммы, и я не работал напрямую с ловушками, но, насколько я помню, TC27X и TC29X имели возможность правильно выйти из ловушек ECC и не иметь возможности отключить ECC для определения диапазона или вообще , Трудно представить больше деталей, поскольку каждый выпущенный Infineon документ конфиденциальен, и я имею доступ к нему только в офисе. – Blueman

ответ

2

После нескольких проверок, для TC29X потока с ECC ошибкой для ROM может быть обработан, как показано ниже:

  • позволяет СМ аварийных сигналам
  • поймать ECC ошибки в ISR из СМ
  • магазина флаг не в инициализации ОЗУ площадь
  • не
  • SW сброса должна быть вызвана (без выхода из ловушки для ECC)
  • в значении флага проверки следующего запуска

Надеюсь, что эта помощь и подобное решение будут доступны на вашем микро.

+0

Я попробую. Благодаря! – Ferhat

0

Я не знаком с TC234, но я был бы поражен, если бы доступ к неписанной вспышке на любом встроенном устройстве вызовет ловушку. Единственное различие между письменной и неписаной вспышкой должно заключаться в том, что последний должен иметь все написанные (при условии, что вспышка начнет стираться). Вы должны просто проверить свой блок данных для всех байтов 0xFF.

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

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

+0

Мое программное обеспечение основано на AUTOSAR.Мне нужно снова проверить, кто вызывает эту ловушку. Есть ли у вас опыт работы с AUTOSAR? Я использую фиксированный адрес памяти для доступа к памяти, что определенно правильно. – Ferhat

+0

У этого семейства Aurix есть область ОЗУ и ПЗУ, защищенная ECC, поэтому доступ к не инициализированной области (в этом контексте не мигает) вызовет ловушку, как описано @Ferhat. – Blueman

+0

В этом случае я стою исправленным и отвечу на мой ответ. Я удалю его, но оставьте его, чтобы эти комментарии не были потеряны. – DoxyLover