W5500 is broken due to enforced version check (IDFGH-10054)

[huming2207]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1-dev-4528-g420ebd208a

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

Custom board

Power Supply used.

USB

What is the expected behavior?

Some W5500 chips may return 0 for version, and just works and connects to the ethernet in ESP-IDF 5.0 (or anything before this commit bb2f346)

What is the actual behavior?

Broken with error:

E (3645) w5500.mac: w5500_verify_id(234): invalid chip version, expected 0x4, actual 0x0
E (3655) w5500.mac: emac_w5500_init(703): vefiry chip ID failed

...and apparently, no ethernet connection can be established after this error.

Steps to reproduce.

I've tried commenting out this line, the issue can be fixed:

esp-idf/components/esp_eth/src/esp_eth_mac_w5500.c

Line 234 in bb2f346

ESP_GOTO_ON_FALSE(version == W5500_CHIP_VERSION, ESP_ERR_INVALID_VERSION, err, TAG, "invalid chip version, expected 0x%x, actual 0x%x", W5500_CHIP_VERSION, version);

Debug Logs.

No response

More Information.

I've sourced our W5500 module from here: https://99tech.com.au/product/mod-w5500-t2/

It seems to be a genuine chip, at least the engraved mark on the chip package is identical to the one on Wiznet's official Raspberry Pi Pico dev W5500 HAT module. It might be just in a different version, and both versions are working fine with ESP-IDF's W5500 driver anyway.

[huming2207]

Interestingly, according to W5500's datasheet, the VERSIONR should be always 0x04:

I don't know now, maybe the module bought from 99tech is with a fake chip or engineering sample chip? But it does work fine with the W5500 driver if that line of code is removed.

[igrr]

Linking the discussion in #10554 (comment)

[huming2207]

Linking the discussion in #10554 (comment)

Oh sorry, I haven't seen this earlier. I will close this issue for now. I'll try putting in a 100ms delay tomorrow and see will that helps or not.

[kostaond]

@huming2207 please let us know if adding a delay help you. If so, I will update the driver. I probably add multiple attempts to read the version and add delay between each attempt.

[huming2207]

Hi @kostaond , I've implemented a poll here: https://github.com/huming2207/esp-idf/commit/6e5e2c7344aaea3add65395849cfd282f6ae572c

I'm awaiting my colleagues to test that out. If that works for us, I will submit a PR soon.

[huming2207]

We've tested the fix and it works for us. I will submit a PR.

[huming2207]

PR submitted, waiting for review now! @igrr @kostaond @espzav @reinismu

[nebkat]

Needs backport to release/v5.1.

[kostaond]

Needs backport to release/v5.1.

Good catch!

[fightforlife]

Is there a way to override the W5500_CHIP_VERSION or the whole w5500_verify_id function?
It seems i have a fake or broken chip which working totally fine with 4.4 but not with 5.1 because the version is not detected 0x0.

[kostaond]

Is there a way to override the W5500_CHIP_VERSION or the whole w5500_verify_id function? It seems i have a fake or broken chip which working totally fine with 4.4 but not with 5.1 because the version is not detected 0x0.

Could you please try to upgrade to v5.1.1. The version check function in this version performs multiple attempts to read the version. It was observed that some chips return 0x0 when it is read right after the reset.

[fightforlife]

5.1.1 fixed this for me, thank you!