MPC8270 FCC (Ethernet) Frame Corruption Problem

[muhammadumersae]

I am porting VxWorks on MPC8270 based board. I am running the board with following clock configurations.

Custom Board (Which has FCCs problem):
Processor: MPC8270 (3K49M, HiP7)
Clocks: 100MHz oscillator, 100MHz bus frequency, 250 MHz CPM frequency and 400MHz core clock
Reference Board (FCCs are working fine):
Processor: MPC8270 (3K49M, HiP7)
Clocks: 64MHz oscillator, 64MHz bus frequency, 192 MHz CPM frequency and 384MHz core clock

Problem:
When I am running the Ethernet on FCC (1, 2, 3) the frame is corrupted by the CPM (communication processor module). Communication processor module is corrupting the frame when reading from Tx buffers (Note: Data is correctly placed in the Tx buffers which I have verified by debugging the driver) which are placed in 60x Bus (SDRAM). CPM reads data in a corrupted manner and append padding and checksum to frame. On the host end I am running Wireshark to see the packets (Corrupted packets). I have debugged the hardware and software driver (Both seems good).

I have also a reference board running the same driver (working fine). The only difference between the custom board and the reference board is the clocks as mentioned above.

Does clocks makes difference to CPM module working? Is there a limit of setting clocks of CPM module? What are the possible outcomes of changing the clocks of CPM on the FCCs driver?

For detailed behavior of FCCs, attached is the file.

[alexander_yakov]

Switching to higher frequency without any changes in software may result to incorrect SDRAM interface settings, because SDRAM interface configuration parameters are calculated for particular frequency 64 Mhz and obviously incorrect for 100 Mhz.

Also, MPC8280 family has known issue with running SDRAM at 100 Mhz, please look the following application note and confirm this application note was taken into account, when designing the board:

https://www.nxp.com/docs/en/application-note/AN2654.pdf

To verify is the difference is only in frequency, please try reducing input frequency back to 64 Mhz for short time, for testing purpose. If the problem does not appear at 64 Mhz, than SDRAM timing settings are the most probable reason of the problem. I do not expect any issues with FCC when increasing its operating frequency, so the problem appears on communication between FCC and SDRAM.

Have a great day,
Alexander
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[muhammadumersae]

Dear,

The board running at 100Mhz is working fine as we ported vxWorks bootloader on it. Following are the specifications of our working board (100Mhz).

(1) SDRAM driver is correctly configured for 100Mhz (Refresh timer, Address Multiplexing etc). As we have copied our bootloader to SDRAM and

      booted from it. The core is working fine (Correct reading and writing from SDRAM). 

(2) Serial ports also working good and gives no error when we interact with bootloader

(3) when CPM reads from SDRAM for FCCs it corrupts data in fixed manner (i.e Reading 16bytes good and 16 bytes faulty-- Pattern remains same throughout the frame).

Following are the arguments for your proposed solutions

(1) If the SDRAM has not been properly interfaced with MPC8280 at 100MHz. Core should also return error after reading from SDRAM (It works fine if the reading and writing from core is done).

(2) If the CPM is not able to read from SDRAM correctly then the data read by CPM should be random. But the corruption is in fixed manner (i.e 16 bytes good and 16 bytes faulty)

Our tried solution

(1) We have checked our transmission buffer before and after transmission of packets. They are not corrupting as the data before transmission and after transmission remains the same (We have print the data placed in the Tx Buffers through serial port).

Questions
(1) Is our processor faulty? Should we have to update the microcode of the processor?
(2) As the SDMA channel (CPM read from SDRAM through SDMA)  is not configurable by user, what are the possible options to debug CPM or to driver CPM?
(3) How can we make sure that CPM's read transactions are good? How to get this visibility?

[alexander_yakov]

There is a difference between core and CPM - core can not create adjacent ("Back-to-back") burst accesses to memory, because of peculiarity of core load/store unit. The CPM is optimized to use memory more intensively, and can issue memory accesses without any gap. So, if some "overlap" problem happens on adjacent memory accesses, where previous memory access somehow interferes with next immediately following memory access, than this problem may happen on CPM-initiated memory transactions, a will not happen on core-initiated ones.

The same very highly optimized intensively memory usage algorithm is implemented in DMA engine, so you can use DMA to test this problem. 

To answer your questions:

1. There is nothing re-programmable inside the processor. Internal microcode ROM is one-time programmable at factory and can not be updated. You can only have "microcode patches" applied to this ROM to fix a particular bug. All known bugs are listed in device errata:

https://www.nxp.com/docs/en/errata/MPC8280CE.pdf

2. SDMA channel usually works perfect and does not require any debugging. There is not too much information in SDMA-related registers (MPC8280 Reference Manual, Section 19.2), only transfer error bit and related MSNUM number. You can also have some debugging information in FCC-related memory structures, but I do not think it will be helpful in this case, because FCC does not indicate any error in this case, as far as I can understand from the description.

3. To make sure CPM read transactions are good, you can use the same SDMA functionality to transfer data from memory to memory, as common DMA engine. Please look MPC8280 Reference Manual, Section 19.3

https://www.nxp.com/docs/en/reference-manual/MPC8280RM.pdf

[muhammadumersae]

Dear Alexander,

We are still standing in the same problem of Ethernet.

(1) We have changed our board's frequency to 66Mhz as you suggest but the Ethernet frame corruption is still the same (SDMA transactions are corrupting, data repetition after 16 or 32 bytes).

(2) We have also tried IDMA transactions, it get stucked and the processor halts during transactions

Kindly tell us , where the problem resides or how to solve it. Is the processor is faulty or is there any hardware of software issue.

For Software issue:

(1) We are using modified reference boards bsp (Reference board is working fine on 64MHz). We have debugged our software and there is no issue in the software

For Hardware issue:

(1)  Considering the BUS frequency 100Mhz is too fast, we have downgraded our boards operating frequency to 66 Mhz. And the problem is not resolved.

[alexander_yakov]

You said:

We have also tried IDMA transactions, it get stucked and the processor halts during transactions

So, does this mean the problem is not only related to Ethernet controller, but IDMA does not work also?

Have you tried to run this IDMA test on our development board to verify if this IDMA test is error-free?

Also, for Ethernet controller issue - when the problem appears please stop the controller and create full dimp of all ethernet-related memory structures - controller registers, parameter ram, buffers and buffer descriptors. Please attach this dump for analysis.