Export, demonstrate ENET peripheral #146
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I linked with SDK code to simplify PLL1 bringup, remuxed ENET clocks, forced a 100Mbit/s PHY autonegotation, and disabled the 10Mbit/s driver config. There's no more CRC or alignment errors in the receive path, and the example works as expected. Looks like it's time for the inevitable: make the 1170 clocks useful. What's this analog IP interface thing...? |
|
A single setpoint also works for PLL1 bring-up, with no analog IP interface needed. The MAC and PHY are up to 100Mbit/s. |
This provides important signal: imxrt-enet builds without issue for all of these MCUs. That doesn't necessarily means it works, but it's nice when the peripheral blocks are consistent across the MCUs.
It's the ENET instance that does not support 1Gbit operation. The PHY reset and configuration is hard-coded into the board module, and it's fixing the PHY for 10Mbit/s operation. If I go faster, the receive pathway doesn't work (but the transmit pathway seems fine). One thing I'd like to rule out is the clock quality; bringing up the ENET PLL is a TODO.
Works on my hardware (1170EVK, and a Netgear R7000 router w/ stock firmware). Note that I'm throttling the ENET's receive speed to 10Mbit/s, full-duplex; see previous commit for more info.
Enable the PLL_LDO in all setpoints, and enable PLL1 in setpoint 1. Since I'm only using setpoints for PLL_LDO and PLL1 bring-up, I'm implementing the rest of the GPC state machine in software (specifically for the ENET clocks). This seems sufficient for enabling PLL1 and getting a clean 50MHz ENET reference clock. I can increase the ENET transfer speeds in the MAC and PHY. The GPC, PMU, and CCM APIs are a bare-minimal. They should be introduced in a separate commit / PR. But they're good enough for prototyping.
Monitor your board's serial log for the IP address it's assigned. Then, pass it into this command-line tool to make sure you can connect, send a message, and receive the response.
Use the constant enum to change the example's behavior. This commit also allows the TCP socket to be re-used after the client disconnects. Each example works in debug and release builds (though I needed a separate fix in the ENET driver due to a poorly-written debug assert).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
rtic_enet_dhcp_tcp.rsexample runs a DHCP client on an i.MX RT 1170EVK. Once assigned an IP address, it creates a TCP socket that loops back any data sent to it. The example demonstrates some support forsmoltcp. It depends on a prototype driver, imxrt-enet, which I'm still thinking through.The example works on my 1170EVK with my router, but there's still more to do. In particular, I can't bring the speed up to 100Mbit/s; if I try, the receive path doesn't work reliably. MIB statistics show CRC and alignment errors for receive, but transmit is fine. I'm notably not bringing up the Ethernet PLL, so next step might be to rule out clock quality issues. Until then, you're playing with a 10Mbit/s driver, enforced by a restricted PHY autonegotiation.