STM32H7 and DP83848

[EAS198585]

I've developed a custom board featuring an STM32H723GTX MCU, which is interfaced with a DP83848 PHY via an MII connection.

Additionally, I'm working with a Nucleo-F767ZI board. When configuring LWIP in the "Platform Settings", I encounter two PHY driver options: LAN8742 and DP83848. However, upon switching to the custom board equipped with the STM32H7 series MCU, the DP83848 option is no longer available.

I'm seeking assistance to address this issue, especially considering the recent update to CubeIDE (version 1.15). Any guidance on how to integrate the DP83848 PHY driver with the STM32H7 series in this context would be greatly appreciated.

[Pavel A.]

STM32H723GTX supports both MII and RMII. You can start with any ST ethernet example for a STM32H723 board and modify the PHY code. Unfortunately CubeMX/IDE templates are not very flexible with the PHY selection. Adapting the PHY traditionally is a hand work (( Here you can find help:

https://www.fiverr.com/categories/programming-tech/electronics-engineering/embedded-systems-iot?ref=platform%3Astm32

[WikNV]

Hi,
It is really strange that ST or the STM32CubeIDE team have sorted out this in a good way.
One would assume that the STM32CubeIDE could be used in production code, this seems not to be the case. Quite many top tier STM32 MCUs support RMII/MII, and there should be no question about how to add new BSP components. Most of the drivers are already proved, but not possible to import. I have succeeded in adding DP83848, in RMII but i need to leave the "Found solution" as Undefined and get a warning each time i generate. This is annoying.....

The problem is maybe mostly due to the fact that MicroXplorer part of configuring and generating is difficult to maintain within the eclipse environment?
If you look at other environments e.g espressif they are aiming for a more VSCode solution of configuring their MCU. 
I don't see the problem in developing something similar for STM32 MCUs? And I suppose the first step would be to deprecate the MicroXplorer solution in favor of something human read-able (open the ioc and see), im thinking a config that is maybe JSON based. Many times I have scratched my head and wondered, wth did i do to my ioc that it diffs so much.
Most of these things are possible in VSCode, question is why isn't it more common to see dev-tools in this environment? politics / licensing/ money ? many questions.
It would be interesting to talk to a STM32CubeIDE dev to get their opinions on the matter.

[Pavel A.]

> One would assume that the STM32CubeIDE could be used in production code

It is a development tool - but can be used in production code (perhaps surprising to the team). This does not mean it can produce a finished project by pointing and clicking. Some manual work (and skills needed for it) still is required.

> The problem is maybe mostly due to the fact that MicroXplorer part of configuring and generating is difficult to maintain within the eclipse environment?

Not that. CubeMX is a standalone GUI, not related to Eclipse. The CubeIDE component is practically same.

> And I suppose the first step would be to deprecate the MicroXplorer solution in favor of something human read-able (open the ioc and see), im thinking a config that is maybe JSON based

Improving the .ioc structure to be more human-friendly and version control friendly is a good idea. Long due.