Does the 52234 part miss interrupts ?

[Alessandro]

Hi,

I'm facing a problem about the FEC which stops frames receiving in the
presence of a heavily loaded network. More in detail, I've configured
the FEC with only one receive buffer descriptor which is always
consumed inside the receive frame interrupt service routine. The
strategy I've implemented is the following:

1) RXF interrupt is rised due to a frame receiving. Since I have only one
    receive buffer descriptor the FEC stops to process incoming frames
2) Inside the ISR I consume the buffer descriptor and FEC starts to
    process incoming frames again because at least one receive buffer is
    available at this time

I have analysed the problem under different point of views and I suspect
that when it occurs the reason is that the CPU misses the RXF interrupt.
My suspect is based on the fact that the CPU has to handle several other
interrupts other than the FEC ones, and the ISR policy I've implemented
plans to use nested interrupts using the priority scheme of Coldfire.

Is it possible that the CPU miss some interrupts ? For my knowledge every
pending interrupt is served during the time. I can accept that someone of the
same type is missed due to system performance but at least one should be
always rised and retriggered from the ISR using the flag clearing mechanism.

Do you have any ideas ?

Best Regards

/Alessandro

[mjbcswitzerland]

Hi Alessandro

I haven't heard of problems with lost rx interrupts after working on a number of projects with  the device.

Looking at our code i think that the following three commands are required to clear an interrupt and free the present buffer.

Code:

    EIR = RXF;                                                           // reset interrupt flag    ptrRxBd->usBDControl |= EMPTY_BUFFER;                                // free the buffer    RDAR = 0;                                                            // re-enable buffer operation

On the other hand I haven't heard of anyone using just one rx buffer (the overrun chance will be rather high).

There is however a problem with using just one tx buffer - see the device errata - where the buffer descriptor (which wraps from one buffer back to itself) may cause a transmission to be sent twice due to timing difficulties in this case. There may be something similar with using just one rx buffer too - possibly not encountered since this is probably a very rare configuration...

regards

Mark

www.uTasker.com