ESP32 - Ethernet (LAN8720) stops working when driving LEDs stripes with RMT

[Maxime P.]

Hi ! I am currently working on an OLIMEX ESP32-EVB REV-F, but this issue also occurs with Gateway and POE boards. In my project, I want to be able to command 4 RGB LEDs stripes with an LAN connection. For that, I am using the FastLED library. Since I am using the ESP-IDF for development, I am using the ported lib to IDF by "bbulkow" named FastLED-idf (link here : https://github.com/bbulkow/FastLED-idf). I have already created an issue on his GitHub page regarding my problem : https://github.com/bbulkow/FastLED-idf/issues/19 . Nevertheless, I will still explain the issue here. One can find a code example with 1 stripe in the previous link which uses the library and shows the issue.

I am initializing esp_eth with LAN8720 as phy, also initializing Wi-Fi but even without it, things don't work. Netif stack is also initialized, so until now, ICMP pings are working.
Then, I am using the library to initialize the data structure and I initialize the task needed to control the stripes. Then on the very first call of the function that shows the LEDs, that is to say the very first data given to the RMT, I can see that no data is ever received at the MAC/PHY level from this point. I used prints inside IDF code to see that, as explained in the GitHub issue. Thus, pings are then not being answered to anymore. Then, if I redo the eth initialization in the firmware, it would work again until next LED show.

The FastLED library is using for the ESP32 two driver possibilities : RMT and I2S. I am having issues with both : I2S gives me LED error patterns and RMT is giving me the main issue described further in this post.

With some guidance, I did lots of testing to try to figure out what was causing this issue RMT/ETH. At first, we thought that there was pin conflict. But, when trying to control the LEDs with pin 12, 02, 04, 05 and what seem to be the safest pins, 32 and 33, the issue was still there.

Then, I tried with different power supply sources, USB, then 5v 3A power supply, nothing changed. I then tried a bunch of things regarding the library, the component / compilation configs of the IDF, FreeRTOS task and interrupt priorities, with only one LED on one stripe, with or without WiFi, fixing Eth RX task on one core and my stuff on the other, etc ... The problem still remains. Every test listed here has been explained in the GitHub issue, that is why I don't go through the details.

At this point, I tend to think that this problem is not related to a task / interrupt that is to greedy, neither to a pin conflict, neither to the LAN port being powered with not enough power, neither to to much LEDs or LED stripes, neither to Stack / Heap corruption (turned on IDF configs heavily control Stack smashing protection, heap corruption detection, ...).

My questions are now, does anyone have ever had trouble with LAN port with other I/O interference ? Could it be a hardware problem ? In my post in GitHub, the owner of the library said this : "Since you have these boards, are there other differences that might give us a clue? For example, are they using Rev 0 chips, with more known errata? Are they using a different XTAL than the internal one, so might have major timing differences?". I did not understand what he exactly meant with all of this but, does someone know anything about this?

I will continue to look for an answer by making more tests, for example with the same configuration but with Arduino, or with an other RMT application. In the meantime, any help would be really appreciated  .

[LubOlimex]

My advice is to leave ESP32-EVB aside if you wish to use an Ethernet project made for another board and test with ESP32-GATEWAY or ESP32-POE. ESP32-EVB has somehow unique design when it comes to the Ethernet and it might require some tweaking to get it working with a specific library.

Furthermore, ESP32-EVB has the most peripherals and the least free pins available of all Olimex-made boards. Also it has different reset strategy used there. If you decide to go with it use only the pins at the UEXT connector. Also when testing avoid GPI36 (UEXT pin 4) since it is only input; and also make sure that you don't have SD card connected. Best idea is to first try with GPIO4 (UEXT pin #3), then with GPIO16 (UEXT pin #5).

"Since you have these boards, are there other differences that might give us a clue? For example, are they using Rev 0 chips, with more known errata?"

Well, you can check what is the chip that you have in your board. When programming esptool would print the version of the chip.

"Are they using a different XTAL than the internal one, so might have major timing differences?".

The ESP32-EVB uses somehow unique 50MHz generator for the Ethernet and some special reset delay circuit. Look at CR1 in the schematic. The rest of the Olimex-made ESP32 boards use the internal clock.

[Maxime P.]

Hi ! Thank you @LubOlimex for your answer ! As I said in the first post, I continued to do tests and I actually found what was the source of this RMT/ETH issue. I also posted what I found in the FastLED-idf GitHub issues page (https://github.com/bbulkow/FastLED-idf/issues/19). So, I found that initializing RMT with default pin GPIO 0 to then use the function rmt_set_pin to change this pin to the actual used pin and then use rmt write function was causing Eth to break. Since GPIO 0 is link to the functionality of EMAC_TX_CLK in ESP32, this makes sense.

But, what is really curious though is that Eth does not break until I do an actual rmt write. Although, the rmt_set_pin function is called and changes the pin before any write. So we should never write to GPIO 0, but it still breaks on the first write.

Anyway, I will take into consideration what you said about the ESP32-EVB being a little to special. Sorry for posting an issue that is not really related to OLIMEX interests !

[LubOlimex]

It is ok, glad you solved it. No worries about the posts - any posts are welcome here, but we can't always help for everything.