• State
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 16 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DP83869HM: Ping test blink led but fail.

Nicolas Bouquet
Intellectual 530 points

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869, DP83869EVM

Hello,

I have a STM32MP257 <> DP83869HM <> SFP 100Mbps <> OS1 fiber <> TPlink MC100CM converter <> ETH <> linux PC

DP83869 power rails are clean, bias is 1V and clean. CLKo is 25MHz and clean.

From the STM32 point of view, the IF is UP. I'm using 4 status led : Link up, Tx, Rx, TXRX fail

  • When the STM32 pings the computer, DP83869 Tx led blink, TPlink converter blink
  • When the computer pings the STM32, DP83869 Rx led blink, TPlink converter blink

But all ping fails.

Below is what I see with a scope

SFP.LOS = 0 => OK 
SFP.TxDIS = 0 => OK
SFP.TxFault = 0 => OK
SFP.DET = 0 => OK
SFP.RS =1 => OK

FX.nRST OK
FX.CLKo 25MHz
FX.TXCLK 2.5MHz (25MHz when link is up)
FX.RXCLK 2.5MHz (25MHz when link is up)
FX.nINT 0 =>>> is it normal that the nIRQ is stalled at 0 ?

Link LED ON
Tx/Rx Error LED OFF
Tx/Rx Active LED blink when pinging

MDIO reg reading:
0x11 = 0x0402
0x1DF = 0x0002
0xC00 = 0x2100
0xC01 = 0x614D

Following the troubleshootong guide, I tried a BIST test with a fiber looping the Tx/Rx slot of the SFP module. This test fails:

write Reg 0x0016 = 0xF000
read Reg 0x17 = 0x40, bit 11 is not set.

Sometimes, FX_INT_STS (0xC19 reg) is showing a FEF error (value 0x0210)

At this point, I really do not see what other test to do. Any help appreciated.

Thanks

(below is the device tree config, if it can help)

&eth2 {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&eth2_rgmii_pins_b>;
	pinctrl-1 = <&eth2_rgmii_sleep_pins_b>;
	phy-mode = "rgmii-txid";
	max-speed = <100>;
	phy-handle = <&eth2_phy>;
	st,ext-phyclk;
	status = "okay";

	sfp0: sfp {
		compatible = "sff,sfp";
		i2c-bus = <&i2c6>;
		mod-def0-gpios = <&gpioh 10 GPIO_ACTIVE_LOW>;
		los-gpios = <&gpioe 1 GPIO_ACTIVE_LOW>;
		tx-fault-gpios = <&gpioe 3 GPIO_ACTIVE_LOW>;
		tx-disable-gpios = <&gpioe 2 GPIO_ACTIVE_LOW>;
		rate-select0-gpios = <&gpioe 5 GPIO_ACTIVE_LOW>;
	};

	mdio {
		compatible = "snps,dwmac-mdio";
		#address-cells = <1>;
		#size-cells = <0>;

		eth2_phy: ethernet-phy@0 {
			/* compatible = "ethernet-phy-id2000.a0f3"; */
			reg = <0>;

			clocks = <&rcc CK_KER_ETH2>;
			interrupt-parent = <&gpiog>;
			interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
			reset-gpios = <&gpiob 2 GPIO_ACTIVE_HIGH>;
			reset-assert-us = <50000>;
			reset-deassert-us = <500000>;
			ti,op-mode = <DP83869_RGMII_100_BASE>;
			max-speed = <100>;
			sfp = <&sfp0>;
			modif,quirk-disable-clk-125;
                        modif,quirk-leds-cfg1 = <0xd230>;
                        modif,quirk-gpio-mux-ctrl = <0x00ba>;
		};
    	};
};
  • 0
    TI__Mastermind 36385 points

    Hi Nicolas,

    I have a couple questions:

    1. We have a fiber debug guide that I recommend reading through. The FEF error suggests some issue with the fiber interface, however I am interested in how the BIST test was performed. By 'looping the TX/RX slot of the SFP module' do you mean the SFP module has a loopback mode that connects these paths together, or are you soldering the lines together with a wire?

    2. Do you have a DP83869EVM to test with? This is a known-good platform that can be placed into reverse loopback to perform BIST PRBS testing over the MDI. 

    3. When you ping, are you seeing a refusal to identify the host (host unreachable) or are you able to ping the host but with packet loss?

    4. Have you performed any uni-directional testing? Ping testing will use both the TX and RX path on the interface, but there are throughput tests (like iperf3) that can send data one way or the other. Can you try sending data from the STM32 to the linux PC and see if you can get packets through, then reverse the direction by sending from the linux PC to the STM32? This would tell us if one path or the other specifically is failing.

    To answer your question

    Nicolas Bouquet said:
    is it normal that the nIRQ is stalled at 0 ?

    If the INT_N pin is constantly low, make sure there is an external pullup on this line and that the MAC is not holding this line low. If these are not the case and it is still held low, the PHY is sending an interrupt on the pin due to one of the enabled interrupt conditions. The interrupt register needs to be read in order to clear this condition.

    Best,

    Shane