Баг ядра LPC2368? Опции

[GetSmart]

Проц LPC2368. Отладчик MT-Link v6.0. Прога под FreeRTOS. Компилятор CW 1.7 build 9

В майне всё как полагается - регистрируются треды и в конце вызывается vTaskStartScheduler(). Собственно во все треды управление залетает, до тех пор пока не встретится vTaskDelay(). Далее управление больше не возвращается. Баг возникает очень редко, но долговременно. Часто до выключения питания. Перепрограммирование проца баг не снимает.

Во всех тредах IRQ и FIQ разрешены (CPSR = x000001f). Расследование показывает, что не вызываются IRQ вообще, хотя FIQи прекрасно работают. Настройки таймера FreeRTOS правильные. Все регистры в норме, таймер тикает до установленного MATCH, потом опять с нуля. В VIC корректный адрес обработчика TIMER0 и приоритет = 1 (проверено). Все остальные регистры VIC тоже в порядке, причём в VICIRQStatus и VICRawIntr установлен запрос на прерывание от TIMER0, но оно туда не идёт. Брейкпоинт на 0x18 и на первой команде прерывания (IRQ) TIMER0 не срабатывает. IRQ реально не вызывается. Не могу выяснить проблему. Кстати, в начале майна стоит запрет прерываний в CPSR и команда VICIntEnClr = ~0;

ЗЫ. Одну странность заметил. В регистре VICRawIntr наблюдается включённый бит 3 (ARM Core Embedded ICE, DbgCommTX), причём этого же бита нет ни в VICIRQStatus ни в VICFIQStatus. Состояние первых 16-ти регистров VIC на картинке.

Забыл указать - прога без конца крутится в цикле for (;;) из функции static portTASK_FUNCTION( prvIdleTask, pvParameters ) периодически залетая в FIQ. В ней аналогично CPSR = x000001f.

В течении ближайшего часа могу продемонстрировать баг "вживую" на "телевизоре" TeamViewer. Реальным пацанам

Сообщение отредактировал GetSmart - Nov 12 2009, 10:36

Эскизы прикрепленных изображений

 

[GetSmart]

Может кто-нибудь знает, как сбрасываются запросы от Embedded ICE, DbgCommRx и Embedded ICE, DbgCommTX или сиё тайна NXP?

Поставил в начале main() вот это

Код

        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;

И всё заработало

Всвязи с этим возник вопрос - как при рестарте проги (программно или по JTAG) правильно сбрасывать VIC ? Чтобы ещё и счётчик приоритетов обнулялся. И для чего существует регистр VICSWPriorityMask, на который в мануале нет внятного объяснения?

И что за регистр, находящийся по адресу 0xFFFFF028 ? В мануале его нет, но на моей картинке в первом посте он есть!

Ещё прикол в том, что иногда подобный баг возникал прямо при первой отладке. Возможно когда отладчик прерывал работающую прогу прямо из прерывания FreeRTOS - Timer0 и все прерывания блокировались. Мля.

Сообщение отредактировал GetSmart - Nov 12 2009, 12:04

[VslavX]

Поставил в начале main() вот это

Код

        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;

И всё заработало

Посмотрел в свои исходники - у меня есть такая строчки

Код

for (i=0; i<16; i++) pVic->sVIC_VECTOR = 0;     // очищаем аппаратный стек вложений

Начал вспоминать и вспомнил - VIC в LPC поддерживает схему приоритетов прерываний - когда происходит прерывание, VIC запоминает в свое внутреннем аппаратном стеке текущий уровень приоритета и все прерывания с более низким приоритетом - блокируются, с более высоким - разрешаются и "нестяться". Вот этот внутренний стек и чистится многократной записью VIC_VECTOR. 16 - глубина стека, равная числу уровней приоритета.

Может кто-нибудь знает, как сбрасываются запросы от Embedded ICE, DbgCommRx и Embedded ICE, DbgCommTX или сиё тайна NXP?

Да нет, в LPC23 все стандартно, задокументировано в документации ARM на ядро ARM7TDMI.
Доступ к регистрам DCC, например, такой:

Код

#define hal_status_dcc()     __MRC(14, 0, 0, 0, 0)
#define hal_write_dcc(a)     __MCR(14, 0, a, 1, 0, 0)
#define hal_read_dcc()       __MRC(14, 0, 1, 0, 0)