RECEIVE BUFFER INTERRUPT

[PEGE]

Hi i have a question about the receive buffer interrupt of the mcf5282 evb.

I use the folowing code to initialize the interrupt.

void initialize (void){fnSetIntHandler(92,(unsigned char*)(*INTERRUPTS_ETH_ISR));}static unsigned char *fnSetIntHandler(int iVectNumber, unsigned char *new_handler){    extern unsigned long __VECTOR_RAM[];    unsigned char *old_handler;        old_handler = (unsigned char *)__VECTOR_RAM[iVectNumber];    __VECTOR_RAM[iVectNumber] = (unsigned long)new_handler;        return old_handler;     }int INTERRUPT_ETH0_INIT_CONTROLLER(void){  MCF_INTC0_ICR28 = MCF_INTC_ICR_IL(3); MCF_INTC0_IMRL &= ~(MCF_INTC_IMRL_INT_MASK28 +  MCF_INTC_IMRL_MASKALL);  MCF_FEC_EIMR |= (MCF_FEC_EIMR_RXB); }__declspec(interrupt:0) int INTERRUPTS_ETH_ISR (void){ printf("Receive Interrupt");  }

 The problem is if i use the RXB interrupt it doesnt work. if i use source 23 for receive frame interrupt and change to MCF_FEC_EIMR_RXF, the interrupt works fine. Does any one see what could be the problem ?

[TomE]

> if i use source 23 for receive frame interrupt and change to MCF_FEC_EIMR_RXF, the interrupt works fine.

Source 23 is "X_INTF Transmit frame interrupt". Are you using that or is the above a typo anyou're using "27 R_INTF Receive frame interrupt"?

The difference between RXF and RXB is detailed in:

Table 17-5. EIR Field Descriptions

RXF: Receive frame interrupt. Indicates a frame has been received and the last corresponding buffer descriptor has been
updated.
RXB: Receive buffer interrupt. Indicates a receive buffer descriptor not the last in the frame has been updated.

If the received frame fits into one buffer then you won't see RXB. That's only for long frames that fit into multiple buffers.

Does that help?

Tom

[PEGE]

Hi,

I am sorry I just wrote the wrong module but in my code I use the 27 for receive frame interrupt. How can I clear the received frame ? If I use the 27 the interrupt works but it interrupts constantly.

Regards

[TomE]

You have to CLEAR the interrupt, and looking at your code that prints, you're not doing that.

17.4.2 Ethernet Interrupt Event Register (EIR)

"Writing a 1 to an EIR bit clears it;"

All the bits in "Figure 17-2. Ethernet Interrupt Event Register (EIR)" are marked "W1C", which means "write one to clear".

So the first thing you have to do in your service routine is to write a 1 to the RXF bit in that register.

This is a very consistent part of ALMOST all devices in Freescale's chips (except the MCF5329 LCDC), and is a brilliant bit of design. To ack a specific interrupt in a shared status register you write "1" bits to clear. In the simplest case you can read the register (to get all the bits that are set), write that exact data back to the register and then process the copy in your code to handle all the bits that were set at the time that you read it.

The way to get it badly wrong is when someone has designed a chip where you have to read it, clear a bit in the copy, then write that copy back to the register to clear the interrupt. That fails badly when another interrupt happens (and sets a new bit) between the read and the write. Then in the next chip in the series the designers try to fix that by adding some "magic and invisible hardware" in the register so that when you read it, it "remembers" which bits it gave you on that read so that it only clears those bits on the subsequent write. Then that fails if you have multiple threads of code reading that register or try to read it in the debugger.

Another way to get it wrong is the "read to clear" method. The MCF5329 LCDC does this. Reading clears all set bits. That means you can only have one "reader function", as anything else reading that register to try and find if any interrupts are pending will clear them - like trying to read the register in a debugger. Or worse, if the register is read at the same time the hardware is trying to set one of the bits, the set fails and the interrupt is lost forever. So you can't even read the register to ACK an interrupt without risking losing other ones.

Freescale's normal "W1C" approach is immune to all of these problems.

Tom