Господа!

Помогите, пожалуйста, разобраться в следующей проблеме.

Написал функции для работы с CAN. Приём и передача работают через прерывания. Одно прерывание обслуживает как приём, так и передачу.Тут у меня вопросов нет.

Потом захотелось мне обрабатывать пассивную ошибку(passive error). Для чего при настройке CAN установил в единицу бит EPIE в регистре CANIER и в обработчике прерывания добавил анализ бита EPI в регистре CANICR. Написал также простейшуюфункцию, посылающую пакеты через заданный интерфейс.После прошивки питание отключил, выдернул кабель CAN и ...

Ничего не произошло. Обработчик прерывания не вызывался. Чтение fucking manual пока что ничего не дало. Что я деляю не так?

укажите хотя бы процессор, зачем догадываться. вроде не атмел а ? наверное НХП ?

Нда, а самое главное и забыл.

Процессор - LPC2294.

писал я HAL драйвер на LPC с месяц назад. Вроде должно там работать все.
Приведите фрагмент обработчика прерывания и то, как вы настраиваете VIC

Точно не помню, но вроде как у меня с EPI валились прерывания непрерывно тысячами.
Сейчас оставил RIE, TIEх, EIE. Т.е. EIE для обработки ошибок мне хватает.

настройка CAN


#define INT_ENABLE(sel, bit) \
{ \
INT_SELECT_ ##sel(bit); \
VICIntEnable = bit; \
}

void init_can()
{
.
.
tmp = 0;
pISR_CAN1RX = (u32_t)rx_isr_ptr;
INT_ENABLE( IRQ, (1<<VIC_CAN1_RX) );

pISR_CAN1TX = (u32_t)tx_isr_ptr;
INT_ENABLE( IRQ, (1<<VIC_CAN1_TX) );
CAN1IER = BIT_0|BIT_1|BIT_3|BIT_5|BIT_7;

}


обработчик прерывания от CAN1


void can1_isr(void)
{ u32_t status;

status = CAN1ICR;
if( status & BIT_0)
{// приём пакета
}
if( status & BIT_1 )
{ //ï передача
}
if( status & BIT_5 )
{// ïпассивная ошибка
}
if( status & BIT_7 )
{ // bus-off
}
VICVectAddr =0;
}


Мне, кстати, не очень нравится следующая фраза из руководства пользователя(стр.203):

Interrupts
Each CAN Controller produces 3 interrupt requests, Receive, Transmit, and “other status”. The Transmit interrupt is the OR of
the Transmit interrupts from the three Tx Buffers. Each Receive and Transmit interrupt request from each controller is assigned
its own channel in the Vectored Interrupt Controller (VIC), and can have its own interrupt service routine. The “other status”
interrupts from all of the CAN controllers, and the Acceptance Filter LUTerr condition, are ORed into one VIC channel.

Что следует понимать под выражением "other status" interrupt" ? И что в обработчике этого прерывания должно выполняться?

Так вы прерывание статуса не задействовали.
Все прерывания статуса от всех CAN контролеров объединены по ИЛИ на одно прерывание.
Дурь, конечно, руки бы оборвать за эту поделку, но оно так реализовано, чего теперь.

Это которое с номером 19? Правильно ли я понимая, что обработчик этого прерывания должен ( в идеале, конечно) обрабатывать все прерывания, за исключением приёма и передачи?

CAN контроллер получился клёвый: 1 приёмный и 1 передающий буфер, FullCan не работает, а уж документация - так вообще, полное г###о.

Угу

Не все, а нужные, я обрабатываю только EIE, проверяя в обработчике биты BEI и EI регистра ICR.
Т.е. у меня, в этом 19-ом прерывании цикл по всем используемым CAN-ам с вызовом общего для передачи и ошибок обработчика. А общий он у меня в связи с тем, что при чтении ICR его биты сбрасываются. И у меня была проблема с потерей прерываний, хотя, возможно, её можно было решить переупорядочиванием приоритетов в VIC.
В результате у меня для 2292
2-обработчика прерываний приёма (они ICR не читают)
2-обработчика прерываний передачи, читают ICR, вызывают общий обработчик передачи ошибок с номером шины и прочитанным ICR.
1-обработчик прерывания всего остального, в цикле по всем используемым CAN-ам читают ICR, вызывают общий обработчик передачи ошибок с номером шины и прочитанным ICR.


А Вам реально надо слать тыщи пакетов с максимальной скоростью?
И что за время приёма следующего пакетта Вы предыдущий не успеваете обработать?
И FullCan нужен?

Меня больше вот это напрягает:


Хотя в моём случае Self Reception Request вместе с Acceptance Filter прокатывает, но в ряде случаев может быть печально.


Её просто долго курить нада, с ерратами вместе. У меня кстати 3 передающие буфера работали без проблем, пока еррата не появилась.

Да это как раз не сильно напрягает. Даже без Acceptance Фильтра можно программно отловить эту фигуню и выкинуть.
Меня вот напрягает CAN.5 из errata, поскольку не написано совершенно, как и в каких случаях проявляется, а в workaround описана чушь и она не работает. Такое ощущение, что они
написали workaround теоретически, не проверяя на практике.
Support меня по этому вопросу, мягко говоря, послал

Во первых при большом исходящем трафике это может стать накладным...
В ряде случаев (например мост между шинами ) может понадобиться логика по сравнению только что отправленного пакета с принятым (ну или ещё какаянить, типа после любого факта отправленного пакета игнорировать принятый, но тут приоритеты прерываний могут влиять)


Тут ничего не скажу, я Reset Mode не пользую.
У них в ерратах про CAN ошибки не только добавлялись но и исчезали....

Я сравнивал принятый с последним переданным. Приоритеты анализировал, не должно быть проблем.
Я не говорю, что это хорошо, но это понятно.
К тому же в одном CAN сегменте 2 узла не должны передавать пакеты с одинаковым ID и RTR,
это противоречит логике CAN, поэтому, возможно можно использовать фильтр почти всегда,
но я не стал.


Кроме Reset там еще описан Abort Mode. Он как раз нужен для того, чтобы прерывать передачу
сообщения в CAN по таймауту (например, когда на шине только один CAN контроллер).