ENC28J60 Driver does not recover after EMI-Burst (IDFGH-7529)

[nx518]

Environment

• Module or chip used: ESP32-WROOM-32 and ESP32S3WROOM1
• IDF version: master(v5.0-dev-3290-g0d014c42d) and v4.4
• Build System: idf.py
• Compiler version crosstool-NG esp-2021r2 8.4.0
• Operating System: Linux
• Using an IDE?: No
• Power Supply: external 3.3V

Problem Description

While doing the conformity tests of our esp32 based product we noticed that the ENC28J60-Driver does not recover from doing the EMI-Burst EN 61000-6-1 tests.
While the ESP32 overall keeps running fine during the tests, the enc28j60 driver seems to get stuck without notification. Only a warning "tx_ready_sem expired" is being sent once. The device is not pingable over ethernet anymore, only reboot of ESP32 resolves the issue.

Expected Behavior

Driver is working fine after the EMI-burst is over. Device is still pingable.

Actual Behavior

Driver never recovers. Device is not pingable. Rebooting the ESP32 resolves the issue.

Steps to reproduce

1. run ENC28J60 Example example
2. sudo ping -s 1450 -i 0.01
3. start EMI burst generator
4. stop EMI burst generator
5. ESP32 is still running but enc28j60 driver is stuck

Code to reproduce this issue

ENC28J60 Example

Debug Logs

I (3172) enc28j60: working in 10Mbps
I (3172) enc28j60: working in half duplex
I (3177) enc28j60: Ethernet Link Up
I (3177) enc28j60: Ethernet HW Addr 02:00:00:12:34:56
I (4147) esp_netif_handlers: eth ip: 192.168.1.186, mask: 255.255.255.0, gw: 192.168.1.1
I (4147) enc28j60: Ethernet Got IP Address
I (4150) enc28j60: ~~~~~~~~~~~
I (4153) enc28j60: ETHIP:192.168.1.186
I (4158) enc28j60: ETHMASK:255.255.255.0
I (4162) enc28j60: ETHGW:192.168.1.1
I (4167) enc28j60: ~~~~~~~~~~~
W (16482) enc28j60: tx_ready_sem expired

Does not recover from here, no more log output, no replies to ping.

[moefear85]

this doesn't seem like a bug in esp-idf, rather an electrical issue in the ethernet module itself.

[kostaond]

Unfortunately, I cannot reproduce the issue since I don't have any EMI generator in our office so hard to say in which state the ENC28J60 is. Probably in some undefined state, may be restarted, may be stuck, I don't. I wouldn't be surprised if it was in some strange state since this chip also behaved strangely when not properly powered when I was fixing the driver some time ago.

Could you please at least try to disconnect Ethernet cable after the EMI burst, if it reads link status as down? Or you can try to periodically read some status of it and if the read provides unexpected result restart the board, here is idea of how you could do that.

I tend to not updating the ENC28J60 "driver" since it seems there is some issue with the module and this ENC28J60 example is really meant as an example. In general, I do not recommend using this chip for any production units since it has bunch of errata, it is slow and it has crazy power consumption (up to 180mA! in comparison to e.g. 75mA of KSZ8851SNL or 79mA of W5500 @ 10M Tx). Anyway, if you really want to use ENC28J60, you can tune the example to meet your expectations.

[kostaond]

I am closing the issue as justified above. Please consider using workaround with periodical check as described above. Feel free to reopen if it turned out the issue is caused really by the ESP-IDF.

[nx518]

Hi, (un)fortunately I have to work on this again, so please reopen the issue.
I also made a PR for small improvement.

[kostaond]

@nx518 thank you for that fix in the PR! It was really a mistake.

Unfortunately, I don't know of how to help you with the EMI issue... You did not provide any details and I'm not able to reproduce it. In addition, the ENC28J60 is really intended as an example and it is only there that the chip was historically popular among DIY community. Otherwise it has really poor performance as mentioned in my comment above and I'm afraid it does not worth to invest such effort to it...

Did you try the previous recommendations?

Could you please at least try to disconnect Ethernet cable after the EMI burst, if it reads link status as down?

Or you can try to periodically read some status of it and if the read provides unexpected result restart the board, here is idea of how you could do that.

[nx518]

Thank you for the recommendations, I did not test them, since the project was stalling back then.

But I will try your recommendations while making further tests comparing the ENC28J60 running with an ESP32S3 to an ENC28J60 running with Raspberry Pi.