Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

regression in ethernet DMA initialization for H743 chips #448

Closed
ritikmishra opened this issue Aug 25, 2023 · 4 comments · Fixed by #450
Closed

regression in ethernet DMA initialization for H743 chips #448

ritikmishra opened this issue Aug 25, 2023 · 4 comments · Fixed by #450
Labels
bug Something isn't working

Comments

@ritikmishra
Copy link

One of the changes merged in by #445 moves the write to the ETH_DMAMR register to before the ethernet peripheral clocks are enabled

https://github.com/stm32-rs/stm32h7xx-hal/pull/445/files#diff-bc6d950ee1ed8e0df070d5ac2e9190dea3730fc251d9ca1b3c9bdad8c7f0bd3aR458-L478

This breaks the ethernet DMA initialization on my STM32H743IIT6

@ryan-summers
Copy link
Member

I can confirm that Stabilizer's hardware-in-the-loop tests indicate that networking no longer functions on the H743 chips with the latest hal rev

@ryan-summers ryan-summers added the bug Something isn't working label Aug 28, 2023
@richardeoin
Copy link
Member

I can reproduce this on two development boards:

  • STM32H747I-DISCO (STM32H747XIH)
  • STM32H735G-DK (STM32H735IGK)

For me the symptom is that the PHY never reports the link is up (over the MDIO interface) and the board does not respond to pings. Reverting the change to eth.rs from #445 resolves the issue.

Why the change in #445 is required for the NUCLEO-H723ZG but fails on the STM32H735G-DK is really not clear. Those STM32 part share a reference manual, so I would expect them to both work with the same initialisation sequence. Perhaps either the board power configuration (LDO vs SMPS) or PHY configuration is to blame.

In the meantime I would propose reverting the change to eth.rs from #445 until we understand why it is needed for the NUCLEO-H723ZG.

@ryan-summers
Copy link
Member

I'm on board with your assessment @richardeoin - I didn't see a thorough explanation in #445 why it was required outside of "Seems to work now". If that truly is the case, we can device gate it, but feels like more investigation is required.

@richardeoin
Copy link
Member

Reading #445 more carefully I see it says "either order works on the nucleo board". The change is not required for the NUCLEO board, only for some custom hardware with a H723. I suspect the difference there is not the H723 vs other H7 parts, but the PHY configuration in that custom hardware.

So by reverting the change we get a configuration that works with all the NUCLEO/DISCO boards we know of, and all but one of the custom hardware items. I think that's the right choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants