H743 and LAN8742 init

[JojoS]

I'm still struggling with the ethernet code. I have some custom hardware that where several H743 controllers are powered on at the same time and sometimes they don't get all a connection (no IP address from dhcp). But I can reproduce this error as well with a NUCLEO_H743ZI2 rev. E-01 when I power it from ext. 5V, or unplug/plug the STLink Jumper.
I have traced it downto a reset timout error from LAN8742_init(). The error code is not checked in the Cube generated software, it looks like this:https://github.com/JojoS62/Test-H743ZI2-lwip/blob/79bd3eb6f7d82179384d7a70a9411745cac3ca20/LWIP/Target/ethernetif.c#L252

What can be the reason that the soft reset sometimes fails?

 

[JojoS]

I'm one step further. The PHY address was read wrong, it was set to 31, the last address. It looks like reading from SMR fails and is returning a false address.
I have fixed the address to 0 and all reboots with power cycle are working fine.

The RXER/PHYAD0 pin is connected via 10 k to GND, is this resistor value low enough? Could this be the source for addr 31? In case of an error I would expect to read addr = 1. So I'm not sure if this really the source of the problem.
The SMR is read in a loop and it is checked for read error and this does not happen. And why is SMR read in a loop? This piece of code is really strange. The PHY address is stored in SMR 0:4 and could be masked out directly.

 

[JojoS]

finally, I found this solution:
this read for SMR fails:
https://github.com/STMicroelectronics/STM32CubeH7/blob/c2b13142a354d26b0baa5f505bb5607cd4aadd88/Drivers/BSP/Components/lan8742/lan8742.c#L98

When I add a delay(50), then it works. This delay can be added to
https://github.com/STMicroelectronics/STM32CubeH7/blob/c2b13142a354d26b0baa5f505bb5607cd4aadd88/Projects/NUCLEO-H743ZI/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src/ethernetif.c#L555
Then the lower level function in lan8742.c has not to be touched.

[Pavel A.]

Could you also update your ticket ? (ask them to fix the template that produces  ethernetif.c )

[JojoS]

yes, I can check but I have not modified this template before.

I'm not quite sure why this delay works, but I can definitely reproduce the problem by omitting the delay. And, it happens only in the case of Power On, not when the board is resettet by reset button or STLink.
One open question is why the failing access to the SMR does not report an error. The function HAL_ETH_ReadPHYRegister checks only for timeout of the busy bit.

[Pavel A.]

>  it happens only in the case of Power On

Is there a separate crystal oscillator for the PHY?

[JojoS]

Yes, the PHY has its own crystal.
I have measured the time from power up until LAN8742_init, it is only 3 ms. So the H743 ist simply too fast...
The PHY chip needs more time for reading the strapping bits (also 23 ms?) and seems not to respond within this time.
Now I have put a HAL_Delay(100) before MX_LWIP_init and it works reliable.Although the 2 s delay after init and link check is stll a guess. But I don't know a good way to change lots of the generated code and keep it controlled by git. The templates are in the installation directory, I have not tried to use templates in the project directory. Is this possible? The documentation in CubeMX about the templates is poor, I have not managed it to write my own. Are there more resources on this topic?

[Pavel A.]

These crystals could be slow to stabilize. Could easily take *seconds* unless well designed.

The Cube documentation, of course, cannot cover all 3rd party components. But ST has an appnote on oscillators which may help.

[JojoS]

I haven't designed the hardware and I know this document. I'm pretty sure that the oscillator is not a problem. It is about the SMA communication with the MDIO/MCLK and about 2 MHz clock. This communication fails when the phy is not yet ready. The datasheet says: 'External power supplies at operational level to nRST
deassertion: min 25 ms'. This is not checked in the generated software.
I can reproduce the problem on a Nucleo H743 by using an external power supply. The phy is accessed too early. The LAN8742_init is also overengineered, it tries to find the address from 0...31, but the LAN8742 has only one strapping bit for address 0 or 1, so this init code is nonsense. Seams to be copied from a TI DP83xxx phy chip. It would be better to check if the chip is ready. In busy case, the response from SMR is 0xffff, but I'm not sure if this is a reliable method to check the ready state.