Ricardo Raupp

FEC on 5225x

Discussion created by Ricardo Raupp on Jul 15, 2011
Latest reply on Oct 26, 2013 by TomE

Hy guys

I did some experiences with 52259 FEC transmitter, and the results were strange for me.

I used wireshark to see the packets.

I´m monitroring the interrupt flag in order to know about the end of transmission.

 

 

Experience #1:

Work? NO

Idea: allocate only one buffer_tx.

Result: the pacxet is transmitted twice, with 3uS between them.

 

Experience #2:

Work? NO

Idea: allocate 2 buffer_tx.

Result: The transmition hangs when I try to send the 2o packet.

The interrupt flag is not set, so the loop keeps closed forever...

The buffer to be used is the first availbale according to the flags provided by descriptors.

This way, the buffer 0 would be always used, once the transmissions request are too slow, therefore the

buffer 0 could be free at  new requests.

 

Exérience #3

Work? YES

Idea: allocate 2 buffer_tx, BUT manage by my self the sequence of wich buffer has been used/released, trhough a variable (uint8 ix), and not just monitoring the descriptors flags.

This way, the next free buffer to be allocated is not scanned from #0 to #n (via descriptor flags), butdefined by the value of "ix" variable. ( free = .buffer [ix] ).

After each transmission, the variable ix is incremented,.

 

Conclusion

It seems the RISC engine MUST allocate / release the buffers tx in a sequentially way.

Due to it, it hangs if I try to use a free buffer [0] while the last transmited, lets say, was the buffer[2].

Seems that I must keep me synchronized to the RISC engine counter...

 

Now I remember, I needed to use this approach to make the antecessor CPU (52235) FEC woks fine..

 

Thanks in advance...!!

 

Ricardo Raupp

Outcomes