ColdFire/68K Microcontrollers and Processors中的主题 Re: When I use API for FEC (MCF5485), number of datas in send frame it is necessarily divisible by 4

When I use API for FEC (MCF5485), number of datas in send frame it is necessarily divisible by 4 ?

ChG — Thu, 31 Dec 2009 23:21:57 GMT

I try to write a program for FEC unit of microprocessor MCF5485.

When I send a frame of 64 bytes, everything is well, she is seen by the Wireshark application (for example).

When I send a frame of 65 or 66 or 67 bytes, sent frames have quite a length of 68 bytes and they are not accepted by the application.

In other words, the argument length of the structure MCD_FEC_bufDesc (Multichannel DMA API) can be the other thing than a modulo number 4?

I tried to work without the DMA, directly with the unity(unit) FEC, there no problem, I can send frames of 64, 65, 66, 67 bytes.... n bytes.

They are correctly received and they have correct sizes (64[preamble]+12[macs]+2[type]+n[data]+4[CRC] x 0.1 micro.sec. @10Mb/s).

It is possible to send frame containing a number of bytes not modulo 4. For example 69 bytes?

Thank you in advance.

Christian.

Re: When I use API for FEC (MCF5485), number of datas in send frame it is necessarily divisible by 4

PaoloRenzo — Tue, 05 Jan 2010 03:06:37 GMT

So you're saying FECDMA pads your packet if not divisible by 4? Is that true? That doesnt seem harmful, plese explain how it affects your system

Re: When I use API for FEC (MCF5485), number of datas in send frame it is necessarily divisible by 4

jkmahan — Tue, 05 Jan 2010 05:11:34 GMT

As I recall there was an errata covering the need to pad to 4 bytes. (it's been a while since I last looked at this..)

Re: When I use API for FEC (MCF5485), number of datas in send frame it is necessarily divisible by 4

TomE — Tue, 05 Jan 2010 07:37:05 GMT

jkmahan wrote:
As I recall there was an errata covering the need to pad to 4 bytes. (it's been a while since I last looked at this..)

Nothing I can find in the relevant device errata:

http://www.freescale.com/files/32bit/doc/errata/MCF5485DE.pdf?fpsp=1&WT_TYPE=Errata&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation

Nothing obvious in the Reference Manual either. It is BIG!

Questions about ethernet padding have been around for a long time, as long as Ethernet itself:

http://fixunix.com/tcp-ip/66823-ethernet-padding.html

http://groups.google.com/group/comp.protocols.tcp-ip/browse_thread/thread/171baf14955bcfa5/

Ethernet packets must be padded out to at least 60 bytes (53 with the checksum). There's nothing that says you can't pad all the way up to 1400 or 1500. All devices should ignore the extra padding, but you might find buggy devices where someone didn't understand the specs and didn't test properly.

I've found bugs in 802.3 packets with SNAP formatting (AppleTalk). One box always sent packets rounded up to an even number of bytes, but put ODD lengths in the Ethernet Length field. Some receivers dropped these packets. The spec isn't clear on this one, but nobody is still using 802.3 so this doesn't matter now.

If Wireshark is the "Application" and it isn't getting the "funny packets" then it is most likely that the checksum isn't valid for the packet being sent.

If you've got some low-level "Application" and it isn't working, make sure you're handling received padding.

Make sure you distinguish the IP packet length field (which says how much valid IP data is in the frame) from the ethernet packet data length. The only relationship is that the Ethernet packet must be long enough to hold the IP packet, but can be longer (that's the definition of the padding). The checksum is generated by the hardware, and should be OK.