topic Re: FEC on 5225x in ColdFire/68K Microcontrollers and Processors

FEC on 5225x

RicardoRaupp — Fri, 15 Jul 2011 19:49:07 GMT

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

Re: FEC on 5225x

PaoloRenzo — Thu, 21 Jul 2011 03:29:56 GMT

Hi Ricardo

About the 2nd scenario, two buffer descriptors:

After modifying tx buffer descriptor, you request a xmit by writing into TDAR register. Then you're supposed to receive an interrupt for frame or buffer already sent. I think you'll be waiting fro frame completition. Then and only then you try to send the 2nd packet, right? Otherwise I'll think you'll have a race condition because FEC controller we'll be using 1 buffer with the Ready flag while you're modifying the 2nd buffer. You should wait for frame completetion interrupt (or TDAR being cleared) to start a new xmit process.

I also think you don't need your own flag but you can resue some of the non-used buffer descriptor flags in the status word from each buffer descriptor. Maybe a general flag to make sure which was the last modified buffer descriptor.

Please let me know if I get this correctly.

Re: FEC on 5225x

mmdonatti — Sat, 26 Oct 2013 10:12:44 GMT

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.

To make work this experience you should set :

1st BD :

- status : R=1,L=0,W=0

- length of data

- pointer to data

2nd BD : (void BD)

- status : R=1,L=1,W=1

- length : 0

- pointer : don't care

after you set TDAR.X_DES_ACTIVE and wait for interrupt flag.

it works for me. Problem : when wrap bit is set with Ready and Last the FEC sends two times the BD.

Re: FEC on 5225x

TomE — Sat, 26 Oct 2013 12:53:48 GMT

You've posted to both this thread and the similar one:

https://community.freescale.com/thread/63872

The original problem (and yours if you were having it) seems it could be caused by the following.

Detailed in section "18.4.6.1 Duplicate Frame Transmission". You have to use at least THREE buffer descriptors in the ring, and also have to ensure that at least one of them is always "free".

A search of this Forum finds:

https://community.freescale.com/message/63878#63878

https://community.freescale.com/message/101080#101080

Tom