ESP32 Forum

Posted: **Tue Sep 24, 2019 7:00 am**

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]

    periph_module_enable(PERIPH_EMAC_MODULE);
 
    if (emac_config.clock_mode != ETH_CLOCK_GPIO0_IN) {
#if CONFIG_SPIRAM_SUPPORT
        if (esp_spiram_is_initialized()) {
            ESP_LOGE(TAG, "GPIO16 and GPIO17 has been occupied by PSRAM, Only ETH_CLOCK_GPIO_IN is supported!");
            ret = ESP_FAIL;
            goto _verify_err;
        } else {
            ESP_LOGW(TAG, "GPIO16/17 is used for clock of EMAC, Please Make Sure you're not using PSRAM.");
        }
#endif
        // 50 MHz = 40MHz * (6 + 4) / (2 * (2 + 2) = 400MHz / 8
        rtc_clk_apll_enable(1, 0, 0, 6, 2);
        REG_SET_FIELD(EMAC_EX_CLKOUT_CONF_REG, EMAC_EX_CLK_OUT_H_DIV_NUM, 0);
        REG_SET_FIELD(EMAC_EX_CLKOUT_CONF_REG, EMAC_EX_CLK_OUT_DIV_NUM, 0);
 
        if (emac_config.clock_mode == ETH_CLOCK_GPIO0_OUT) {
            PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO0_U, FUNC_GPIO0_CLK_OUT1);
            REG_WRITE(PIN_CTRL, 6);
            ESP_LOGD(TAG, "EMAC 50MHz clock output on GPIO0");
        } else if (emac_config.clock_mode == ETH_CLOCK_GPIO16_OUT) {
            PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO16_U, FUNC_GPIO16_EMAC_CLK_OUT);
            ESP_LOGD(TAG, "EMAC 50MHz clock output on GPIO16");
        } else if (emac_config.clock_mode == ETH_CLOCK_GPIO17_OUT) {
            PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO17_U, FUNC_GPIO17_EMAC_CLK_OUT_180);
            ESP_LOGD(TAG, "EMAC 50MHz inverted clock output on GPIO17");
        }
    }

GeSHi © Codebox Plus Extension

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

Thanks,
Nirav Agrawal

Posted: **Tue Sep 24, 2019 9:01 am**

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

Posted: **Wed Sep 25, 2019 2:11 am**

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

Posted: **Wed Sep 25, 2019 12:15 pm**

ESP_morris wrote: 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.

Posted: **Fri Oct 04, 2019 4:44 pm**

ESP_morris wrote: 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?

Posted: **Mon Oct 07, 2019 9:48 am**

Yes, It is part of 3.3 release.

ESP32 Forum

Incorrect EMAC Clock Validation for PSRAM

Incorrect EMAC Clock Validation for PSRAM

Re: Incorrect EMAC Clock Validation for PSRAM

Re: Incorrect EMAC Clock Validation for PSRAM

Re: Incorrect EMAC Clock Validation for PSRAM

Re: Incorrect EMAC Clock Validation for PSRAM

Re: Incorrect EMAC Clock Validation for PSRAM