[GetSmart 0]

У ARM7TDMI нет ни кэша ни буфера записи.

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

 

Заключался он в том, что при чтении адреса вектора прерывания из VIC, мог считаться ноль - это ложное прерывание.

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

Изменено 16 ноября, 2015 пользователем GetSmart

[zltigo 1]

Давно уже работал с LPC2378, но вроде смутно помнится, что был подобный баг в контроллере прерываний. И он был описан в еррата.

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

И даже в соотв. порту uCOS было указано.

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

Если это конечно он.

Описанной ситуации соответствует.

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

 

 

 

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

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

 

[jcxz 199]

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

Я с LPC23xx последний раз работал уже неск. лет назад, а ещё раньше я переписал весь системный обработчик IRQ на свой собственный.

Так что из оригинального там остались только комменты о проверке на ложное IRQ с соответствующим кодом. Надо старые архивы поднимать если там что-то сохранилось.

Ну или скачать порт uCOS для ARM7 и посмотреть код стандартного обработчика IRQ.

Документ, кстати, тоже был, находится гуглом по фразе "spurious interrupts":

http://www.nxp.com/documents/application_note/AN10414.pdf

[zltigo 1]

Ну или скачать порт uCOS для ARM7 и посмотреть код стандартного обработчика IRQ.

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

Документ, кстати, тоже был, находится гуглом по фразе "spurious interrupts":

http://www.nxp.com/documents/application_note/AN10414.pdf

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

Появилось при использовании SPI Slave.

 

[zltigo 1]

Так что из оригинального там остались только комменты о проверке на ложное IRQ с соответствующим кодом. Надо старые архивы поднимать если там что-то сохранилось.

Ну или скачать порт uCOS для ARM7 и посмотреть код стандартного обработчика IRQ.

Зашел на микриум. Скачал порт - для LPC23xx. Убийственный по объему обработчик, но в конце действительно есть "Make sure we don't have a NULL pointer", но это собственно и все из комментариев. Отчего так делают объяснений нет.

Кстати, действий при считывании нулевого вектора тоже никаких - даже ACK контроллеру не делают - просто вернулись и все. Ну и VICDefVectAddr они НЕ УСТАНАВЛИВАЮТ вообще, так что это объясняет впихивание во все их "макроме" еще и проверки вектора на NULL.

[jcxz 199]

Зашел на микриум. Скачал порт - для LPC23xx. Убийственный по объему обработчик,

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

Но ISR конечно там можно хорошо оптимизировать, что я и сделал.

 

Кстати, действий при считывании нулевого вектора тоже никаких - даже ACK контроллеру не делают - просто вернулись и все. Ну и VICDefVectAddr они НЕ УСТАНАВЛИВАЮТ вообще, так что это объясняет впихивание во все их "макроме" еще и проверки вектора на NULL.

Странно... Я по своему коду вижу, что ACK я даю на нулевой вектор также как на валидный, просто не вызываю никакой прикладной обработчик ISR. И проверка на NULL не в конце ISR, а в начале.

Тем не менее множество наших счётчиков э-энергии на LPC2378 выпускаются уже несколько лет (уже наверное многие тысячи), работают в непрерывном круглосуточном режиме и проблем с прерываниями вроде не возникает.

Сама проверка - ничего страшного - всего одна доп. команда CMP R0, #0.

[zltigo 1]

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

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

Сама проверка - ничего страшного - всего одна доп. команда CMP R0, #0.

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

[zltigo 1]

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

__start_entry:
            push     { r0 }
            mrs        r0, cpsr
            and     r0, r0, #MODE_MASK
              cmp     r0, #IRQ_MODE
            bneq       __start
            pop     { r0 }
            b        zero_vector_handler
__start:

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

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

[slavka012 0]

EMCStaticConfig0 bit 19

[zltigo 1]

EMCStaticConfig0 bit 19

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

[slavka012 0]

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

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

 

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