Проблема LPC2214 UART+T0 IRQ Опции

[dmyl]

Прерывания два УАРТ и Таймер0, Т0 запускается периодически (отсчет таймаута), пока был один Т0 все работало, с делал прерывание на прием по УАРТу - какие-то глюки
Не получается разобраться в чем проблема, вот код
Инициализания прирываний:

static void DefDummyInterrupt(void)
{}

// IRQ exception handler. Calls the interrupt handlers.
#pragma vector=0x18
__irq __ramfunc void irq_handler(void)
{
void (*interrupt_function)();
unsigned long vector;

vector = VICVectAddr; // Get interrupt vector.
interrupt_function = (void(*)())vector;
// __enable_interrupt(); // Enable interrupts.
(*interrupt_function)(); // Call vectored interrupt function.

VICVectAddr = 0; // Clear interrupt in VIC.
}

//************************************************************
void init_IRQ(void)
{
// Setup interrupt controller.
VICProtection = 0;
// Disable all interrupts
VICIntEnClear = 0xffffffff;
VICDefVectAddr = (unsigned long)&DefDummyInterrupt;

// Setup timer callback function.
VICIntSelect=0x0; // Timer0 & UART select as IRQ.
VICVectAddr0 = (unsigned long)&UART0Interrupt;
VICVectCntl0 = 0x20 | VIC_UART0; // Enable vector interrupt for UART0.
VICVectAddr1 = (unsigned long)&Timer0Interrupt;
VICVectCntl1 = 0x20 | VIC_TIMER0; // Enable vector interrupt for timer 0.
VICIntEnable = 0x50; // Enable timer 0 & UART0 interrupt.
}

УАРТ - слот0
Т0- слот1
Процедура обработки для Т0 и УАРТа

// Timer0 interrupt handler
__ramfunc void Timer0Interrupt(void)
{
T0IR = 0xff; // Clear timer 0 interrupt line.
BF=0;
}

//******************************************************************
// Заполняет буфер приема
__ramfunc void UART0Interrupt()
{
while (U0LSR&0x1)
{
rx_buff[rx_end]=U0RBR;
rx_end=(rx_end+1)%RX_BUFF_LEN;
rx_len++;
}
}


Под житагом запускаю программу, передаю пакет данных. На него должен быть ответ, ответа нет. Останавливаю программу, пакет в буфер принимается верно, лишнего нет почему-то постоянно вылетает на DummyInterrupt, пока не тормознешь отладчиком ответа нет, после остановки отладчиком и снова запуска ответ передается.
Если точка останова на irq_handler то постоянно вылезают DummyInterrupt.
Вообщем чушь какая-то, отладить не получается стоит тормознуть отладчиком идут ответы на пакет.

Может есть пример рабочего кода для обработки приема по УАРТ?

[aaarrr]

Моя статистика наблюдений за "проблемами с прерываниями" на данном форуме, показывает, что в большинстве случаев они оказываются "проблемаим со стеком".

По-моему, описанная проблема - не вызывается обработчик прерывания - очень плохо вяжется с "проблемами со стеком".

[dmyl]

Проблему поборол, не понятно почему вычитывание данных UART до опустошения буфера (бит DR) не эквивалентно вычитыванию UART пока не снимется IIR. Прерывания УАРТа кроме RDA все запрещены.

Загадкой осталось такое поведение под отладчиком через JTAG.
Причем абсолютно точно, если висит окно просмотра регистров UART то прерывание сразу сбрасывалось, если окно закрыть то нет. Видимо чтение регистров сбрасывающих прерывания через JTAG в отладчике эквивалентно их чтению в программе. Вот и получается глюкодром.

[zltigo]

Проблему поборол, не понятно почему вычитывание данных UART до опустошения буфера (бит DR) не эквивалентно вычитыванию UART пока не снимется IIR.

Странный подход к делу - НЕ должно оно сниматся от того, что буфер опустошили а должно только после того, как Вы дали понять, что на него среагировали, а уж какяя там Ваша реакция должна быть -
читать буфер, не читать буфер, читать, но в следующий понедельник - не его дело.

Загадкой осталось такое поведение под отладчиком через JTAG.
Причем абсолютно точно, если висит окно просмотра регистров UART то прерывание сразу сбрасывалось, если окно закрыть то нет.

Какая "загадка" - висит отладчик и ЧИТАЕТ UART. Железу UART по барабану, кто его считал и дал знак,
что СРЕАГИРОВАЛ на прерывание.

[dmyl]

Странный подход к делу - НЕ должно оно сниматся от того, что буфер опустошили а должно только после того, как Вы дали понять, что на него среагировали, а уж какяя там Ваша реакция должна быть -
читать буфер, не читать буфер, читать, но в следующий понедельник - не его дело.

Что же тут странного? Или есть другой способ дать понять что среагировали на прерывание по приему УАРТа и сбросить его кроме как прочитать данные из RBR?

[zltigo]

Или есть другой способ дать понять что среагировали на прерывание по приему УАРТа и сбросить его кроме как прочитать данные из RBR?

Уж не знаю, как и обьяснить... Вы с железом когда нибудь до этого случая дело имели?
Контроллер прерывания и контроллер UART две РАЗНЫЕ вещи. Сброс источника прерывания в UART не является сигналом для снятия прерывания КОНТРОЛЛЕРОМ и наоборот. И это правильно(см. предыщее письмо)

[dmyl]

Уж не знаю, как и обьяснить... Вы с железом когда нибудь до этого случая дело имели?

Уважаемый, я бы попросил.....

Контроллер прерывания и контроллер UART две РАЗНЫЕ вещи. Сброс источника прерывания в UART не является сигналом для снятия прерывания КОНТРОЛЛЕРОМ и наоборот. И это правильно(см. предыщее письмо)

Если вы всетаки взгляните на код в начале ветки, то увидите что прерывание на контроллере сбрасывалось, а сброс источника прерывания на УАРТ выполнялся вычитываением буфера. Сбрасывая прерывание в VIC но не сбрасывая источник этого прерывания в контроллере УАРТа, вы его тутже получаете по новой, что я и имел удовольсвие наблюдать.
Поэтому вопрос как оказалось был в следующем (забудьте о VIC я про него и не спрашивал):
Почему сброс ИСТОЧНИКА прерывания по приему УАРТ путем чтения буфера по признаку DR и по признаку пока не снимется IIR не эквивалентны.

[zltigo]

Если вы всетаки взгляните на код в начале ветки, то увидите что прерывание на контроллере сбрасывалось

Виноват :-(, хотя лишнего там много, отформатировать не сочли нужным и код с разными 0x01 вместо поименованных констант тоже не способствует желанию читать.
Посмотрел. Все вышесказанное относится и к парочке IIR RBR. Вычитывание FIFO c отражением сего факта в LSR
не должно приводить с сбросу запроса прерывания равно как и сброс прерывания не должен приводить :-) к сбросу содержимого FIFO
Для полного счастья нужно и вычитать FIFO и считать IIR. Операции отдельные ибо я имею право читать FIFO когда и где мне заблагорассудится и это не должно приводить к "ичезновению" флага причины прерывния в IIR наоборот - считать IIR и решив, что мне сейчас не до этого - уйти не вычитывая FIFO.

Сие абослютно логично и описано в документации.

[dmyl]

Для полного счастья нужно и вычитать FIFO и считать IIR.
....
Сие абослютно логично и описано в документации.

Простите, но смотрю в таблицу #81 UART0 Interrupt Handling мануала по 2214, нахожу нужные мне две строчки для IIR=0100 и 1100 (данные доступны и таймаут по приему), смотрю на заветную колонку INTERRUPT RESET, там черным по англицки написано U0RBR READ, и ни слова что нужно читать IIR. А выходит что не читая IIR а обходясь только LSR и RBR прерывание не сбрасывается, в докции в самом начале описания обработки прерывания прямо в тексте мелким шрифтом есть что-то похожее на то что надо IIR всеже надо прочитать до выхода из обработчика.

А насчет дефайнов - сорри, я код причесывал специально чтобы поменьше в ветку вываливать текста, кроме того я тег не поставил чтобы форматироание сохранилось все время забываю какой он.

[zltigo]

...там черным по англицки написано U0RBR READ, и ни слова что нужно читать IIR.
А выходит что не читая IIR а обходясь только LSR и RBR прерывание не сбрасывается,
в докции в самом начале описания обработки прерывания прямо в тексте мелким шрифтом есть что-то похожее на то что надо IIR всеже надо прочитать до выхода из обработчика.

Да нормальный там шрифт :-) и написано вполне "в лоб":

Код

Interrupts are handled as described in Table 9–105. Given the status of U0IIR[3:0], an
interrupt handler routine can determine the cause of the interrupt and how to clear the
active interrupt. The U0IIR must be read in order to clear the interrupt prior to exiting the
Interrupt Service Routine.

Ну а самое главное, к чему я собственно "привязался" это то, что такое поведение является правильным, логичным и привычным для железок которые позволяют реализовывать идеи "посложнее".

Еще результаты чтения:
Выкинуть промежуточный/первичный обработчик прерывания за полной его ненадобностью.
Ну и размещения кода в RAM не слишком уж ускоряет - MAM у LPC неплохой, зато чрезмерное увлечение подпрограммами уж точно тормозит.

По-моему, описанная проблема - не вызывается обработчик прерывания - очень плохо вяжется с "проблемами со стеком".

Прочитайте - там не "не вызывается" там:

Через какое-то время перестают вызываться обработчики прерываний,

И я говорил о статистике, голой статистике - ввиду отсутствия информации к размышлению.

[dmyl]

Еще результаты чтения:
Выкинуть промежуточный/первичный обработчик прерывания за полной его ненадобностью.

Это понятно, но ресурсов хватает выше крыши, а так СИ код прозрачен и понятен, врубать же ассемблерные куски лишние хлопоты. Я когда то давно спрашивал как это можно изящно изобразить на СИ, других вариантов не подсказали.