У NXP есть - LPC288x. 8K кэша.


Часто в векторе IRQ стоит что-то вроде LDR PC,[PC, #-xxx]. Оптимальнее будет ложный нулевой адрес "ловить" в ResetVector-е по значению младших пяти бит CPSR, равных режиму IRQ.

Сообщение отредактировал GetSmart - Nov 16 2015, 11:47

Посмотрел еще раз в свежайшие errata - увы, ничего подобного не описано.

Очень бы хотелось взглянуть на то, что в uCOS написано. Это было просто в исходниках откомментировано, или какой то документ?

Описанной ситуации соответствует.
Явную заплатку не делал - стучал в бубен в месте опроса-сброса SPI прерывания. Но хотелось-бы явного понимания что надо делать.




Делал подобное для локализации проблемы вылета, но просто возвратиться не подумал. Пожалуй это вариант.

Я с LPC23xx последний раз работал уже неск. лет назад, а ещё раньше я переписал весь системный обработчик IRQ на свой собственный.
Так что из оригинального там остались только комменты о проверке на ложное IRQ с соответствующим кодом. Надо старые архивы поднимать если там что-то сохранилось.
Ну или скачать порт uCOS для ARM7 и посмотреть код стандартного обработчика IRQ.
Документ, кстати, тоже был, находится гуглом по фразе "spurious interrupts":
http://www.nxp.com/documents/application_note/AN10414.pdf

Хорошо. Посмотрю. Но если говорить об этом:

То это НЕ ТО о чем говорим. Заглушка на VIC Default Vector Address, естественно, стоит. То, что происходит, происходит по другому механизму - вектор считывается именно нулевой, хотя Default прописан. Вылетов по запрограммированному Default тоже можно добится, это я к тому, что эта ветка работает, но на ее фоне прилетает и нулевой вектор.
Появилось при использовании SPI Slave.

Зашел на микриум. Скачал порт - для LPC23xx. Убийственный по объему обработчик, но в конце действительно есть "Make sure we don't have a NULL pointer", но это собственно и все из комментариев. Отчего так делают объяснений нет.
Кстати, действий при считывании нулевого вектора тоже никаких - даже ACK контроллеру не делают - просто вернулись и все. Ну и VICDefVectAddr они НЕ УСТАНАВЛИВАЮТ вообще, так что это объясняет впихивание во все их "макроме" еще и проверки вектора на NULL.

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


Странно... Я по своему коду вижу, что ACK я даю на нулевой вектор также как на валидный, просто не вызываю никакой прикладной обработчик ISR. И проверка на NULL не в конце ISR, а в начале.
Тем не менее множество наших счётчиков э-энергии на LPC2378 выпускаются уже несколько лет (уже наверное многие тысячи), работают в непрерывном круглосуточном режиме и проблем с прерываниями вроде не возникает.
Сама проверка - ничего страшного - всего одна доп. команда CMP R0, #0.

Прямо противоположное мнение . Просто вытеснение задач именно uCOS сделано конкретно через анус, ну а массовые вложеные вообще не нужны при операционке, тем более есть FIQ. То, как сделано у ARM7 так-же сделано у старших "A" кортексов явно заточеных под операционки, ну а для мелких "M" кортесов в которых справедливо предположили, что народ пойдет писать после всяких восьмибитовиков и в силе восьмибитовиков, сделали "удобный" NVIC.

На фоне ужасно огромого обработчика перывания, как у uCOS - несомненно да.

Дошли руки. Заплатку на NULL вектор вставил по варианту GetSmart на вектор сброса:

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

EMCStaticConfig0 bit 19

К чему это было? Разговор не о EMC.

Разговор был о кэшировании записи

а.... ок. это on-chip memory... да, тогда мимо