SPC5Studio Network ping application not working

[eliozepeda]

SPC58EC-DISP: FreeRTOS+TCP “ping” demo never replies to ARP/ICMP (IRQ only fires periodically)

Board: SPC58EC-DISP (DP83848 PHY)
App note / demo: “SPC5Studio Network ping application” (AN5413) integrated into SPC5Studio
Host: Windows PC, static IP 192.168.1.10, direct Ethernet to board
Target static IP: 192.168.1.2 (gateway/DNS not required for same subnet)

Symptom

• Link LED on RJ45 is solid (100 Mbps FDX).

• FreeRTOS+TCP comes UP: in vApplicationIPNetworkEventHook() we print the configured IP/netmask/gateway/DNS and they are correct.

• The PC cannot ARP the board. arp -a shows no entry for 192.168.1.2, ping times out.

• Ethernet IRQ does not fire on ping. It does fire periodically (first ~every 10 s, later ~every 30 s) even with no traffic.

What the periodic IRQs are (what we see)

When the periodic IRQ happens, DMA_CH0_STATUS shows TX-side causes, not RX:

• Example snapshot: DMA_CH0_STATUS = 0x00008405 → TI=1, ETI=1, TBU=1, NIS=1, RI=0.

• This matches periodic TX from the stack (e.g., ARP refresh / housekeeping).

• Disabling the UDP logging task/hook removes some TX, but periodic IRQs still occur (ARP timer etc.). We understand this is expected.

What we’ve verified / configured

Hardware & IO voltage

• JP5 and JP50: FIT as per the demo.

• JP34 (VDD_HV_IO_Main) and JP35 (VDD_HV_IO_Flex) set to 3V3 (not 5 V).

• On the MCU: PMCDIG.VSIO: VSIO_IM=0, VSIO_IF=0 (both rings 3.3 V).
  (Earlier IF was 5 V; we fixed that.)

Mode, clocks, PHY

• SIUL2.SCR0.ETHERNET_0_MODE = 1 (MII).

• ETH0 peripheral clock enabled (PCTL set in RUN/LP).

• PHY DP83848 strapped for 25 MHz crystal; link up at 100Base-TX full duplex.

• FreeRTOS+TCP network event eNetworkUp is received and IP reported correctly.

• PHY basic status shows link up (BMSR/PHYSTS confirm link/speed/duplex).

Interrupt routing

• Handler: IRQ_HANDLER(SPC5_ETH0_CORE_HANDLER) uses vector 212 (Ethernet0 combined).

• INTC PSR[212]: priority > 0, routed to the core running the stack; CPR = 0; MSR[EE]=1.

• We see the handler increment a counter on periodic IRQs (so vector is correct).

DMA/MTL/MAC after init (current state)

• MAC_CONFIGURATION: RE=1, TE=1 (enabled).

• MTL_RXQ0_OPERATION_MODE: RXQEN = 0x2 (enabled).

• MTL_TXQ0_OPERATION_MODE: TXQEN = 0x2.

• DMA_CH0_RX_CONTROL: SR=1, RBSZ ≈ 1524 bytes.

• DMA_CH0_INTERRUPT_ENABLE: NIE=1, RIE=1, (TIE optionally 1).

• Descriptor list base/tail registers (RX/TX) are non-zero and set.

• We also tried promiscuous (MAC_PACKET_FILTER.PM=1) and ensured broadcast not blocked (DBF=0).

RWT (Receive Watchdog)

• To avoid coalescing hiding RX events, we set dwmac->rwt_en = 0 in dwmac_netdrv_init() so RX descriptors request IRQ per frame.
  (With RWT on and max count, we saw the ISR only at long intervals; now it should fire on RX.)

What still doesn’t happen

• When we ping or send ARP from the PC, the IRQ does not fire due to RX: DMA_CH0_STATUS.RI remains 0.

• PC continues to show no ARP entry for 192.168.1.2.

• Wireshark on the PC shows ARP Requests leaving the PC; no reply from the board.

Things we investigated earlier (and corrected)

• New, critical observation — timing / breakpoint effect

  We’ve found a repeatable, timing-dependent behavior during bring-up:

  • If we run the firmware normally (no breakpoints), after init we read:

    • MTL_RXQ0_OPERATION_MODE.RXQEN = 0 (disabled)

    • MTL_TXQ0_OPERATION_MODE.TXQEN = 0 (disabled)

    • DMA_CH0_RX_CONTROL.RBSZ = 0x0000

    • DMA_CH0_INTERRUPT_ENABLE.NIE/RIE = 0
      …so no RX , no RI interrupts, no ARP replies. (SAME FOR TX) 

  • If we place a breakpoint in the driver initialization path (e.g., around dwmac->dma->init() / dwmac->mac->init() / dwmac_start()), and single-step a few lines, the very same run ends up with:

    • RXQEN = 0x2, TXQEN = 0x2

    • RBSZ ≈ 1524

    • NIE/RIE = 1 (and DMA SR/ST set)
      …then the IRQ handler starts firing properly and the path looks alive.

  • Power-cycle and run without breaking → the problem returns (queues disabled, RBSZ=0, no RX).

  • In short: with a breakpoint/step it configures correctly; running straight it often doesn’t.

Questions for ST / requests for guidance

1. Descriptor ownership & cache: Are there known cache maintenance requirements for EQoS on SPC58EC for RX descriptor ring and RX buffers at init?
   We call the driver’s dwmac_flush/invalidate_cache_range() around desc/buffers on RX/TX. Is there a required memory attribute (non-cacheable) region for descriptors/buffers on this platform? Any example linker script / MPU settings for this demo?

2. RX filters: Beyond PM=1 and not blocking broadcast, is there any additional filter bit (e.g., DAIF, HMC, HPF) that must be set/cleared on this MAC/port to ensure ARP (broadcast) reception on queue 0?

3. MDIO PHY address: What is the PHYADDR strap used on the SPC58EC-DISP DP83848? If the driver’s MDIO address doesn’t match, can the DMA/MTL init silently skip enabling RX? (We can scan 0..31 and confirm the exact address if needed.)

4. SIUL2 / pinmux side: Aside from ETHERNET_0_MODE=MII, are there additional pad configs (drive strength/pull) required on RXD[3:0], RX_DV, CRS, COL, RX_CLK for reliable input? (We fixed IO voltage to 3.3 V.)

5. Known sequence dependencies: Is there any ordering requirement (e.g., enable MTL RXQEN before setting RX tail pointers, or start DMA RX only after RE=1) specific to this DWMAC port for SPC58?

6. Any known errata on this device/port where link is up, MAC enabled, but RX path is blocked until a specific register write/clear?

What we can provide

• Screenshots of MAC_CONFIGURATION, MTL_*_OP_MODE, DMA_CH0_*, and DMA_CH0_STATUS before and after a ping.

• MDIO BMSR/PHYSTS values and PHYID (once you confirm the expected PHY address strap for this board).

• Wireshark traces from the PC (ARP request visible; no reply).

Goal: get ARP/ICMP replies working (i.e., see RI=1 on ping and ARP reply transmitted).
Any pointers on cache/descriptor setup, required register bits, or ordering for the EQoS/DWMAC on SPC58EC-DISP would be greatly appreciated. Thanks!