Need support for Interfacing Dp83620 driver with SMT32H753 in RMII mode

[Rsukh.1]

Hi everyone, my name is shekhar. I have to interface Dp83620 with STM32 in RMII mode. CubeMx supports only LAN8742. Can I get support for dp83620 driver code for STM32 in RMII mode? Thank you.

[TDK]

STM32CubeMX supports interfaces, not individual chips. Since DP83620 has an RMII interface, you should be able to generate code to initialize it with CubeMX.

[Rsukh.1]

Hi TDK,

Thank you for your support. I have couple of doubts, inorder to initialize dp83620 PHY driver from CubeMx, (#1). Do we need to add driver code of it somewhere in STM32 installation path? Or (#2). CubeMx will detect dp83620 driver automatically from PCB(where it mounted) and install it's drivers automatically and ready to generate the code in RMII mode?..

[Piranha]

To support a standard PHY on MDIO configuration interface, one just have to define a status register address and speed and duplex bits. And all TI's PHYs are equal in this regard. Therefore one can just use the configuration of DP83848, which can be selected even in the CubeMX broken bloatware generator.

[Rsukh.1]

Hi Piranha,

Thank you for your suggestions. Will check and let you know.

[JMall]

Hi. I am also looking at interfacing to a PHY that is not the LAN8742 on the STM32H753. I tried using CubeMX, but it only gave me the option of the LAN8742 for the Driver_PHY.

Also, searching though the installed software package, I could find files only related to the LAN8742.

Is there anywhere else to go looking for driver code?

Thanks.

[Piranha]

One literally has to modify 3 constant values, which I named in my previous comment. If one is incapable of doing that, there is no point in trying to deal with networking at all.

[Tesla DeLorean]

>>Is there anywhere else to go looking for driver code?

PHY Mechanics only involves a handful of registers, the data sheets should be sufficient to adjust any address/settings unique to any given one following the overall standard.

The trick in general to put the automated tool down, and review the hardware expectations.

Should the autogen tool have more options? Sure I've been pushing ST to have a broader understanding of what customers are using for the best part of a decade, but generally they only automate for hardware they have delivered on DISCO, NUCLEO, EVAL boards, not random hardware picked by the end-customer. So if you stray outside the lines of the "Reference Designs", expect to have to pick up all the data sheets, and work on the plumbing.

[JMall]

Thanks, Tesla, it's very helpful to know that it is not as simple as selecting the DP83848 in CubeMX. And migrating the provided LAN8742 driver code does not look too difficult at all.

Thanks, again.

[Piranha]

If the PHY doesn't have MDIO or it has multiple physical interfaces, then it will require a different code. Otherwise for the standard (R)MII/MDIO PHYs all of the basic functionality is standardized, including software reset, power down, speed/duplex mode selection, auto-negotiation and link state. The only typically necessary thing, that is not standardized, is extended status register, which returns the auto-negotiation result. Those are the three constants to adapt for a particular standard PHY. And, as I said, manufacturers typically keep those registers and bits compatible between their own devices. Of course the Microchip's LAN*** and KSZ*** series have different implementations, because those series come from different manufacturers they acquired, but still the new devices continue the trend of either one or the other series.

The fact that ST cannot make the basic Ethernet and lwIP working for 15 years and counting, but implemented 1000+ code line "chip specific" driver for a functionality that is standardized, just shows how far from the real life usage their incompetent software developers are.

And yes, I know what I'm talking because I actually read the documentation and develop code, not just click CubeMX bloatware generator. Here is an useful information on Ethernet related problems with ST's code:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

The most ironic thing is when the people believe that, for example, PHY driver, which really is simple, is "not that simple", but then are completely OK with using ST's totally broken ETH MAC driver and lwIP integration code, both of which indeed are not that simple...

[Pavel A.]

Many PHY drivers can be found in the Keil CMSIS drivers repo .

You can only borrow the .h file with register definition and leave the rest from ST examples, as @piranha advised.

[Piranha]

And, to get those chips working, none of them actually require anything more than adapting these few constants:

https://community.st.com/s/question/0D53W000015bQsFSAU/cant-get-f746zg-nucleo-ethernet-to-work-with-the-lwip-example-on-cubeide

[JMall]

Thanks everyone for the help.