pcupid emac debug SOP

REVISION HISTORY

Revision No.
Description
 Date
1.0
  • Initial release
    		•  06/19/2024
    1.1
  • Update pcupid reset debug and iperf debug
    		•  12/05/2024
    1.2
  • Remove web references and revise descriptions, and modify svg to English
    		•  07/22/2025

    Introduction: pcupid only rmii

    pcupid only has rmii, no mii. Therefore, attention should be paid to the read and write of the phy, which can refer to the Ethernet User Guide phytool and phyStatusWR phy reads and writes debug nodes in pcupid's.

    Issue 1: Short network cable cannot ping

    Process Method Exit Conditions Next Step or Conclusion Information to Provide to FAE Notes & Related FAQ
    A Swap the network cable with a normal network environment for cross-testing Exit Condition 1: Not a cable issue
    Exit Condition 2: Cable issue    		 Exit Condition 1: ==> B
    Exit Condition 2: End ==> Cable issue
    B Intervene with the intermediary device (switch or router) in a normal network environment Exit Condition 1: Network is normal after intervening with the intermediary device
    Exit Condition 2: Network is not reachable after intervening with the intermediary device    		 Exit Condition 1: ==> C
    Exit Condition 2: End ==> Intermediary device issue
    C Execute ping and check if the prompt is "Network unreachable" or stuck Exit Condition 1: Stuck ==> Indicates network is reachable
    Exit Condition 2: Network unreachable ==> Local network configuration is incorrect, such as gateway, IP segment, IP table, etc.    		 Exit Condition 1: ==> D
    Exit Condition 2: End ==> Network configuration issue
    D Method 1: Plug and unplug the cable, check the link up or down log
    Method 2: Read the link status bit of the phy register    		 Exit Condition 1: Link down or no link up log
    Exit Condition 2: Link up    		 Exit Condition 1: ==> E
    Exit Condition 2: ==> F    		 You can check the link through the phy register
    bank_phy0 offset1 bit2 :
    1: Link is up
    0: Link is down
    Method to read phy register:
    phytool read eth0/0/1
    echo phy_r 1 > phyStatusWR
    echo phyE_r 1 1 > phyStatusWR
    E Use ethtool to confirm if the current mode is force mode
    If so, manually switch MDI/MDIX, register: bank_phy0 offset 0x43 bit[12:11]
    If value != 2'b11, set value to 2'b11
    Otherwise, set value to 2'b10    		 Exit Condition 1: Currently not in force mode, or cannot link up after executing the above method
    Exit Condition 2: Currently in force mode, and can link up normally after manually switching MDI/MDIX    		 Exit Condition 1: ==> F
    Exit Condition 2: End ==> Auto MDI/MDIX issue    		 Provide serial log
    Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh    		 Command: ./ethtool eth0
    Currently resolved by SW PATCH
    F mii (internal phy): No need to check
    rmii (external phy):
    Public board: First check the corresponding dtsi of padmux, whether there is a conflict with the corresponding gpio pin or configured to other gpio modes. If not, check eth_mode.
    Non-public version: Need to check based on the actual pin design of the customer to see if there is an issue with incorrect pin multiplexing.    		 Exit Condition 1: Process E link down, and mii or rmii pin configuration is normal
    Exit Condition 2: mii or rmii pin configuration is normal
    Exit Condition 3: rmii pin configuration is abnormal    		 Exit Condition 1: End ==> Find FAE
    Exit Condition 2: ==> G
    Exit Condition 3: End ==> Pin configuration abnormal    		 Provide serial log
    Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh    		 pcupid eth_mode:
    RIU bank 0x103c offset 0x6e
    eth0: bit[1:0] BGA: 3 QFN: 2
    eth1: bit[7:4] BGA: 2 QFN: 1
    G After hitting ifconfig, ping for a while, then use ifconfig to check the statistics
    If the TX packets count increase is 0, then there is a problem in the TX direction
    If the RX packets count increase is 0, or errors increase, then there is a problem in the RX direction    		 Exit Condition 1: RX issue
    Exit Condition 2: TX issue
    Exit Condition 3: None of the above (both have counts) ==> Possible network environment issue    		 Exit Condition 1: ==> H
    Exit Condition 2: ==> M
    Exit Condition 3: Find FAE to analyze the environmental issue    		 Logs before and after ifconfig
    Auxiliary measurement and board-side packet capture information
    Network configuration information on both sides, such as IP address, MAC address, ARP table, routing table, etc.    		 If there are no counts, you can first check the RX issue, then check the TX issue
    H If rx packets are 0, then there is no counter issue
    If there are rx error counts, then it is an error packet issue    		 Exit Condition 1: No counter issue
    Exit Condition 2: Error packet issue    		 Exit Condition 1: ==> J
    Exit Condition 2: ==> I
    I rmii (external phy): Generally no need to adjust, if necessary, contact the phy manufacturer
    mii (internal phy): Adjust the driver's driving capability, try to enhance the tx driving capability and adjust the rx impedance
    After adjustment, try pinging again to see if it can ping through    		 Exit Condition 1: Can ping through
    Exit Condition 2: No errors count increase, but still cannot ping through
    Exit Condition 3: Errors count still increases    		 Exit Condition 1: End ==> Driver capability issue
    Exit Condition 2: ==> H
    Exit Condition 3: End ==> Need to find CAE to check if there is a hardware issue    		 Provide the serial log of the test pcupid does not have MII, you can first find CAE to check if there is a hardware issue
    J 1. PC opens wireshark for packet capture, board opens tcpdump for packet capture.
    2. Board pings PC, observe message interaction, check if the board sends out ICMP requests, and if the PC responds with ICMP replies    		 Exit Condition 1: Board does not send ICMP packets
    Exit Condition 2: PC does not send ICMP packets    		 Exit Condition 1: ==> L
    Exit Condition 2: ==> K
    K Confirm whether the PC/auxiliary testing device has a firewall enabled that causes the ICMP packets sent by the board to be filtered Exit Condition 1: Firewall is enabled
    Exit Condition 2: Firewall is not enabled    		 Exit Condition 1: End ==> Disable the firewall, it may be that the firewall intercepted the packets from the board
    Exit Condition 2: End ==> Possible network environment issue, if necessary, contact FAE for analysis    		 Logs before and after ifconfig
    Auxiliary measurement and board-side packet capture information
    Network configuration information on both sides, such as IP address, MAC address, ARP table, routing table, etc.
    L mii (internal phy): Generally, there will not be a clk error issue
    rmii (external phy): Check the SC_GP_CTRL's reg_ckg_emac related register values
    If the register values are correct, use an oscilloscope to check if the REF_CLK waveform is normal (if there is a waveform, whether the frequency is 50M)    		 Exit Condition 1: phy clk register configuration error or clk abnormal
    Exit Condition 2: phy clk normal    		 Exit Condition 1: End ==> Find FAE to confirm
    Exit Condition 2: ==> M    		 Provide the serial log of the test pcupid emac0:
    RIU bank 0x1133 offset 0x2a = 0x0004
    RIU bank 0x1133 offset 0x2b = 0x0004
    pcupid emac1:
    RIU bank 0x1133 offset 0x33 = 0x0004
    RIU bank 0x1133 offset 0x34 = 0x0004
    N Find FAE to confirm
    O Find FAE to confirm
    Q Use tool to read the OTP/Efuse's disable emac bit (if you don't know the method, find OTP owner for assistance) Exit Condition 1: Read result is 00 or 11 ==> Not disabled
    Exit Condition 2: Read result is 10 or 01 ==> Disabled    		 Exit Condition 1: End ==> Find FAE
    Exit Condition 2: End ==> Find SWPM    		 Provide a screenshot of the OTP reading result

    Issue 2: Long network cable cannot ping or packet loss

    Process Method Exit Conditions Next Step Information to Provide to FAE Notes & Related FAQ
    A Replace with a normal short network cable
    Check if it still cannot ping
    Or if the packet loss phenomenon has improved    		 Exit Condition 1: Still cannot ping or packet loss phenomenon has not improved
    Exit Condition 2: Can ping or packet loss phenomenon has improved    		 Exit Condition 1: ==> B
    Exit Condition 2: ==> D
    B Is the issue that it cannot ping or is there packet loss Exit Condition 1: Cannot ping
    Exit Condition 2: Packet loss    		 Exit Condition 1: ==> C
    Exit Condition 2: ==> G
    C Refer to Issue 1: Short network cable cannot ping for troubleshooting
    D Replace with a long network cable in a normal network environment to see if the issue still exists
    Or connect this long cable to other normal devices to see if the issue still exists    		 Exit Condition 1: Returns to normal
    Exit Condition 2: Issue still exists    		 Exit Condition 1: ==> End process, cable issue
    Exit Condition 2: ==> E
    E Confirm the length of the cable and the bandwidth in the usage scenario Exit Condition 1: Meets the usage scenario
    Exit Condition 2: Does not meet the usage scenario    		 Exit Condition 1: ==> F
    Exit Condition 2: ==> End process, usage scenario exceeds design capability    		 PCUPID supports
    100M bandwidth under 100 meters of long cable
    and 10M bandwidth under 250 meters of long cable
    F Change the device and cable to a direct connection environment to see if it returns to normal Exit Condition 1: Returns to normal
    Exit Condition 2: Issue still exists    		 Exit Condition 1: ==> End process, network environment issue
    Exit Condition 2: ==> G
    G Use ethtool to disable device auto-negotiation
    Configure both devices to the same working mode    		 Exit Condition 1: Returns to normal
    Exit Condition 2: Issue still exists    		 Exit Condition 1: ==> End process, auto-negotiation not effective issue, find corresponding FAE
    Exit Condition 2: ==> H    		 Exit Condition 1: ==> Provide serial log ==> Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh    		 Query the basic settings of ethx network port
    ./ethtool ethx
    Set ethx speed/duplex/auto negotiation
    ethtool -s ethx [speed 10|100|1000] [duplex half|full] [autoneg on|off]
    H Check if the device's CPU loading is normal
    Command: top -d 1
    You can see the CPU percentage occupied by processes, the second line's CPU: indicates CPU usage information, where idle indicates free resources. The less idle, the greater the CPU loading (cpu loading = 100% - idle)    		 Exit Condition 1: CPU loading is not fully loaded
    Exit Condition 2: CPU loading is fully loaded    		 Exit Condition 1: ==> I
    Exit Condition 2: ==> End process, check the program causing loading, find corresponding FAE    		 top -d 1 information
    In the UI interface after top, press 1 for information    		 Some versions of top are different from the common ones, you can use the command: busybox top -d 1
    -d 1 indicates refresh interval of 1s
    I Try to adjust the driver's driving capability:
    Enhance tx driving capability and adjust rx impedance
    After adjustment, see if it can ping/packet loss    		 Exit Condition 1: Improvement after adjustment
    Exit Condition 2: No improvement after adjustment    		 Exit Condition 1: End ==> Driver capability issue
    Exit Condition 2: End ==> Find corresponding FAE to troubleshoot    		 1. Provide serial log
    2. Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh    		 MII Command:
    echo swing_100 2 > /sys/devices/virtural/sstar/emac0/turndrv ==> Increase tx driving capability under 100M bandwidth by two levels
    echo swing_10 2 > /sys/devices/virtural/sstar/emac0/turndrv ==> Increase tx driving capability under 10M bandwidth by two levels
    echo rx_imp 7 > /sys/devices/virtual/mstar/emac0/turndrv ==> Set rx impedance to 7 (range -4~7)

    Issue 3: Insufficient network bandwidth

    Process Method Exit Conditions Next Step Information to Provide to FAE Notes & Related FAQ
    A Check if the speed test tool's command is correct, common issues include:
    1. iperf measures UDP bandwidth requires -b to specify maximum bandwidth
    2. iperf2 server and client both need to add -u to send and receive UDP normally    		 Exit Condition 1: Command is correct
    Exit Condition 2: Command is incorrect    		 Exit Condition 1: ==> B
    Exit Condition 2: End ==> Tool usage issue    		 Logs from the server and client side of testing tools like iperf iperf3 server:
    ./iperf3 -s [-i 1] [-p \]
    iperf3 client:
    ./iperf3 -c \<remote-ip> [-p \<port-id>] [-i 1] [-t 36000] [-b 95M] [-u] [-R]
    B 1. Check the port's rate and duplex mode
    2. Check if the rate and duplex mode of the opposite port configuration match
    3. If the rate mode of the opposite port is inconvenient to check, you can also check if there are a lot of error, collision, drop packets through ifconfig    		 Exit Condition 1: Everything is normal
    Exit Condition 2: There are anomalies, port configuration rate is low, rate mode of both ends do not match, there are a lot of error packet statistics, etc.    		 Exit Condition 1: ==> D
    Exit Condition 2: ==> C    		 Query the basic settings of eth0 network port
    ./ethtool eth0
    Set ethx speed/duplex/auto negotiation
    ./ethtool -s ethx [speed 10|100|1000] [duplex half|full] [autoneg on|off]
    C 1. Use ethtool to fix the rate and duplex mode of both ends and retest Exit Condition 1: Bandwidth is still insufficient
    Exit Condition 2: Bandwidth is normal    		 Exit Condition 1: ==> D
    Exit Condition 2: End ==> Auto-negotiation issue    		 1. Provide relevant logs during the test
    2. On-site network topology situation
    3. Assist FAE in reproduction
    D Check if the intermediary device (router, switch) has implemented QoS policies or bandwidth limiting policies affecting bandwidth
    Method: Use direct connection to test device bandwidth    		 Exit Condition 1: Direct connection test still shows insufficient bandwidth
    Exit Condition 2: Direct connection test shows normal bandwidth    		 Exit Condition 1: ==> E
    Exit Condition 2: End ==> Intermediary device speed limit
    E Check if the device and auxiliary device (such as PC) used for testing bandwidth have a firewall enabled
    If so, disable the firewall and retest    		 Exit Condition 1: Firewall is not enabled or bandwidth is still insufficient after disabling the firewall
    Exit Condition 2: Bandwidth returns to normal after disabling the firewall    		 Exit Condition 1: ==> F
    Exit Condition 2: End ==> Firewall reason
    F During the bandwidth testing process, use the top command to observe the system resource usage, mainly focusing on:
    1. Is there free memory (Mem: xxx free)
    2. Is there free CPU (CPU: xx% idle)    		 Exit Condition 1: System resources are sufficient
    Exit Condition 2: System resources are insufficient    		 Exit Condition 1: ==> G
    Exit Condition 2: End ==> Performance issue    		 1. Provide relevant logs during the test
    2. Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh    		 Idle indicates free resources. The less idle, the greater the CPU loading (cpu loading = 100% - idle)
    Some versions of top are different from the common ones, you can use the command: busybox top -d 1
    -d 1 indicates refresh interval of 1s
    G 1. Plug and unplug the cable and retest
    2. Replace with a normal network cable and retest    		 Exit Condition 1: Bandwidth returns to normal
    Exit Condition 2: Bandwidth is still insufficient    		 Exit Condition 1: End ==> Physical connection issue
    Exit Condition 2: End ==> Feedback to FAE    		 1. Provide relevant logs during the test
    2. Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh
    H Try changing the streaming direction or streaming device
    1. Use the -R command in iperf to change the streaming direction
    2. Replace with the same model device, using the same image    		 Exit Condition 1: Bandwidth returns to normal
    Exit Condition 2: Bandwidth is still insufficient    		 Exit Condition 1: End ==> Hardware issue, find CAE to troubleshoot
    Exit Condition 2: End ==> Feedback to FAE    		 1. Provide relevant logs during the test
    2. Execute the following script and provide the corresponding log
    pcupid-emac-dump-register.sh    		 If the bandwidth is normal after changing the streaming direction or replacing the device, you can change one of the server or client devices to determine whether it is the original device's tx issue or rx issue (it may also be both issues)

    Issue 4: Network cannot be used under uboot

    Process Method Exit Conditions Next Step Information to Provide to FAE Notes & Related FAQ
    A Connect the cable originally connected to the device to another network that is normal, test if the network is normal Exit Condition 1: Network is normal
    Exit Condition 2: Network is abnormal    		 Exit Condition 1: ==> B
    Exit Condition 2: End ==> Check network environment
    B 1. Check if the boot log prints "Net: MAC Address xxx" to confirm
    2. If there is no relevant print in the boot log, execute the estart command to initialize emac
    3. Check if the network is available    		 Exit Condition 1: Network is available
    Exit Condition 2: Network is not available    		 Exit Condition 1: End ==> Network card not initialized issue
    Exit Condition 2: ==> C    		 You can enable automatic initialization of the network card at boot by setting the environment variable autoestart=1
    C Check if the configuration of the environment variable is correct Exit Condition 1: Environment variable configuration is correct, and it is dynamically obtaining the IP address (dhcp)
    Exit Condition 2: Environment variable configuration is correct, and it is static IP
    Exit Condition 3: Environment variable configuration is incorrect    		 Exit Condition 1: ==> D
    Exit Condition 2: ==> E
    Exit Condition 3: End ==> Re-test after correct configuration    		 refer to the Ethernet User Guide Uboot cmd parameter description
    D Check DHCP
    Method: Change to someone else's MAC address, try DHCP to see if you can ping the PC    		 Exit Condition 1: dhcp cannot obtain IP or still cannot ping
    Exit Condition 2: Network is normal    		 Exit Condition 1: ==> E
    Exit Condition 2: End ==> Possible IP address conflict, check if there are other devices with the same MAC address, or find MIS    		 refer to the Ethernet User Guide Uboot cmd parameter description
    E Internal phy: No need to check
    External phy
    1. Check if there is "Can't get correct PHY Addr and reset to 0" in the boot log, if there is this log, it indicates abnormal mdio connection
    2. Use the command: phy_r 1, if the read value is all 0 or all F, it indicates abnormal mdio connection    		 Exit Condition 1: Abnormal mdio connection
    Exit Condition 2: Normal mdio connection    		 Exit Condition 1: ==> G
    Exit Condition 2: ==> F    		 Relevant logs during debugging
    Assist FAE in reproduction
    F Use the command: phy_r 1, check the phy link status Exit Condition 1: Link up
    Exit Condition 2: Link down    		 Exit Condition 1: End ==> Find FAE for feedback
    Exit Condition 2: End ==> Possible phy issue, try replacing phy or find CAE for troubleshooting    		 Debugging process log You can check if link is up through the phy register
    bank_phy0 offset1 bit2 :
    1: Link is up
    0: Link is down
    G Check based on the customer's actual pin design to see if there is an issue with incorrect multiplexing of rmii pins Exit Condition 1: No error multiplexing in pinmux
    Exit Condition 2: Error multiplexing in pinmux    		 Exit Condition 1: ==> H
    Exit Condition 2: End ==> Pin multiplexing error    		 Debugging process log
    H Use LA or oscilloscope to measure signals/waveforms, observe:
    1. High level around 3.3V, low level 0V
    2. Whether the waveform is normal without noise    		 Exit Condition 1: Signal/waveform is normal
    Exit Condition 2: Signal/waveform is abnormal    		 Exit Condition 1: Contact FAE to continue troubleshooting
    Exit Condition 2: End ==> Check if the voltage is normal, chip soldering issues, pins controlled by phy, etc.    		 Debugging process log Refer to Issue 5: New model Ephy or switch network card adaptation failure for troubleshooting
    1. Abnormal voltage may need to check jump caps, need to contact CAE for analysis
    2. Abnormal waveform, with noise, may be chip soldering issues, or external phy controlling pins. You can try phy reset, refer to the phy reset configuration and FAQ_Q1 in Ethernet User Guide

    Issue 5: New model Ephy or switch network card adaptation failure

    Process Method Exit Conditions Next Step Information to Provide to FAE Notes & Related FAQ
    A Check if the phy or switch pins are physically connected to the chip
    Check for any loose connections    		 Exit Condition 1: Physical connection is normal
    Exit Condition 2: Not connected normally    		 Exit Condition 1: ==> B
    Exit Condition 2: End ==> Physical connection abnormal
    B Check the pinmux of the connecting pins
    Ensure all are set to the correct mode, and there are no occupation issues    		 Exit Condition 1: Pinmux is normal
    Exit Condition 2: Pinmux is abnormal    		 Exit Condition 1: ==> C
    Exit Condition 2: End ==> Pinmux abnormal    		 pcupid eth_mode:
    RIU bank 0x103c offset 0x6e
    eth0: bit[1:0] BGA: 3 QFN: 2
    eth1: bit[7:4] BGA: 2 QFN: 1
    C Check the actual configured reset timing according to the reset timing requirements in the phy manual or switch manual Exit Condition 1: Timing is normal, reset pin configuration is correct
    Exit Condition 2: Timing is incorrect, or reset pin is occupied    		 Exit Condition 1: ==> D
    Exit Condition 2: End ==> Reset pin error    		 The sw phy reset logic of pcupid is due to the external reverse circuit, so the code first pulls high and then pulls low
    The reset pin of pcupid is not connected by default, a resistor needs to be soldered for the chip to control the reset pin
    By default, pull the reset pin low for 20ms, then pull the reset pin high for 50ms
    The customer may have modifications, need to confirm if the actual reset timing meets the requirements
    Also need to confirm if the reset pin selection is correct, whether there are pinmux error multiplexing issues
    D Confirm if fixed-link is enabled
    Switch network card adaptation or not focusing on phy status (no mdio, etc.) requires enabling fixed-link    		 Exit Condition 1: Already enabled or does not need fixed-link
    Exit Condition 2: Not enabled    		 Exit Condition 1: ==> E
    Exit Condition 2: End ==> Fixed-link not enabled    		 uboot refers Uboot CONFIG configuration instructions in Ethernet User Guide to set KCONFIG.
    kernel need remove the phy-handle attribute and node mdio-bus@emacx, and add a fix-link node:
    fixed-link {
    speed = <100>;
    full-duplex;
    };
    E Check if the clk provided by the phy/switch is 50Mhz Exit Condition 1: Yes
    Exit Condition 2: No    		 Exit Condition 1: ==> F
    Exit Condition 2: End ==> Clock mismatch causing adaptation failure
    F Confirm with the phy manufacturer or switch manufacturer whether a driver update is needed Exit Condition 1: No update needed
    Exit Condition 2: Update needed    		 Exit Condition 1: End ==> Contact FAE for further troubleshooting
    Exit Condition 2: End ==> Driver needs to be updated    		 Debugging process log EXTERNAL PHY PORTING SOP

    Issue 6: Frequent network disconnections

    Process Method Exit Conditions Next Step Information to Provide to FAE Notes & Related FAQ
    A Check if frequent disconnections are caused by cable quality
    Swap the cable with a normal network environment for cross-testing    		 Exit Condition 1: Not a cable issue
    Exit Condition 2: Cable issue    		 Exit Condition 1: ==> B
    Exit Condition 2: End ==> Cable issue
    B Check if it is due to the network environment
    Change to direct connection testing to see if it frequently disconnects    		 Exit Condition 1: Direct connection test still frequently disconnects
    Exit Condition 2: Network is normal    		 Exit Condition 1: ==> C
    Exit Condition 2: End ==> Network environment or intermediary device issue
    C Check the phy status register, see if it changes frequently, read the link status to see if it is consistent with the current Exit Condition 1: phy status is normal
    Exit Condition 2: External phy and phy status is abnormal
    Exit Condition 3: Internal phy and phy status is abnormal    		 Exit Condition 1: ==> D
    Exit Condition 2: ==> E
    Exit Condition 3: End ==> Feedback to FAE    		 Debugging process log You can check the link through the phy register
    bank_phy0 offset1 bit2 :
    1: Link is up
    0: Link is down
    Method to read phy register:
    phytool read eth0/0/1
    echo phy_r 1 > phyStatusWR
    echo phyE_r 1 1 > phyStatusWR
    D Check if the device's port configuration (duplex mode/rate) matches the opposite port Exit Condition 1: Not matching
    Exit Condition 2: Matching    		 Exit Condition 1: ==> Retry after configuring matching port mode
    Exit Condition 2: End ==> Feedback to FAE    		 Debugging process log Command: ./ethtool eth0
    E Check the pinmux of the connecting pins
    Ensure all are set to the correct mode, and there are no occupation issues    		 Exit Condition 1: Pinmux is normal
    Exit Condition 2: Pinmux is abnormal    		 Exit Condition 1: ==> F
    Exit Condition 2: End ==> Pinmux abnormal    		 pcupid eth_mode:
    RIU bank 0x103c offset 0x6e
    eth0: bit[1:0] BGA: 3 QFN: 2
    eth1: bit[7:4] BGA: 2 QFN: 1
    F Use an oscilloscope to check if the waveform of the phy crystal oscillator pin is normal Exit Condition 1: Waveform is normal
    Exit Condition 2: Waveform is abnormal    		 Exit Condition 1: ==> G
    Exit Condition 2: End ==> phy crystal oscillator damaged
    G Check the actual configured reset timing according to the reset timing requirements in the phy manual or switch manual Exit Condition 1: Reset flow is correct
    Exit Condition 2: Reset flow is incorrect    		 Exit Condition 1: End ==> Feedback to FAE
    Exit Condition 2: End ==> Adjust reset flow and retest    		 Debugging process log The sw phy reset logic of pcupid is due to the external reverse circuit, so the code first pulls high and then pulls low
    The reset pin of pcupid is not connected by default, a resistor needs to be soldered for the chip to control the reset pin
    By default, pull the reset pin low for 20ms, then pull the reset pin high for 50ms
    The customer may have modifications, need to confirm if the actual reset timing meets the requirements
    Also need to confirm if the reset pin selection is correct, whether there are pinmux error multiplexing issues