RA6M5 Ethernet PHY

About the communication failure of the r7fa6m5bf3cfp network driver, The following is a description of the problem, see if there are good solutions and suggestions for the problem? Thanks!

1. Problem description
At present, we have the development board of r7fa6m5bh3cfp (EK-RA6M5) and the project pcb board based on r7fa6m5bf3cfp . Transplanting the network driver is one of the tasks of this project. The differences between the two platforms include:

(1) Ethernet pin mapping, development board mapping as shown in Figure 1-3 (irrelevant pin configuration has been removed), project pcb mapping as shown in Figure 1-4;

(2) phy chip model, The phy model of the development board is KSZ8091RNB, and the phy chip model of the project pcb is DP83848KSP.

Development process(project pcb): First, modify the pin mapping based on the development board routine, Then modify the phy driver, mainly the modification of the phy address, After the modification, the communication can be performed normally, and the oscilloscope has been used for signal measurement verification. The DP83848KSP configuration only needs to modify the configuration after soft reset and change the communication interface to rmii mode to send and receive data, The phy input and output ends have been captured by the oscilloscope respectively. The R_ETHER_Open function returns normally, and the R_ETHER_LinkProcess function returns normally, but no receive interrupt is generated, The R_ETHER_LinkProcess function can detect the connection flag, network speed, full-duplex communication and other information. When the edmac reception is enabled, it is found that the EESR.ADE of the edmac is always set to 1 (address error flag), but the descriptors, buffer addresses and other configurations are all Using the routine configuration, it is inconsistent with the phenomenon when debugging on the development board.

 Figure 1-3

Figure 1-4

2. Attempt to solve the problem
1. Comparing the register configuration of ethernet and edmac after network initialization when the pcb board and the development board are debugged, they are the same except for the eesr status register of edmac. (Because the routine modification part does not involve register modification, and the tracking of the initialization process of the two remains consistent, the result is as expected, and other places are suspected.)
2. Comparing the two chips, the datasheet describes that the size of the rom is inconsistent, and the size of the ram is 512K, so confirm whether the buffer location is a non-secure area, and the two platforms run-time descriptors and buffer addresses are consistent.
3. It is suspected that there is a difference in the configuration roms of the two, Use j-link-lite to erase and re-program for comparison, The configuration is also the same, Except for the configuration of starting the crystal oscillator, all others are 0xFF.
4. Connect the rmii interface of the phy on the pcb to the development board through the flying wire (or use the pin mapping relationship on the pcb), the routine remains unchanged after modification, and EESR.ADE is not set when edmac reception is enabled , as a result, the communication is normal, and the interruption can be entered normally when the network packet is received.

 Figure：edmac status register when pcb board is debugged

3. Summary
The project based on the pcb project can run normally when the flying wire connects the DP83848KSP to the development board, It is suspected that there are differences between the two chips, Since the receive overflow flag is also set, and the buffer address is illegally set, it is guessed that the data packet is at the Ethernet ip layer, It has been accepted that this phenomenon is caused by edmac not correctly moving the data in the fifo to the sram.

The above is the description of the problem. We have also tried various methods for the interactive test of the development board and the project PCB board. Do we have relevant comments and suggestions? Thank you!