Ethernet frame corruption

[toltol]

Hi,

We are using the FCC Ethernet (MII) interface of the MPC8270 to load the boot image on our board. Host A (our board) communicates over Ethernet with Host B (windows based PC). The first transmitted (TX) frame by Host A is an ARP request and the first received (RX) frame by Host A is the ARP reply (sent back by Host B). However, both the TX and RX frames are corrupted possibly by the Communication Processor Module (CPM) or the FCC. Therefore, the ARP query is never resolved and the communication does not go forward.

Hardware and communication details are as follows:

Host A - our board (communication initiator);

• Processor: MPC8270, Rev. A.0, Mask 3K49M;
• PHY: Texas Instruments DP83848;
• FCC2 MAC: 08 04 e3 33 00 00;  FCC2 IP: 10.10.10.1.
• Frame A: Actual Frame generated by the Core; checked and verified by printing the TxBuffer value (stored in SDRAM)
• Frame A': Corrupted Frame transmitted by FCC2; recorded and verified at the TXD[0:3] pins of the PHY using ChipScope

Host B - Windows based PC;

• Processor: Intel Core i5 with Intel-based Ethernet controller;
• Host B MAC: 10 04 70 aa 06 09; Host B IP: 10.10.10.2
• Frame B: Corrupted Frame received by Host B and viewed on Wire Shark

Based on the ARP packet structure, details of the frames are as follows:

Frame A:

• Ethernet header:
  • Dest MAC: ff ff ff ff ff ff - (The dest MAC is broadcast since this is an ARP query)
  • Sender MAC: 08 04 e3 33 00 00
  • ARP Code: 08 06 
• Payload:
  • Hardware type: 00 01
  • Protocol type: 08 00
  • Hardware and Protocol length: 06 | 04
  • Opr Code: 00 01
  • Sender (Host A) MAC: 08 04 e3 33 00 00
  • Sender (Host A) IP: 0a 0a 0a 01
  • Dest (Host B) MAC: 00 00 00 00 00 00
  • Dest (Host B) IP: 0a 0a 0a 02

Frame A': 

• Ethernet header: PREAMBLE + SF + same as Frame A
• Payload
  • Hardware type: same as Frame A
  • Protocol type: same as Frame A
  • Hardware and Protocol length: same as Frame A
  • Opr Code: same as Frame A
  • Sender (Host A) MAC: same as Frame A
  • Sender (Host A) IP: 08 06 00 01 - (8.6.0.1)
  • Dest (Host B) MAC: 00 08 06 04 00 01
  • Dest (Host B) IP: same as Frame A
  • Some padding + CRC at the end

Frame B:

• Ethernet header: Same as Frame A'
• Payload
  • Hardware type: same as Frame A'
  • Protocol type: same as Frame A'
  • Hardware and Protocol length: same as Frame A'
  • Opr Code: same as Frame A'
  • Sender (Host A) MAC: same as Frame A'
  • Sender (Host A) IP: same as Frame A'
  • Dest (Host B) MAC: same as Frame A'
  • Dest (Host B) IP: same as Frame A
  • Some padding + CRC at the end

Details of the problem:

1. The result above indicates that Frame A ≠ B, however, since Frame A' = Frame B, the CRC matches and Host B accepts the frame.
2. Host B replies to Host A at 8.6.0.1 instead of 10.10.10.1 since it has been changed in Frame A' possibly by the CPM or FCC.
3. The reply sent by Host B to Host A is also corrupted (changed) by the FCC, which was verified by printing the RxBuffer value (stored in SDRAM)
4. Since the extra padding + CRC is performed by the CPM/FCC we suspect that frame corruption happens at the CPM/FCC.
5. Comparison of Frame A and Frame A' indicates that the CPM/FCC replaces the 10 bytes (Sender IP and Dest MAC inside the payload) with the values starting from the ARP code (in the Ethernet header).
6. It is also possible that it replaces the 18 bytes (Sender MAC, IP and Dest MAC inside the payload) with the values starting from the Sender MAC (in the Ethernet header)

Additional test + debugging details:

1. The complete software (BSP+drivers+libraries) has been successfully tested on a different board that uses the same processor (MPC8270 Rev A.0) with ADM7001/X PHY.
2. We are using the same software (with some modifications based on our board design) as mentioned above.
3. We interfaced our processor with ADM7001/X PHY and faced the same issue
4. The same problem is faced when using either FCC0 or FCC2.
5. The same problem is faced when using a 2nd board (with the same hardware).
6. The same problem is faced when using either a straight or cross over cable or an Ethernet switch in between.
7. The same problem is faced when either changing Host A MAC or/and IP addresses.
8. Possibility of Frame corruption happening within the software (BSP+drivers+libraries) is negligible since the data in both TxBuffers and RxBuffers (placed in SDRAM) has been verified.

Questions related to the problem

1. What could be the possible reason for this frame corruption?
2. Is there a way to access the CPM/FCC and determine what happens after it fetches the frame from the TxBuffers (placed in SDRAM) and prepares it for transmission?
3. Is there a way to access the portion of CPM/FCC where it computes and applies the CRC?
4. Common solution to such problems given in "Chip Errata for MPC8280" indicates on using the "provided microcode patch". Where and which microcode patches can we download and how are they used?
5. The CPM also has an internal ROM, is it possible that additional code has to be placed on this ROM. If yes how can this be achieved?
6. Is it possible the frame corruption is happening somewhere else?

[alexander_yakov]

Please show example of corruption in binary format - dump of contents of TX buffer for "correct" and "corrupted" cases, with actual physical location (address) in memory.