Example LWIP PING project using DP8384 instead of LAN8741

[jonasa]

Hi, 

I build and use this example project:

\mcuxsdk\examples\lwip_examples\lwip_ping_enet_qos

with this dev. board:

\mcuxsdk\examples\_boards\frdmmcxe31b

and it works good, I can connect the dev board to a Raspberry Pi 4 and ping the dev board.

I got a custom board with the same MCX microcontroller but with a DP8384 PHY controller instead of a LAN8741 that is used on the frdmmcxe31b board. I have ported the example project to this board and the board send ping to the Raspberry but it doesn't send reply on ARP requests sent from the Raspberry. I have debugged and can see that the microcontroller receives the ARP request and try to send a reply with this function:

status_t ENET_QOS_SendFrame

in this file:

\mcuxsdk\drivers\enet_qos\fsl_enet_qos.c

You can see the call stack in call_stack.png.

But no package is sent and I get no errors. I run tcpdump on the Raspberry.

Here is the .pcap file:

disco__test14.zip
where can be seen that packet 18 is the ARP request from the Raspberry.

I've compared the .config files from the dev project and the custom board project and they are almost identical except the 

CONFIG_MCUX_COMPONENT_component.phydp8384x=y

and

CONFIG_MCUX_COMPONENT_component.phylan8741=y

In config.zip you find both .config files.

My question is if there are any more adaptations that need to be done? Is it the DP8384 that blocks the ARP reply?

Kind regards,

Jonas

[Harry_Zhang]

Hi @jonasa 

“In config.zip you find both .config files.”

Can you share your config.zip?

If the ARP request is received by the MCU, parsed by lwIP, and ENET_QOS_SendFrame() is called but no frame ever appears on the wire, the MAC is ready, the PHY is not transmitting.
This strongly suggests a PHY configuration issue rather than lwIP or ENET_QOS driver logic.

Can you share  your schematic screenshot of DP83848?

BR

Harry

[jonasa]

One more thing:
On the dev board we have a MCXE31BMPB

and on the custom board we have a S32K324EHT.

Those two microcontrollers are identical, right?

[jonasa]

Sorry forgot the other files, I've attached them to this message.

[jonasa]

Hi, 

I've attached a schematic screenshot.

The board can send other ethernet frames like the echo request as can be seen in the attached .zip file.
The board has IP address 192.168.0.102 and the Raspberry has IP address 192.168.0.100.

[PavelL]

Hello @jonasa , @Harry_Zhang ,

I checked your schematic and it appears to be correct.

Base on AN14792 - S32K31x to MCX E31x Migration Guidelines, MCXE31BMPB is S32K314EHT1.

At first, let me discuss the shared pcap file.

The device with IP 192.168.0.102 (your NXP board) is sending traffic first: it transmits a gratuitous ARP (“ARP announcement for 192.168.0.102”) and then it sends ICMP Echo requests to the Raspberry Pi (192.168.0.100). The Raspberry Pi replies with ICMP Echo replies for several seconds, so both TX and RX are working initially (at least for IP/ICMP).

After ~10–12 seconds, the Raspberry Pi starts issuing repeated ARP “Who has 192.168.0.102?” requests and does not receive any ARP reply from the NXP device. On Linux, once neighbor reachability is in doubt, it will first try unicast ARP probes (to the last-known MAC) and then fall back to broadcast ARP requests if that fails. At that point, the Pi can no longer reliably send frames to 192.168.0.102, so it also stops returning ICMP replies.
So the core issue is not “hardware cannot transmit” (we clearly see the NXP board transmitting ICMP requests), but rather that after some time the NXP board stops replying to ARP requests for its own IP address.

If ARP requests stop being answered only after running for a while, common causes are: 

• RX path not being serviced anymore (interrupt not firing, polling not running, RX task starved),
• RX descriptor/buffer exhaustion (frames are received by DMA but buffers are not recycled),
• a timing/priority issue where the application load eventually prevents lwIP input processing.

Suggested quick experiment

• Please try disabling the periodic ping generated by the NXP board (or reduce its rate significantly). If the ARP failure disappears when the device is not continuously generating ICMP, that strongly suggests a scheduling/priority / RX-servicing / buffer-recycling problem rather than a PHY limitation.
• As a quick diagnostic, please verify whether D‑Cache is enabled and try running with D‑Cache disabled

Best regards,

Pavel

[jonasa]

I got it to work now, I added these lines in a .cmake file in my project:

mcux_add_macro(
CC "-DFSL_ETH_ENABLE_CACHE_CONTROL"
)

In the example project these lines are in this file:

C:\work\mcx\mcuxpresso-sdk\mcuxsdk\examples\_boards\frdmmcxe31b\lwip_examples\lwip_ping_enet_qos\bm\reconfig.cmake

Do you know why ethernet cache control needs to be enabled?

[PavelL]

Hello @jonasa ,

That's a great catch. Ethernet drivers typically uses DMA to read TX descriptors/buffers and to write RX descriptors/buffers, so it's not surprising. I apologize, I don't know details related to this SDK.

Best regards,

Pavel

[jonasa]

Hi, 

Ok, same software works on the dev board MCXE31BMPB.

Are there any difference between the two microcontrollers.

As you state, the root cause might be that EMAC DMS interrupt is not triggered. DO I need to modify the driver code for the EMAC or are the two microcontrollers exactly the same? WIth same EMAC control registers etc?

This is a bare metal example.

This is the main loop:

    while (1)

    {

        /* Poll the driver, get any outstanding frames */

        ethernetif_input(&netif);

        sys_check_timeouts(); /* Handle all system timeouts for all core protocols */

    }

[PavelL]

Hello @jonasa ,

MCXE31BMPB is S32K314EHT1. Difference between S32K14 and S32K324 is only in the number of cores - please refer to S32K3 Data Sheet, Table 1. I do not believe you need any modification of the code.

Best regards,

Pavel