Incorrect EMAC Clock Validation for PSRAM

[nirav.agrawal]

Hello,

A) I am working on one project where I need to keep both WIFI and Ethernet initialized and altered in run time. Meaning, ESP32 should be working with WIFI but whenever Ethernet adaptor plugged, it should switch to the Ethernet interface and vica-versa.
Here, I am getting "Link Up" & "Link Down" event from emac though there is no ethernet adopter connected.
can you let us know what would be causing this? because of this issue, Internet connectivity over WIFI is not pertained.

B) One another issue I found in emac clock validation.
We are using ESP32 module with PSRAM. Because of this, GPIO16 & GPIO17 occupied by PSRAM and could not be used by EMAC clock configuration. To deal with this, we configured GPIO0_OUT to provide 50MHz clock to emac.
But when we initialize ethernet, it throws below error message and ethernet could not initialized properly.
"GPIO16 and GPIO17 has been occupied by PSRAM, Only ETH_CLOCK_GPIO_IN is supported!"

I believe that there is an issue in emac clock validation where psram availability verified. esp-idf does not have check for GPIO0_out emac clock mode which can be allowable in case of psram presence. But according to below code, this condition not verified and ethernet initialization failed.

Code: [Select all] [Expand/Collapse]

1.     periph_module_enable(PERIPH_EMAC_MODULE);
2.  
3.     if (emac_config.clock_mode != ETH_CLOCK_GPIO0_IN) {
4. #if CONFIG_SPIRAM_SUPPORT
5.         if (esp_spiram_is_initialized()) {
6.             ESP_LOGE(TAG, "GPIO16 and GPIO17 has been occupied by PSRAM, Only ETH_CLOCK_GPIO_IN is supported!");
7.             ret = ESP_FAIL;
8.             goto _verify_err;
9.         } else {
10.             ESP_LOGW(TAG, "GPIO16/17 is used for clock of EMAC, Please Make Sure you're not using PSRAM.");
11.         }
12. #endif
13.         // 50 MHz = 40MHz * (6 + 4) / (2 * (2 + 2) = 400MHz / 8
14.         rtc_clk_apll_enable(1, 0, 0, 6, 2);
15.         REG_SET_FIELD(EMAC_EX_CLKOUT_CONF_REG, EMAC_EX_CLK_OUT_H_DIV_NUM, 0);
16.         REG_SET_FIELD(EMAC_EX_CLKOUT_CONF_REG, EMAC_EX_CLK_OUT_DIV_NUM, 0);
17.  
18.         if (emac_config.clock_mode == ETH_CLOCK_GPIO0_OUT) {
19.             PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO0_U, FUNC_GPIO0_CLK_OUT1);
20.             REG_WRITE(PIN_CTRL, 6);
21.             ESP_LOGD(TAG, "EMAC 50MHz clock output on GPIO0");
22.         } else if (emac_config.clock_mode == ETH_CLOCK_GPIO16_OUT) {
23.             PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO16_U, FUNC_GPIO16_EMAC_CLK_OUT);
24.             ESP_LOGD(TAG, "EMAC 50MHz clock output on GPIO16");
25.         } else if (emac_config.clock_mode == ETH_CLOCK_GPIO17_OUT) {
26.             PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO17_U, FUNC_GPIO17_EMAC_CLK_OUT_180);
27.             ESP_LOGD(TAG, "EMAC 50MHz inverted clock output on GPIO17");
28.         }
29.     }

GeSHi © Codebox Plus Extension

Please let us know if you have resolutions of both (A) and (B) issues.

Thanks,
Nirav Agrawal

[WiFive]

https://esp32.com/viewtopic.php?f=12&t=12123

[ESP_morris]

For question A, it's hard to say since I don't know your harware: which PHY, how it connected to esp32, where the RMII clock comes from, etc.

For question B, sure, we already fixed it in our internal repo, will push it to GItHub ASAP

[nirav.agrawal]

For question A, it's hard to say since I don't know your harware: which PHY, how it connected to esp32, where the RMII clock comes from, etc.

For question B, sure, we already fixed it in our internal repo, will push it to GItHub ASAP

Hi Morris,
Below is PHY chip and configurations for ESP32:

PHY: lan8720
Ethernet Configurations:
eth_config_t config = phy_lan8720_default_ethernet_config;
config.phy_addr = 0;
config.clock_mode = 1;

>> RMMI Clock sourced from "GPIO0_out" (50MHz)
>> We are using PSRAM (4MB) ESP module which is why we could not use GPIO16 & GPIO17.
>> We verified that ethernet up and running along with WIFI but few times we observed that "Link up" & "Link Down" request received in phy_common though there was not ethernet adopter attached.

[xpetept]

For question B, sure, we already fixed it in our internal repo, will push it to GItHub ASAP

Is this already available on GItHub? I can't find it in any branch.
Is this going to be available in version 3.3.x?

[nirav.agrawal]

Yes, It is part of 3.3 release.