STM32H7 LAN8742 LwIP only works fine after power-up, not after reset

0
votes

I have a weird problem on hand, I never saw it before. Yet, I'm still trying to pinpoint the problem. I have an STM32H753VIT and a LAN8742 ethernet controller connected to it. I run LwIP in NO-SYS mode. It only works fine after a cold power-up, but not after a hardware reset (button or ST-LINK probe). It runs a simple TCP echo server. If it runs, I can ping it, and it responds to a TCP client.

But after a hardware reset, I no longer can ping it, and it does not respond as an echo server. I noticed the green (link) LED on the interface will remain off after the reset.

I could see the LAN8742_Init function executes successful after a hardware reset, but it sees no longer RX data available in the function low_level_input.

On a Nucleo-H743ZI, I run the same code, and this also works after a hardware reset. Note the code is only slightly different as pin mapping is slightly different. Code for well working Nucleo-H743ZI: https://github.com/bkht/Nucleo-H743ZI_LAN8742_LwIP_NO-SYS Code for strange behaving STM32H753VIT: https://github.com/bkht/STM32H753VIT_LAN8742_LwIP_NO-SYS

The nRST of the MCU is connected to the nRST of the LAN8742A and a capacitor of 100nF is used to GND. I've a reset switch and I tried a Pull-up resistor, nut no luck. I have added a reset button, and this found that a longer hardware reset does not work either.

I'm thinking in the direction of timing, or memory contents. Has anybody ever seen such start-up behavior?

1
stm32ethernethallwip
Have you checked the datasheet of LAN8742A to see the minimum reset pulse time required? I've ran into this exact issue in the past where I've had the same hardware layout - nRST of STM and RST of PHY were connected and those were connected to the debugger connector. In my case, PHY required a longer reset pulse than STM, which would cause it to sometimes "lock", unless a longer reset pulse was done. – Jacek Ślimok
You also probably want to check that minimum required reset pulse time and compare it with the pulse generated on nRST by STM when you perform a "software" reset (watchdog, core reset e.g. through NVIC_SystemReset). If it's longer than the one output by STM, you may later run into issues in the field when you for example perform a firmware upgrade and perform a software reset. – Jacek Ślimok
Thanks for the responses! Yes, I thought of this too, and added a reset button, and found that a longer hardware reset does not work either. Just for test, and although the reset goes to high without it, I tried it with pull-up resistors of various values, but no luck. – Jack
Finally I solved it. It was a software problem. Or actually the straps in HW seem wrong, which I solved in SW. By adding one line into the code. After a software reset of the LAN8942A, I set the auto-negotiation bit (bit 12) in the BCR (0x00) register. I will update the code in github, for those people interested. – Jack
Please refrain from adding SOLVED to the title. See meta.stackexchange.com/questions/116101/…. Instead, answer your question below. – user47589

1 Answers

2
votes

Solved, after the code that performs a software reset of the LAN8942A, I added one line to set the auto-negotiation bit (bit 12) in the BCR (0x00) register.

pObj->IO.WriteReg(pObj->DevAddr, LAN8742_BCR, LAN8742_BCR_AUTONEGO_EN);

I will update the code in github, for those people interested.