Add LAN8720 phy support (IDFGH-3260) #383

RobinCutshaw · 2017-02-26T18:36:13Z

No description provided.

CLAassistant · 2017-02-26T18:37:14Z

All committers have signed the CLA.

negativekelvin · 2017-02-26T19:53:47Z

Could you fix debug logging to use ESP_LOGD?

RobinCutshaw · 2017-02-26T22:50:22Z

The original code uses ESP_LOGI so I followed it by example. Should the original code remain ESP_LOGI and the new code use ESP_LOGD?

projectgus

Thanks for contributing this, we really appreciate it.

I've requested a couple of small changes/clarifications. The bigger questions around naming I'm happy for us to deal with later, unless you're particularly inspired to do some refactoring along those lines. :)

Regarding ESP_LOGD vs ESP_LOGI, as this is a fairly low-level technical example I think we can afford to keep the default ("info" level) output fairly technical like this. Some time down the road, if/when the PHY support code gets refactored into a library, we may change some of this.

projectgus · 2017-02-27T00:15:56Z

examples/ethernet/ethernet/main/ethernet_main.c

+#if (CONFIG_PHY_LAN8720)
+            if (debug)
+                dump_lan8720_registers();
+#endif


For code like the above it's preferable to define a single function name, something like static void dump_phy_registers and name both PHY-specific versions the same. The #ifdef guards will determine which one is compiled in.

My original plan was to pull all of the phy code out of ethernet_main.c and put it in separate source files. That is a little more work but I'm happy to do that now if preferred.

I've refactored by moving the phy code out of ethernet_main.c so there is no phy device specific code there. Now would be the time to change the logging level before I check in. Preferences?

projectgus · 2017-02-27T00:16:23Z

examples/ethernet/ethernet/main/ethernet_main.c

    eth_config_t config;
-    config.phy_addr = PHY31;
+//    config.phy_addr = PHY31;
+    config.phy_addr = PHY1; // tlk eval board


Is this an intentional change to the TLK1110 config?

The upstream repository uses PHY31 which would be specific to the original author and their hardware. I changed it to the default for the evaluation boards for both the TLK110 and LAN8720. I left the original commented out so the original author could easily change it. Ideally, what I should do is place the PHY ID in the menuconfig file.

projectgus · 2017-02-27T00:19:52Z

examples/ethernet/ethernet/main/ethernet_main.c

+    config.phy_get_duplex_mode = phy_lan8720_get_duplex_mode;
+    config.phy_get_partner_pause_enable = phy_lan8720_get_partner_pause_enable;
+    config.phy_power_enable = phy_lan8720_power_enable;
+#endif


I'm not sure about the naming here either.

It may make more sense, long term, to split these PHY-specific functions into individual source files and have extern eth_config_t lan8270_eth_config and extern eth_config_t tlk110_eth_config or something like this.

You don't need to change that in this PR unless you want to, it's something we can rework in a follow-up (eventually some of this will probably be moved to library code, as well.)

Yes, I had planned to rework this if the code I submitted was of interest.

projectgus · 2017-02-27T00:21:47Z

examples/ethernet/ethernet/main/Kconfig.projbuild

@@ -0,0 +1,17 @@
+menu "Example Configuration"
+
+config PHY_TLK110


For these kind of options, it's better to use a "choice". Something like this: https://github.com/espressif/esp-idf/blob/master/components/freertos/Kconfig#L14 (note the "choice" keyword starts the series of choices, until the "endchoice" line.)

Ok. I looked at all of the Kconfig file examples under the examples tree and didn't see an example of that. I'll make the change.

…ables

projectgus · 2017-02-27T03:41:40Z

examples/ethernet/ethernet/main/ethernet_main.c


-static const char *TAG = "eth_demo";
+extern void phy_device_check_phy_init(void);


Feel free to disagree with me here, but I think rather than declare all these functions as extern, it may be better to make them static in the individual source files and then declare inside each PHY-specific file

const eth_config_t tlk110_default_ethernet_phy_config = { .phy_check_init = phy_tlk110_check_phy_init, .phy_check_link = phy_tlk110_check_phy_link_status, .phy_get_speed_mode = phy_tlk110_get_speed_mode, .phy_get_duplex_mode = phy_tlk110_get_duplex_mode, .flow_ctrl_enable = true; .phy_get_partner_pause_enable = phy_tlk110_get_partner_pause_enable, etc}

And then in this code:

extern const eth_config_t tlk110_default_ethernet_phy_config;

Which then be either passed to the esp_eth_init() directly (if the signature is changed to const), or copied to another structure which is then passed in directly.

This also has the advantage that you don't need to selectively compile the source files, we can compile both but only one will be linked into the final binary depending on which extern-ed config structure is used.

(Sorry if this seems different to what I was suggesting before, I realised I gave two different recommendations as I read my way through the code.)

There are a couple of functions in the eth_config structure that come from ethernet_main instead of the phy support code so a phy function like:

eth_config_t *eth_config = phy_device_get_config(eth_gpio_config_rmii, tcpip_adapter_eth_input);

or the structure would not be const and ethernet_main would just set those functions. Given that there may be more than one ethernet project in the future, the phy code should probably move out from the project and into a component support library (in the future). That would make me lean towards the eth_config function approach.

Here is the latest suggestion. lan8720_phy.c has:

void phy_update_config(eth_config_t *config);

and ethernet_main.c has:

eth_config_t config; config.gpio_config = eth_gpio_config_rmii; config.tcpip_input = tcpip_adapter_eth_input; config.phy_power_enable = phy_device_power_enable; phy_update_config(&config); ret = esp_eth_init(&config);

This is really a minor variation on your suggestion, but what about:

eth_config_t config = tlk110_default_ethernet_phy_config; config.gpio_config = eth_gpio_config_rmii; config.tcpip_input = tcpip_adapter_eth_input; config.phy_power_enable = phy_device_power_enable; ret = esp_eth_init(&config);

This means that you don't need to selectively compile each PHY source file, they can all be compiled but only one will be picked up at link time (because of the individual name tlk110_default_ethernet_phy_config). This will probably help once the code is in a comonent support library (which I agree should be the goal), as many non-example users probably won't need to support multiple PHYs and therefore won't find the overhead of sdkconfig phy selection useful.

Eventually, we can probably also push some of these generic functions (like tcpip_adapter_eth_input) into the "default" config for each PHY as well.

I liked (in my version) that ethernet_main did not need to know anything about the underlying phy. Does it make a difference (other than compile time) whether you do selective compiling or selective linking? Your version would need ifdefs around the version of the struct to pull. If you feel strongly about it, I'll happily shut up and go with your version... :)

There are a couple of considerations:

We try to use code-as-configuration where possible instead of sdkconfig. This often leads to more understandable code (if each PHY symbol has a different name, it's obvious what the intention of the phy configuration selection is from reading the calling code in ethernet_main. Whereas using the same name to configure PHYs means a reader has to also look at the component.mk file in order to see the full picture of what's happening, and how the three parts - sdkconfig, build configuration, ethernet_main - join together.)

The second reason is that for Arduino and some other environments (like Micropython/NodeMCU) the maintainers build a single set of libraries and then link to those. For these environments to support multiple PHYs, they have to be able to access them all simultaneously without rebuilding or reconfiguring IDF.
Thanks for being patient with all my requests. :)

EDIT: Changed readable to understandable above, as you're totally correct that the version without #ifdefs reads clearer. It's just harder to understand exactly what it does, without looking at some additional pieces.

projectgus · 2017-02-27T03:42:22Z

examples/ethernet/ethernet/main/lan8720_phy.c

+
+#include "lan8720_phy.h"
+
+extern char *demo_tag;


better to do something like static const char *TAG = "lan8720"; here, similar for the other PHY.

Ok, that works.

projectgus · 2017-02-27T03:43:45Z

Thanks for the quick update, loosk good. I left a couple more comments. Feel free to let me know if you think it's better to go in a different direction, I'm not very familiar with the ethernet support yet (still waiting on a development board.)

ESP32DE · 2017-02-27T13:51:52Z

Some time down the road, if/when the PHY support code gets refactored into a library, we may change some of this.

hello angus,
mhm, i'm sorry if i anticipate something,
between the lines i read that the code/PHY support code in the near future only appears as lib?
when the new design appears to the eth board, will there be open code or lib?

best wishes
rudi ;-)

projectgus · 2017-02-27T22:56:51Z

between the lines i read that the code/PHY support code in the near future only appears as lib?
when the new design appears to the eth board, will there be open code or lib?

Sorry, I used the wrong language. I mean a component (specifically a component which provides generic library-style support for PHYs, rather than keeping it in the example code.) We intend to keep the ethernet support fully open source.

projectgus

Thanks for all your work on this, I like this structure a lot better overall.

projectgus · 2017-03-01T01:28:40Z

examples/ethernet/ethernet/main/ethernet_main.c

@@ -32,92 +32,47 @@
 #include "tcpip_adapter.h"
 #include "nvs_flash.h"
 #include "driver/gpio.h"
-#include "tlk110_phy.h"
+
+extern void phy_update_config(eth_config_t *config);


I think this declaration is a leftover here

projectgus · 2017-03-01T01:31:06Z

examples/ethernet/ethernet/main/ethernet_main.c

-    }   
-}
+// uncomment for console debug messages
+#define DEMO_DEBUG 1


This pattern is not really "the IDF way". Use ESP_LOGD or ESP_LOGI to set the debug levels based on how important you think the output is.

Users can override the logging level (either per-file or globally) in various ways as described here:
http://esp-idf.readthedocs.io/en/latest/api/system/log.html

As I said before, I don't feel strongly about whether this example output should be ESP_LOGD or ESP_LOGI. Whichever you think is more useful is fine.

projectgus · 2017-03-01T01:31:36Z

examples/ethernet/ethernet/main/lan8720_phy.c

+
+#define PHY_ID PHY0
+// uncomment for console debug messages
+//#define PHY_DEBUG 1


Same comment about debugging conventions applies here.

projectgus · 2017-03-01T01:34:57Z

examples/ethernet/ethernet/main/ethernet_main.c

+// select phy device
+//extern eth_config_t lan8720_default_ethernet_phy_config;
+//#define PHY_CONFIG lan8720_default_ethernet_phy_config
+extern eth_config_t tlk110_default_ethernet_phy_config;


For the example, it's nicer to conditionally compile this lines based on an sdkconfig choice (similar to the first version of this PR). Sorry if I accidentally gave you the impression that I wanted that removed.

Also, the "extern eth_config_t ..." declarations can be moved to the respective PHY headers.

projectgus · 2017-03-01T01:35:33Z

examples/ethernet/ethernet/main/lan8720_phy.c

+    phy_enable_flow_ctrl();
+}
+
+eth_config_t lan8720_default_ethernet_phy_config = {


This can be "const eth_config_t", in which case it lives in flash to save RAM.

projectgus · 2017-03-01T01:35:45Z

examples/ethernet/ethernet/main/tlk110_phy.c

+    phy_enable_flow_ctrl();
+}
+
+eth_config_t tlk110_default_ethernet_phy_config = {


This can be "const eth_config_t", in which case it lives in flash to save RAM.

projectgus · 2017-03-02T03:29:49Z

Thanks Robin, looks very good. I've squashed these commits and put them into our internal review/merge queue. I'll let you know how things progress.

We're still gearing up for the V2.0 release (which is already feature complete), so a final merge may be a little delayed. Thanks for being patient with us!

projectgus · 2017-03-06T23:26:11Z

Hi Robin,

Quick update on this: no problems with the code surfaced in internal review. The only thing was some discussions around support-ability once merged to IDF.

We're going to mark LAN8720 as contributed/unsupported when we merge, but we're also going to order some LAN8720 modules so we can test these changes in-house before merging and (hopefully) verify any other major ethernet changes that may impact LAN8270 (although we won't be guaranteeing support.)

Thanks for being patient with us.

Angus

RobinCutshaw · 2017-03-06T23:43:21Z

Thanks Angus. I've submitted a couple of new pull requests that move the phy support under the components tree and added ethernet support to the http_request example. These are obviously dependent on the original patch. Please take a look at the http_request pull request and let me know if that is the direction you would like to go. I hope to add ethernet support to all of the examples if that is ok.

RobinCutshaw · 2017-04-08T21:27:52Z

It has been a while since this was approved. I had time to design and test a "ESP32 Etherbase" ethernet proto board with the LAN8720A. It is working well. Hopefully we can get these changes applied so we don't get so far away from the master.

Robin

projectgus · 2017-04-10T00:50:56Z

Hi @RobinCutshaw ,

Very nice board! Is the design open source anywhere?

Sorry I didn't update you earlier. During our internal review process, we decided that one of our engineers should make a test setup with this PHY before we merge it. The engineer failed to get a LAN8270 breakout board working correctly, and then had higher priority work take him away from this. The task was handed back to me a couple of weeks ago. I have a LAN8720 board here but I haven't had time to wire it up yet. Hopefully soon.

Thanks for being patient while we work through this.

Angus

ESP32DE · 2017-04-10T04:12:22Z

The engineer failed to get a LAN8270 breakout board working correctly,

perhabs this helps:
http://www.waveshare.com/w/upload/0/08/LAN8720-ETH-Board-Schematic.pdf

I have a LAN8720 board here but I haven't had time to wire it up yet

incredible
it's a five minute test!

everything is described neatly

many manufacturer build ESP32 ETH PHY Boards

olimex makes now ETH PHY + CAN too
https://olimex.wordpress.com/2017/04/06/esp32-evb-now-get-much-better/
..
incredible

the most loved ones which makes the esp32 so interesting like LAN(ETH PHY) + CAN
are totally neglected. these two work come completely by/from third party

and the theme pSRAM ..
i speak and ask not more in and about this - now near 5 month waiting for details
speechless ( for not taking time )

@RobinCutshaw
nice board!
thank you for your effort on ETH PHY with LAN8720 and your work on ESP-IDF
as third party component, that's the best way for it now and for future other things ( openWiFi ...)

igrr · 2017-04-10T05:06:20Z

@ESP32DE

everything is described neatly

If you can point us to the description of correct wiring, it would probably speed up things significantly!

ESP32DE · 2017-04-10T05:39:16Z

@igrr

WROVER-KIT Waveshare LAN8720 Breakout

must_IO22 ->TX1
must_IO21 ->TX_EN
must_IO25 ->RX0
must_IO00 ->nINT/RETCLK
user_IO18 ->MDIO
must_GND ->GND
must_VCC ->VCC 3.3V
must_IO19 -> TX0
must_IO26 -> RX1
must_IO27 -> CRS
user_IO23 -> MDC

user_IO23
user_IO18

#define PIN_SMI_MDC   23
#define PIN_SMI_MDIO  18

example as jpeg from pdf
example as pdf

ESP32DE · 2017-04-10T05:52:01Z

hope this helps for

it would probably speed up things significantly!

best wishes
rudi ;-)

ESP32DE · 2017-04-10T06:11:43Z

btw:

the must ETH PHY RMII pins are from esp32 pin list
side 4

RMII side 5

the details from the ESP32 technical reference manual
side 45, 46

edit:
and last but not least:
there is a ethernet tlk110 demo code with the must pins for ETH PHY RMII in the esp-idf examples folder

void eth_gpio_config_rmii(void)
{
    //txd0 to gpio19 ,can not change
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO19_U, FUNC_GPIO19_EMAC_TXD0);
    //tx_en to gpio21 ,can not change
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO21_U, FUNC_GPIO21_EMAC_TX_EN);
    //txd1 to gpio22 , can not change
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO22_U, FUNC_GPIO22_EMAC_TXD1);
    //rxd0 to gpio25 , can not change
    gpio_set_direction(25, GPIO_MODE_INPUT);
    //rxd1 to gpio26 ,can not change
    gpio_set_direction(26, GPIO_MODE_INPUT);
    //rmii clk  ,can not change
    gpio_set_direction(0, GPIO_MODE_INPUT);

    //mdc to gpio23 
    gpio_matrix_out(PIN_SMI_MDC, EMAC_MDC_O_IDX, 0, 0);
    //mdio to gpio18
    gpio_matrix_out(PIN_SMI_MDIO, EMAC_MDO_O_IDX, 0, 0);
    gpio_matrix_in(PIN_SMI_MDIO, EMAC_MDI_I_IDX, 0);
}

same is then in the LAN8720

;-)

be sure you set phy addr right.
the tlk110 demo code from espressif used PHY31 as address

config.phy_addr = PHY31;

the EVB tlk110 used PHY0

the Waveshare LAN8720 breakboard Adapter used PHY1

config.phy_addr = PHY1;

RobinCutshaw · 2017-04-10T14:31:31Z

Here are the pin definitions in the IDF code:

`void eth_gpio_config_rmii(void)
{
//crs_dv to gpio27 ,can not change (default so not needed but physical signal must be connected)
//PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO27_U, FUNC_GPIO27_EMAC_RX_DV);

//txd0 to gpio19 ,can not change
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO19_U, FUNC_GPIO19_EMAC_TXD0);
//tx_en to gpio21 ,can not change
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO21_U, FUNC_GPIO21_EMAC_TX_EN);
//txd1 to gpio22 , can not change
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO22_U, FUNC_GPIO22_EMAC_TXD1);
//rxd0 to gpio25 , can not change
gpio_set_direction(25, GPIO_MODE_INPUT);
//rxd1 to gpio26 ,can not change
gpio_set_direction(26, GPIO_MODE_INPUT);
//rmii clk  ,can not change
gpio_set_direction(0, GPIO_MODE_INPUT);

//mdc to gpio23
gpio_matrix_out(PIN_SMI_MDC, EMAC_MDC_O_IDX, 0, 0);
//mdio to gpio18
gpio_matrix_out(PIN_SMI_MDIO, EMAC_MDO_O_IDX, 0, 0);
gpio_matrix_in(PIN_SMI_MDIO, EMAC_MDI_I_IDX, 0);

}
`
I used the Microchip/SMSC EVB8720 eval board in it's default configuration. The default PHY_ID is 0 so you will need to change the phy_addr from PHY31 in the IDF master branch. The PIN_PHY_POWER isn't used with the eval board so I either hit reset several times to get to the right mode or disconnect the clock pin while booting. The key for receive is to connect GPIO27 to the CRS_DV pin on the PHY. If you are not using the EVB8720 (which has pull ups on mode pins), you will need to add the mode bits in software when you configure the phy.

`
#define AUTO_NEG_ADVERTISEMENT_REG (0x4)
#define ASM_DIR BIT(11)
#define PAUSE BIT(10)
#define MODE_100_FULL_DUPLEX BIT(8)
#define MODE_100_TX_ABLE BIT(7)
#define MODE_10_FULL_DUPLEX BIT(6)
#define MODE_10_ABLE BIT(5)
#define MODE_ALL 0x01e0

void phy_enable_flow_ctrl(void)
{
uint32_t data = 0;
data = esp_eth_smi_read(AUTO_NEG_ADVERTISEMENT_REG);
esp_eth_smi_write(AUTO_NEG_ADVERTISEMENT_REG,data|ASM_DIR|MODE_ALL|PAUSE);
// esp_eth_smi_write(AUTO_NEG_ADVERTISEMENT_REG,data|ASM_DIR|PAUSE);
}
`

Robin

ESP32DE · 2017-04-18T14:53:45Z

@sauttefk
comment to the edit post

BTW: LED1 is connected wrongly. The LED1 should be connected to GND to ensure REGOFF=0 see datasheet page 32 section 3.8.1.1

thats one of more problems with the modules on market,
the WAVESHARE module shows no resistor on the last place

but point in the wiki still to mounted things in the shematic

..
so double check the used LAN8720 Modul
and check the routing....

best wishes
rudi ;-)

sauttefk · 2017-04-18T15:38:35Z

@projectgus: could you please merge this pull request. I think it has been proven by several people here, that the code is working as intended.

sauttefk · 2017-04-18T16:09:52Z

@ESP32DE

this snip shows too, we can use 25 MHz for the LAN8720 and LAN8720 generate the 50MHz on RefCLK
so the mean of R12 as "optional" was well thought

yes sure, but this means either

populate R12

or

populate R11 and also change the bootstrap on LED2 nINTSEL=0 to get the 50MHz REFCLKO on pin 14 nINT/REFCLKO of LAN8720

to get a 50MHz signal on the R_RXCLK pin of the pinheader of the waveshare module.

Merges #383 #383

projectgus · 2017-04-20T08:19:23Z

Thanks everyone for the information and for your patience with this. As I'm sure you can all appreciate, we have a lot of open tasks and sometimes things we'd love to see done are pushed behind more urgent items.

I finally had time yesterday and I wired up my LAN8720, everything worked fine. I've also rebased this branch on the current master, and added a couple of things:

Refactored the PHY support into the ethernet component - which makes it easier to reuse between projects. This is very similar to Robin's work in Move ethernet phy support into components tree and refactor example app #398, only goes a little further with removing duplicate code and aiming to provide ways that common PHY driver code can be reused/shared.
Expanded the README for the ethernet example, based on the details provided by @ESP32DE , @RobinCutshaw & @sauttefk in this thread. Should make it quicker for new folks to get up and running.

The branch is back in the internal review queue, so it may not be merged to master for a few days yet. I've pushed it temporarily/unofficially here: https://github.com/espressif/esp-idf/compare/temp/ethernet_lan8720 in case anyone would like to take a look or test it out beforehand.

Expect a proper merge to master very shortly, though. Thanks again for bearing with us.

PS @sauttefk Very nice blog post and trick using the spare pin on the Waveshare module for oscillator Enable!

RobinCutshaw · 2017-04-20T18:23:34Z

The ethernet_lan8720 branch works well on my ESP32 Etherbase board (which has the LAN8720). I like the other refactoring you did as well.

Merges #383 #383

ethernet: Add LAN8720 phy support, move PHY to components Encompasses PR #383 #383 Also includes changes to move PHY support functions into ethernet component, similar to #398 https://github.com/espressif/esp-idf/pull/398/files. See merge request !540

projectgus · 2017-04-25T23:51:21Z

Cherry-picked in 5d6e6f7. Thanks for all the input folks, and thanks for sending the original PR @RobinCutshaw .

santanapablo1975 · 2017-04-26T14:16:10Z

Hi All,

I see here that everybody is working with ESP32 and Ethernet.

I have tried also with success the ESP32 and the LAN Board from wave share (DP83848) with small changes from the ESP32 example.

Now I have a general question... waht about if I want to connect direct my PC to the ESP32 via the Ethernet interface, would that be possible? or at least has any sense?

Thanks in any case for your contributions to the ESP32 community!

Regards/Saludos/Gruesse

Juan

ahmedjouirou · 2017-05-01T16:18:17Z

@santanapablo1975 , can you please share the DP83848 port ? i mean if you have made like a "phy_dp83848.h/c" sources ?

Thanks !

santanapablo1975 · 2017-05-02T13:13:51Z

For the Ethernet test I used this board http://www.waveshare.com/dp83848-ethernet-board.htm And took the example from the ESP32 IDF with small change in the PHYADR1 and create the pinout for pin CRS Please let me know how your test was doing! Regards!!! Juan

…

On Mon, May 1, 2017 at 11:18 AM, ahmedjouirou ***@***.***> wrote: @santanapablo1975 <https://github.com/santanapablo1975> , can you please share the DP83848 port ? i mean if you have made like a "phy_dp83848.h/c" sources ? Thanks ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#383 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT6ZYJww-ImIkJuM_ADBnFIsV9fNCI3nks5r1gXOgaJpZM4MMeJj> .

Nakul93 · 2017-07-19T10:29:03Z

@ESP32DE Where should we connect PIN_PHY_POWER on lan8720 board?

Nakul93 · 2017-07-20T11:18:03Z

Hey @projectgus
I am unable to get in the write mode each time I have to press reset multiple times before I get in the right mode.
This what I get on serial monitor:
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57

//After pressing reset for the 3rd time I got in to the right mode
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0008,len:8
load:0x3fff0010,len:160
load:0x40078000,len:10632
load:0x40080000,len:252
entry 0x40080034
ETH started
ETH MAC: 24:0A:C4:01:82:EF
ETH connected
ETH IPv4: 192.168.0.107

TIA

RobinCutshaw · 2017-07-20T12:25:40Z

The PIN_PHY_POWER is normally used to turn on/off the power to the ethernet PHY or to control a mosfet or clock enable pin (that you add in your design) that blocks the 50MHz clock from GPIO0. If the clock is running and connected to GPIO0 when you boot, you have a 50/50 chance of going into bootloader mode or normal boot. If you are using an external PHY board to test, you will need to manually remove power or disconnect the clock from GPIO0 while booting.

Nakul93 · 2017-07-20T12:57:20Z

So if I make those changes as suggested by @sauttefk connecting the PIN_PHY_POWER pin to the clock enable of lan8720 would that work without having to continuously reset to get in to the right mode.

RobinCutshaw · 2017-07-20T13:35:48Z

I think you need a custom circuit that would disable clock via the clock enable pin on the oscillator (if you are using one) or would need to block the clock from GPIO0 through something like a mosfet.

…

On Thu, Jul 20, 2017 at 8:57 AM, Nakul93 ***@***.***> wrote: So if I make those changes as suggested by @sauttefk <https://github.com/sauttefk> connecting the PIN_PHY_POWER pin to the clock enable of lan8720 would that work without having to continuously reset to get in to the right mode. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#383 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABntlL484fy8B6oe9SPsEseF2qxEXHrZks5sP064gaJpZM4MMeJj> .

Arthedian · 2018-05-11T11:19:02Z

Hello,
is it possible to change the connection of CLK pin to GPIO0? I want to use ethernet, but my dev board, which i bought dont have GPIO0 on its header.

sauttefk · 2018-05-11T12:25:34Z

@Arthedian Take a look here: https://github.com/espressif/esp-idf/blob/09d2791cfdf7348405712c0a746ab780b2b0230d/examples/ethernet/ethernet/README.md#phy-clock-wiring
Only GPIO0 can be used as an input for the Ethernet PHY-clock.

projectgus · 2018-05-14T01:09:40Z

@Arthedian You may be able to reconfigure to generate the clock from the ESP32 and output on GPIO 16, as noted at the link @sauttefk sent.

You can set the clock mode in the eth_config_t structure passed when you configure the clock, see here:
http://esp-idf.readthedocs.io/en/latest/api-reference/ethernet/esp_eth.html#_CPPv2N12eth_config_t10clock_modeE

Arthedian · 2018-05-21T08:39:09Z

Thanks for your support. Fortunately now I got ESP32 with PIN0, so its no problem. But when I connected it to the LAN8720 (I double check the connection), it gives me this error. Do you know, where the problem could be?

E (1304) emac: Timed out waiting for PHY register 0x2 to have value 0x0007 (mask 0xffff). Current value 0xffff
E (2304) emac: Timed out waiting for PHY register 0x3 to have value 0xc0f0 (mask 0xfff0). Current value 0xffff

EDIT: Fixed, when config.phy_addr changed to config.phy_addr = PHY1;

Arthedian · 2018-07-16T12:32:19Z

Hello, I have another question. Can i have ethernet connected to esp and load the code at once? I already have transistor between pin0 and ethernet.

tantu1293 · 2018-07-23T16:05:01Z

Hello, I have another problem.
I choose REF_CLK Out Mode with crytal 25MHz for comunication between my custom PCB Lan8720 and ESP32-wroom- 32D. I configured LED2 pin and LED1 pin following datasheet to get CLK.
After that, I use ETHERNET example code to test. But I can't obtain IP Adrress . This is log which i have

So, i read datasheet and "rev D schematic checklist" of Lan8720 again. And i find out some things.

What should i do ?
May anybody help me ? Please.
Thanks.

theElementZero · 2018-10-14T16:24:24Z

Hi All,

I see here that everybody is working with ESP32 and Ethernet.

I have tried also with success the ESP32 and the LAN Board from wave share (DP83848) with small changes from the ESP32 example.

Now I have a general question... waht about if I want to connect direct my PC to the ESP32 via the Ethernet interface, would that be possible? or at least has any sense?

Thanks in any case for your contributions to the ESP32 community!

Regards/Saludos/Gruesse

Juan

Hi Juan, i am trying to interface DP83848 with ESP32, i am facing some issue, i would like to know what all possible changed needed in phy_xxxx.c file for this PHY.

would like to know your inputs.

Regards
Sushant

BenjaminK87 · 2020-05-08T09:01:16Z

Sorry for pulling this old thread.

Is there any way to get the lan8720ai working with a esp 32 Pico d4? As far as I can see, The gpio 16 and 17 are used for the internal flash.

I already asked here, but no answer so far.
https://www.esp32.com/viewtopic.php?f=12&t=15496

Thanks in advance.

tantu1293 · 2020-05-08T13:27:54Z

Dear, This is my project about *Esp32-Wroom32u* and LAN8720. [image: image.png] Compare to *ESP32-Pico D4* [image: image.png] You can see that function of pins for Ethernet comunication is the similar and doesn't conflict. Best Regards, Nguyen Vi Tan Tu (Mr.) Electrical Engineer - Hardware Developer Mobile: (+84) 78 212 0323 Vào Th 6, 8 thg 5, 2020 vào lúc 16:01 BenjaminK87 < notifications@github.com> đã viết:

…

Sorry for pulling this old thread. Is there any way to get the lan8720ai working with a esp 32 Pico d4? As far as I can see, The gpio 16 and 17 are used for the internal flash. I already asked here, but no answer so far. https://www.esp32.com/viewtopic.php?f=12&t=15496 Thanks in advance. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#383 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADLFTQYDQWHP7GXW6AWEKNLRQPC6XANCNFSM4DBR4JRQ> .

BenjaminK87 · 2020-05-09T05:41:56Z

Thank your for your reply.

I think something went wrong with the picture upload. I can't see it.

Add LAN8720 phy support

1d4b7fc

ESP32DE mentioned this pull request Feb 26, 2017

ESP32 ETH PHY support in arduino-esp32 espressif/arduino-esp32#237

Closed

projectgus suggested changes Feb 27, 2017

View reviewed changes

Refactor phy device code out of ethernet_main and rework Kconfig vari…

5a0dac1

…ables

projectgus reviewed Feb 27, 2017

View reviewed changes

Rework eth_config initialization and update TAG use

5737ca6

projectgus suggested changes Mar 1, 2017

View reviewed changes

Update debugging levels and sdkconfig variables

70bd029

projectgus approved these changes Mar 2, 2017

View reviewed changes

projectgus added the Status: Pending blocked by some other factor label Mar 2, 2017

ESP32DE mentioned this pull request Mar 2, 2017

ethernet example does not run ( tlk110, LAN8720, LAN8720A, LAN8710......RMII ) #372

Closed

Merge remote-tracking branch 'upstream/master'

c33725e

projectgus pushed a commit that referenced this pull request Apr 20, 2017

examples/ethernet: Add LAN8720 phy support

27fd898

Merges #383 #383

igrr pushed a commit that referenced this pull request Apr 25, 2017

examples/ethernet: Add LAN8720 phy support

5d6e6f7

Merges #383 #383

projectgus closed this Apr 25, 2017

igrr removed the Status: Pending blocked by some other factor label Nov 14, 2017

github-actions bot changed the title ~~Add LAN8720 phy support~~ Add LAN8720 phy support (IDFGH-3260) May 8, 2020

		@@ -0,0 +1,17 @@
		menu "Example Configuration"

		config PHY_TLK110


		static const char *TAG = "eth_demo";
		extern void phy_device_check_phy_init(void);

Add LAN8720 phy support (IDFGH-3260) #383

Add LAN8720 phy support (IDFGH-3260) #383

Conversation

RobinCutshaw commented Feb 26, 2017

CLAassistant commented Feb 26, 2017 • edited Loading

negativekelvin commented Feb 26, 2017

RobinCutshaw commented Feb 26, 2017

projectgus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RobinCutshaw Feb 27, 2017 • edited Loading

Choose a reason for hiding this comment

projectgus Feb 27, 2017 • edited Loading

Choose a reason for hiding this comment

RobinCutshaw Feb 28, 2017 • edited Loading

Choose a reason for hiding this comment

projectgus Feb 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

projectgus commented Feb 27, 2017

ESP32DE commented Feb 27, 2017

projectgus commented Feb 27, 2017

projectgus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

projectgus commented Mar 2, 2017

projectgus commented Mar 6, 2017

RobinCutshaw commented Mar 6, 2017

RobinCutshaw commented Apr 8, 2017

projectgus commented Apr 10, 2017

ESP32DE commented Apr 10, 2017 • edited Loading

igrr commented Apr 10, 2017

ESP32DE commented Apr 10, 2017 • edited Loading

WROVER-KIT Waveshare LAN8720 Breakout

ESP32DE commented Apr 10, 2017

ESP32DE commented Apr 10, 2017 • edited Loading

RobinCutshaw commented Apr 10, 2017 • edited Loading

ESP32DE commented Apr 18, 2017 • edited Loading

sauttefk commented Apr 18, 2017

sauttefk commented Apr 18, 2017

projectgus commented Apr 20, 2017

RobinCutshaw commented Apr 20, 2017

projectgus commented Apr 25, 2017

santanapablo1975 commented Apr 26, 2017

ahmedjouirou commented May 1, 2017

santanapablo1975 commented May 2, 2017 via email

Nakul93 commented Jul 19, 2017 • edited Loading

Nakul93 commented Jul 20, 2017

RobinCutshaw commented Jul 20, 2017

Nakul93 commented Jul 20, 2017

RobinCutshaw commented Jul 20, 2017 via email

Arthedian commented May 11, 2018

sauttefk commented May 11, 2018

projectgus commented May 14, 2018

Arthedian commented May 21, 2018 • edited Loading

Arthedian commented Jul 16, 2018

tantu1293 commented Jul 23, 2018 • edited Loading

theElementZero commented Oct 14, 2018

BenjaminK87 commented May 8, 2020

tantu1293 commented May 8, 2020 via email

BenjaminK87 commented May 9, 2020

CLAassistant commented Feb 26, 2017 •

edited

Loading

RobinCutshaw Feb 27, 2017 •

edited

Loading

projectgus Feb 27, 2017 •

edited

Loading

RobinCutshaw Feb 28, 2017 •

edited

Loading

projectgus Feb 28, 2017 •

edited

Loading

ESP32DE commented Apr 10, 2017 •

edited

Loading

ESP32DE commented Apr 10, 2017 •

edited

Loading

ESP32DE commented Apr 10, 2017 •

edited

Loading

RobinCutshaw commented Apr 10, 2017 •

edited

Loading

ESP32DE commented Apr 18, 2017 •

edited

Loading

Nakul93 commented Jul 19, 2017 •

edited

Loading

Arthedian commented May 21, 2018 •

edited

Loading

tantu1293 commented Jul 23, 2018 •

edited

Loading