-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Ethernet PHY and arduino-esp32 2.0.0/IDF 4.4 #5239
Comments
same problem here. Are using also the clock on an other pin. So would be great to have an soultion that is not building your own Librarie. |
you are not passing a clock mode argument to eth.begin in your sketch. arduino-esp32/libraries/WiFi/src/ETH.cpp Line 114 in e6ba8c7
that should still work. |
oh, it looks like the argument was removed. That is not good, as I also require this. |
Exactly, this parameter was removed...but i think that is not the only problem (i've tested hardcoding this parameter in |
i have hope that they will change something like that in the final release.We are using the same pinout like olimex uses in one of ouer products. |
Absolutely an issue, a clarification is needed! @me-no-dev...maybe you're the right guy! 😀 |
Hmm... I'm also missing this. I've added this feature 4 years ago and now it has vanished... :-( |
@sauttefk, initially i was suspecting that there was only this problem (missing Nothing changes, same result. |
I can drop a minor update about that, i've tried to compile a "plain" esp-idf project (not esp32-arduino), basically i've used the iperf example, configured GPIO17 as ETH_CLOCK_GPIO17_OUT, flashed using idf.py and it works. I've tested it using IDF 4.4, here is my sdkconfig: Click to expand
So, i think that something on esp32-arduino side is not aligned and needs to be fixed. |
Hi All. ESP-IDF API has changed much since v3.3. RMII Clock out is no longer controlled from the app, so some things ended up misconfigured :) Please try using the github version and |
I'll try it right now, thanks @me-no-dev: i have a bunch of boards on my hand i can test it and let you know |
fixes #5239 * Add back clock mode argument
Hi guys,
In these days i'm trying to use the arduino-esp32 2.0.0 beta version on my test lab boards (OLIMEX ESP32-POE).
Most of the functionalities are okay, but when i try to use the onboard ETH lan chip (LAN8720) nothing works.
I know that "nothing works" is not correct in the IT/Electronics field, but i'll try to explain more in depth in the following paragraphs.
Preliminary informations: this board uses the
GPIO12
asETH_PHY_POWER
and theGPIO17
asETH_CLK_MODE
.I'm using the standard sketch that works for other versions of arduino-esp32 in order to power up the ETH, acquire an IP from DHCP server and do a sample request to google: here it's the sketch
but when i open the arduino console i see those messages:
At this point, it seems that the ETH phy chip isn't initialized correctly, so i've picked up my oscilloscope and this is what i've seen:
Older esp32-arduino (1.0.4 and 1.0.6), probe on GPIO17, as you can see, there is a clean and nice looking 50MHZ signal coming out from GPIO17, as expected:
When i use the esp32-arduino 2.0.0, probing GPIO17 there isn't any signal coming out from that pin, as you can see:
...so, i've asked to gitter, and @lbernstone clearly says that starting from esp-arduino 2.0.0 the eth clock gpio output is hardcoded in sdkconfig and if i want to modify it i need to compile my own libraries.
Anyhow...i've repeated the same probing test on GPIO0 (...thinking that the phy clock out comes out from the "default" GPIO0 pin...), but also in this case, nothing comes out from that:
This seems odd...i mean, in the past using a define (
#define ETH_CLK_MODE ETH_CLOCK_GPIO17_OUT
) everything was okay and no custom libraries were needed...how it's possible that now anyone who is not using the same pinout definition for ETH phy chips of the ESP32-Ethernet-Kit needs a custom compiled libraries?Please clarify those aspects and help us to make the phy chips work again, because i think that i've misinterpreted those changes and maybe is more simple than reported!
The text was updated successfully, but these errors were encountered: