H723 ethernet

[jlogan03]

• Add ethernet example for NUCLEO-H723ZG board based on the ethernet-rtic-stm32h735g-dk example
• Tweak ethernet initialization to be compatible with more H723 chips/implementations
  • For some reason the units I have in a custom implementation freeze if the ethernet DMA is reset after the AHB is brought up
  • Resetting the DMA in either order works on the nucleo board, so going with the one that is compatible with both
  • Could use another look at the effect on the other ethernet examples - I don't have the other boards so I can't check if they're affected, but I think they should be fine based on the datasheet

Proof that the link comes up on the nucleo board:

nucleo-h723zg_link.mp4

[jlogan03]

I'm unable to reproduce the build error locally. The build error is referencing smoltcp 0.10.0, but Cargo.toml specifies 0.9.0 and the examples build fine with that version. Might be a build cache issue?

[jordens]

Mid-term it might be better to use move over to stm32-eth once stm32-rs/stm32-eth#77 lands.

[jlogan03]

Ah awesome, good to see it's getting its own crate - I'll close this out and see if any of this is needed over there. Thanks!

[jordens]

But let's make sure the 723 is actually supported there, that it lands in stm32-eth, and that stm32h7xx-hal migrates.

[richardeoin]

Yes it would be great to merge this fix and example for the H723 already. Could you consider re-opening the PR @jlogan03 ?

I'm not clear why smoltcp 0.10.0 is used in the CI build. In any case we should re-base this onto master (which does use 0.10.0) and update the example, otherwise it will correctly fail CI when merged.

[jlogan03]

Sure thing - rebased & updated the example for smoltcp 0.10.x

[richardeoin]

The github merge queue reported a conflict with the base branch, but there was no conflict. Presumably a github bug, so I merged manually.

[richardeoin]

For now I'm going to revert the changes to eth.rs from this PR, since they break 2/3 of the other supported boards.

RM0468 Rev 3 contains this note:

@jlogan03 I guess these clocks are different on your custom implementation. It may be that asserting SWR before ETH1MACEN is set does not actually perform a full reset, while if you assert SWR later you do get a reset that becomes a freeze if a clock is not running?

[jlogan03]

Interesting, I'll have to dig into that. Both my implementation and the dev board use the internal clock in the chip, and the same code runs on both (including the same clock setup), so it'll be an adventure figuring out why it trips some boards and not others.