no longer builds against the latest esp-idf master

[mangodan2003]

Additionally the basic Ethernet example in esp-idf doesn't seem to work with this board. It gives a mac timeout error. Seems like this board may require power to be enabled via a GPIO which the esp-idf libraries don't seem to provide a configuration option for. Having added a few lines to the example to provide the power it gets a little but further but then times out awaiting a reset. Not had time to look any further.

[DanKoloff]

Did you test exactly with this example: https://github.com/OLIMEX/ESP32-POE/tree/master/SOFTWARE/ESP-IDF/ESP32_PoE_Ethernet ?

[mangodan2003]

Away from my dev system atm but that sure looks like the one. I first tried it some months ago and it built and worked fine but due to lack of websockets client and time the project halted. There is now a websocket client and example in the latest idf sdk but I've not been able to get the PoE board to work with it.

…

On 4 August 2019 16:09:41 BST, DanKoloff ***@***.***> wrote: Did you test exactly with this example: https://github.com/OLIMEX/ESP32-POE/tree/master/SOFTWARE/ESP-IDF/ESP32_PoE_Ethernet ? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #7 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[DanKoloff]

We tested it today. It seems to work fine. Make sure to use the demo that I linked since the default Ethernet demo has no configuration for LAN8710A only for LAN8720.

[mangodan2003]

I've got my project going by modifying one one of the esp-idf examples to enable the PHY power and set the PHY address so its no big deal for me any more, but I tried anyway. With a current fresh clone of the esp-idf and the above example it fails as shown below.
I ran make twice and omitted the output of the first run to keep it a bit shorter.

dan@grape:~/workspace/esp/esp32/projects$ git clone https://github.com/OLIMEX/ESP32-POE.git
Cloning into 'ESP32-POE'...
remote: Enumerating objects: 49, done.
remote: Counting objects: 100% (49/49), done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 406 (delta 5), reused 36 (delta 3), pack-reused 357
Receiving objects: 100% (406/406), 6.75 MiB | 3.45 MiB/s, done.
Resolving deltas: 100% (119/119), done.
dan@grape:~/workspace/esp/esp32/projects$ cd ESP32-POE/SOFTWARE/ESP-IDF/ESP32_PoE_Ethernet/ESP32_PoE_Ethernet/
dan@grape:~/workspace/esp/esp32/projects/ESP32-POE/SOFTWARE/ESP-IDF/ESP32_PoE_Ethernet/ESP32_PoE_Ethernet$ make
Toolchain path: /home/dan/.espressif/tools/xtensa-esp32-elf/esp32-2019r1-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: esp32-2019r1
Compiler version: 8.2.0
Python requirements from /home/dan/workspace/esp/esp32/esp-idf/requirements.txt are satisfied.

App "ESP32-PoE" version: 98aa6c8-dirty
CC build/main/main.o
In file included from /home/dan/workspace/esp/esp32/projects/ESP32-POE/SOFTWARE/ESP-IDF/ESP32_PoE_Ethernet/ESP32_PoE_Ethernet/main/main.c:23:
/home/dan/workspace/esp/esp32/esp-idf/components/esp32/include/rom/uart.h:1:2: warning: #warning rom/uart.h is deprecated, please use esp32/rom/uart.h instead [-Wcpp]
 #warning rom/uart.h is deprecated, please use esp32/rom/uart.h instead
  ^~~~~~~
/home/dan/workspace/esp/esp32/projects/ESP32-POE/SOFTWARE/ESP-IDF/ESP32_PoE_Ethernet/ESP32_PoE_Ethernet/main/main.c:27:10: fatal error: eth_phy/phy_lan8720.h: No such file or directory
 #include "eth_phy/phy_lan8720.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
/home/dan/workspace/esp/esp32/esp-idf/make/component_wrapper.mk:291: recipe for target 'main.o' failed
make[1]: *** [main.o] Error 1
/home/dan/workspace/esp/esp32/esp-idf/make/project.mk:584: recipe for target 'component-main-build' failed
make: *** [component-main-build] Error 2

[DanKoloff]

It certainly looks like the whole component structure related to the Ethernet was changed since the most recent v4.1-dev tag. This change probably breaks all Ethernet examples for all ESP32 boards with Ethernet. The change is not only in the directory naming and structure, it also changes the way the ESP-IDF header files related to the Ethernet are used.

Check how the directory structure looked in v4.0-dev: https://github.com/espressif/esp-idf/tree/v4.0-dev/components/ethernet/eth_phy

Check how it looks now: https://github.com/espressif/esp-idf/tree/v4.1-dev/components/esp_eth/include

We are looking into this, and need to decide what is the best way to go.

[g-mocken]

@DanKoloff I can compile and successfully run the linked olimex demo code only with release-3.3 of esp-idf.
@mangodan2003 would you mind to share more details regarding your modifications of the esp-idf examples code?

[DanKoloff]

@g-mocken Yes, 3.3 is fine. The issue here is present only for newest versions of esp-idf - 4.1v-dev and newer.

[g-mocken]

@DanKoloff Sorry if I was not clear enough: My point is that 4.0 does not work either. And I would like to use 4.0 (or later) because of other improvements. I would not mind ignoring 4.1 for the time being. If the demo code is supposed to work with 4.0, then I would appreciate some hints as to what I might be doing wrong.

[DanKoloff]

@g-mocken We still haven't published an updated example. Everything I said about the issue here still applies for 4.0: #7 (comment)

[TsvetanUsunov]

Espressif official ESP32 IDF is 3.3 https://www.espressif.com/en/support/download/sdks-demos
if you decide to use experimental, unstabile, preliminary releases we would rather not spend time on them, until they are officially released as they may bear bugs and we do not recommend anyone to use them in production

[mangodan2003]

@TsvetanUsunov I hadn't actually checked the releases page, I merely followed the getting started documents here https://docs.espressif.com/projects/esp-idf/en/latest/get-started/. It does appear that that hes left me with a dev version tho :

dan@grape:~/workspace/esp/esp32/esp-idf$ git describe
v4.0-dev-1443-g39f090a4f

@g-mocken Sure. Copy examples/common_components/protocol_examples_common to the projects local components dir and amend the start function in connect.c around about line 191

    eth_phy_config_t phy_config = ETH_PHY_DEFAULT_CONFIG();
    phy_config.phy_addr = 0; //Add this to set the PHY address to 0 - its hard coded to 1 by ETH_PHY_DEFAULT_CONFIG above.

Before the last 3 lines of the same function add the following to power up the PHY

#define PIN_PHY_POWER 12
    gpio_pad_select_gpio(PIN_PHY_POWER);
    gpio_set_direction(PIN_PHY_POWER, GPIO_MODE_OUTPUT);
    gpio_set_level(PIN_PHY_POWER, 1);
    vTaskDelay(pdMS_TO_TICKS(10));

You will need to also amend the make file to point to the new components instead of the original one.

Then in the sdkconfig of your project, or via the menuconfig utility find and set each of the following :

# CONFIG_EXAMPLE_USE_SPI_ETHERNET is not set
# CONFIG_EXAMPLE_ETH_PHY_IP101 is not set
# CONFIG_EXAMPLE_ETH_PHY_RTL8201 is not set
CONFIG_EXAMPLE_ETH_PHY_LAN8720=y
# CONFIG_ETH_RMII_CLK_INPUT is not set
CONFIG_ETH_RMII_CLK_OUTPUT=y
# CONFIG_ETH_RMII_CLK_OUTPUT_GPIO0 is not set
CONFIG_ETH_RMII_CLK_OUT_GPIO=17
CONFIG_ETH_SMI_MDC_GPIO=23
CONFIG_ETH_SMI_MDIO_GPIO=18

If you are using a different board these settings may differ. I only have experience with the PoE board. Check the relevant schematics.

Hope that makes sense and is of some help.

[will-emmerson]

The instructions above didn't work for me for v4.1, but the following did:

static esp_err_t phy_device_power_enable_via_gpio() {
    gpio_pad_select_gpio(PIN_PHY_POWER);
    gpio_set_direction(PIN_PHY_POWER, GPIO_MODE_OUTPUT);
    gpio_set_level(PIN_PHY_POWER, 1);
    vTaskDelay(100 / portTICK_PERIOD_MS);   // note <100ms didn't work
    return ESP_OK;
}

// after defining config, set this
esp_eth_config_t config = ETH_DEFAULT_CONFIG(mac, phy);
config.on_lowlevel_init_done = phy_device_power_enable_via_gpio;

[ArendJan]

Thanks for the instructions! I can now use Websockets over ethernet! (added in v4)

To make it easier for other people I made a repo with the changes applied(tested with POE rev C): https://github.com/ArendJan/esp32POE-example-v4.1
and these changes also work for the ESP32 GATEWAY(rev F).

[will-emmerson]

Unfortunately I'm not convinced this code works properly - there seem to be corrupt heap errors when doing an OTA update:

      CORRUPT HEAP: multi_heap.c:432 detected at 0x3fff1958
      abort() was called at PC 0x40093817 on core 0
      0x40093817: multi_heap_assert at /home/willemmerson/esp/esp-idf/components/heap/multi_heap_platform.h:59
       (inlined by) multi_heap_malloc_impl at /home/willemmerson/esp/esp-idf/components/heap/multi_heap.c:432


      ELF file SHA256: b4505d213febafc83734033f8d64bae971764286d4fe8c5f04aed2c6b707663c

      Backtrace: 0x400912a5:0x3ffd97b0 0x4009169d:0x3ffd97d0 0x40093817:0x3ffd97f0 0x40093d89:0x3ffd9810 0x400824c9:0x3ffd9830 0x400824f9:0x3ffd9850 0x4009727d:0x3ffd9870 0x400eed85:0x3ffd9890 0x400eee03:0x3ffd98b0 0x400eee80:0x3ffd98d0 0x400ef895:0x3ffd98f0 0x400efa71:0x3ffd9910 0x4015f51a:0x3ffd9940 0x401760a5:0x3ffd9960 0x400ebeb1:0x3ffd9980 0x4017816e:0x3ffd99a0 0x40093f81:0x3ffd99d0
      0x400912a5: invoke_abort at /home/willemmerson/esp/esp-idf/components/esp32/panic.c:157

      0x4009169d: abort at /home/willemmerson/esp/esp-idf/components/esp32/panic.c:174

      0x40093817: multi_heap_assert at /home/willemmerson/esp/esp-idf/components/heap/multi_heap_platform.h:59
       (inlined by) multi_heap_malloc_impl at /home/willemmerson/esp/esp-idf/components/heap/multi_heap.c:432

      0x40093d89: multi_heap_malloc at /home/willemmerson/esp/esp-idf/components/heap/multi_heap_poisoning.c:191

      0x400824c9: heap_caps_malloc at /home/willemmerson/esp/esp-idf/components/heap/heap_caps.c:115

      0x400824f9: heap_caps_malloc_default at /home/willemmerson/esp/esp-idf/components/heap/heap_caps.c:144

      0x4009727d: malloc at /home/willemmerson/esp/esp-idf/components/newlib/heap.c:32

      0x400eed85: mem_malloc at /home/willemmerson/esp/esp-idf/components/lwip/lwip/src/core/mem.c:237

      0x400eee03: do_memp_malloc_pool at /home/willemmerson/esp/esp-idf/components/lwip/lwip/src/core/memp.c:254

      0x400eee80: memp_malloc at /home/willemmerson/esp/esp-idf/components/lwip/lwip/src/core/memp.c:350 (discriminator 2)

      0x400ef895: pbuf_alloc_reference at /home/willemmerson/esp/esp-idf/components/lwip/lwip/src/core/pbuf.c:336

      0x400efa71: pbuf_alloc at /home/willemmerson/esp/esp-idf/components/lwip/lwip/src/core/pbuf.c:237

      0x4015f51a: ethernetif_input at /home/willemmerson/esp/esp-idf/components/lwip/port/esp32/netif/ethernetif.c:166

      0x401760a5: esp_netif_receive at /home/willemmerson/esp/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:660

      0x400ebeb1: eth_stack_input at /home/willemmerson/esp/esp-idf/components/esp_eth/src/esp_eth.c:89

      0x4017816e: emac_esp32_rx_task at /home/willemmerson/esp/esp-idf/components/esp_eth/src/esp_eth_mac_esp32.c:255

      0x40093f81: vPortTaskWrapper at /home/willemmerson/esp/esp-idf/components/freertos/port.c:143

I don't think it's OTA update that's the problem itself, I think it's just the throughput. When I use Wifi instead it works fine. Annoyingly it's quite intermittent so sometimes it works. Also sometimes the ethernet doesn't work after esp_restart(), probably because it needs de-initialising properly.

[will-emmerson]

It seems CONFIG_ETH_DMA_BUFFER_SIZE=1524 fixes the above problem in v4, see espressif/esp-idf#4454