Hi @all, i have running a board with the NXP LPC2290 with FreeRTOS and want to use the CAN Controller. For me it seems to be a strange contruction of the Interrupt-Handling of this uC. The uC has two IRQ’s (Tx an Rx) connected to two Interrupt- vectors but only one Interrupt-capture-register. So I don’t know how to handle this interrupts because when i am reading the interrupt-capture- register this interrupts are cleared. So i must handle the Tx-ints during Rx-ISR-call and Rx-Ints during Tx-ISR-call – strang – does someone have already implemented a CAN-driver with both Interrupts or does someone know how to solve this ? I connected the Rx-Int to IRQ-Prio 2 and the Tx-Int to Prio 3 so the Rx- Int is able to interrupt the Rx-Int and the function will nest. May be, is it possible to use only one Irq for both Tx and Rx- Interrupts? The ISR are instrumented with teh FreeRTOS-Macros portENTER_SWITCHING_ISR() and portEXIT_SWITCHING_ISR( 1 ) as required from FreeRTOS. The symptom is that I am getting an programe abort exception and i guess that the nested ISR are creating it. I searched the whole web in order to find a solution but i didn’t find anything. I hope that someone can help me solving this problem or maybe someon have already coded it with FreeRTOS ? regards Joe

I cannot help with the CAN interrupts specifically, but I have some general comments. The interrupts will not nest unless you have explicitly re enabled interrupts within the ISR.  However you cannot do this without making some other changes in the macros otherwise you definitely will run into problems.  Interrupt nesting is not really desirable. My suggestion would be to process the CAN information within a high priority ‘interrupt task’.  This would take the following structure: void CANHandlerTask( void* parameters ) { __for(;;) __{ ____// Wait for a CAN interrupt. ____xSemaphoreTask( CANSem ); ____if( Rx interrupt received ) ____{ ______// Process Rx data. ____} ____if( Tx interrupt received ) ____{ ______// Process Tx data. ____} __} } Both the Rx and Tx ISRs then take the following format: void CANTxISR( void ) __attribute__ ((naked)) { __portENTER_SWITCHING_ISR(); __xSemaphoreGive( CANSem ); __//clear CAN interrupt here! __//clear VIC here! __portEXIT_SWITCHING_ISR(1); } CANHandlerTask() is then given the highest priority of all tasks (if this is desired).  Then, when an interrupt occurs it wakes the CANHandlerTask(), and as it is the highest priority, the ISR returns directly to the handler task.  The processing is then immediate as if it was done in the ISR itself, but as it is at the task level interrupts are enabled and you can have other ‘interrupt tasks’ running at various priorities without having to worry about nesting. Dave.

Hi Dave, i think i know what you mean. The theory is to call the ISR initaited by the CANHandlerTask which is signalled by semaphores from the real TxIsr/RxIsr ? But i’ve tried to walkthrough the concept and I think it would be good to create isr-events put to two diffenet queue’s – one for rx and the second for tx interrupts instead of the boolean variante as you decsribed: your proposal: ____if( Rx interrupt received ) ____{ ______// Process Rx data. ____} ____if( Tx interrupt received ) ____{ ______// Process Tx data. ____} my proposal: ____do ____{ _______if(isr_event_availble = read_rx_isr_event_queue(&isr_rx_event) _______{ ___________// Process Rx data. ___________rx_isr_func(); _______} _______if(isr_event_available = read_tx_isr_event_queue(&isr_tx_event) _______{ ___________// Process Tx data. ___________tx_isr_func(); _______} ____}while(isr_event_avalible); void CANRx/TxISR( void ) __attribute__ ((naked)) { __portENTER_SWITCHING_ISR(); __xSemaphoreGive( CANSem ); __volatile uint32 cicr =0; __//clear CAN interrupt here! __cicr = CICR; // read interrupt capture register __write_tx/rx_isr_event_queue(cicr) __//clear VIC here! __portEXIT_SWITCHING_ISR(1); } with the usage of event-queues it would be able to compensate jitter! what do you think of my proposal ? Joe