AndySymons
commented
5 months ago I am sorry that no one has responded to this issue yet :-(
Shooting in the dark, but in an attempt to narrow down the main issue, I did several more tests and recorded the log files, which are attached.
Initial state
As in my original posting…
- There is no manual IP.
- All 6 pins are physically connected (four SPI plus Reset and interrupt). cs_pin: 18 clk_pin: 19 mosi_pin: 21 miso_pin: 23 reset_pin: 22 interrupt_pin: 36
- Clock speed is default.
Test 1
I removed the definition of the interrupt pin, wondering if it is necessary because the ESPHome documentation says it is optional and the AZ-Delivery example with Arduino does not use it. Result: no new errors. Same errors as the initial state. Conclusion: not sure. Maybe there is a default? Still need to actually cut the wire (test 3).
Test 2
I removed the definition of the reset pin, wondering if it is necessary because the ESPHome documentation says it is optional, although the AZ-Delivery example with Arduino does use it. Result: ‘reset’ errors and could not load the program at all. Conclusion: reset is mandatory.
Test 3
I restored the reset pin, and physically cut the wire to the interrupt pin because the ESPHome documentation says it is optional and the AZ-Delivery example with Arduino does not use it.
(It is till not defined in the config since test 1).
Result: still fails but gives different errors [Ethernet: 237]
Conclusion: inconclusive, but these errors look more serious (?), so I will continue to assume for now that the interrupt pin is mandatory.
Test 4
I restored the config to the initial state, i.e. all six pins physically connected and configured, no manual IP and default clock frequency. I ran it to get a fresh log of the errors. There are many, and it is hard to see which is the most fundamental error and which are knock-on errors. I checked by doing a manual reset after the initial load but that made no difference -- same errors again.
Test 5
I previously had the impression that the device connected better when a manual IP was specified. I tried specifying a manual IP, but it made no difference this time. The errors are the same. I therefore withdrew the manual IP again.
Test 6
I previously noted that the clock speed cannot be set to 80MHz. I verified that by putting it in the config, installing it and keeping the log file. I withdrew the clock_speed entry from the config.
CONCLUSIONS SO FAR
- The need for an interrupt pin is unclear. Leaving it out seems to create more serious errors, but it needs to be re-tested when a situation is reached when no other errors are being reported. In the meantime, I note that the ESPHome documentation could be clearer about the use for this pin and the consequences of not connecting and/or defining it.
- The reset pin is clearly important. Without reset, no program can be loaded. Perhaps there is an awkward way of manually resetting the board when necessary, but I did not pursue that. The ESPHome documentation should be much clearer on this point; ‘optional’ does not cover it!
- Manual IP is not necessary. I withdraw my previous comment that this appeared to be the case.
- The clock speed cannot be set to 80MHz. The ESPHome documentation is probably wrong about the default being 29.97MHz; the error log says “the driver always tries to find the closest frequency to your configuration”. If that is correct, setting the clock speed at all only makes sense if you want to slow it down for some reason!
NEXT STEPS?
I have cleared up some side issues, and eliminated some causes, but still not found the central problem. If no one has an answer, I would at least like some guidance on how to proceed with further diagnostics. It would help a lot if someone could tell me some more about what the error messages in the log mean. (I cannot find any list online). The following look like they may be important. They occur several times, with variations in the numbers in brackets (what do they mean?). In all cases except the removal of reset, the configuration was successfully compiled and uploaded. The error messages occur after the line ‘[C][ethernet:034]: Setting up Ethernet…’.
[D][esp-idf:000]: E (679) w5500.mac: w5500_send_command(123): send command timeout [D][esp-idf:000]: E (680) w5500.mac: emac_w5500_start(279): issue OPEN command failed [D][esp-idf:000]: E (690) w5500.mac: emac_w5500_set_link(422): w5500 start failed [D][esp-idf:000]: E (700) esp_eth: eth_on_state_changed(121): ethernet mac set link failed [D][esp-idf:000]: E (711) w5500.phy: w5500_update_link_duplex_speed(84): change link failed [D][esp-idf:000]: E (721) w5500.phy: w5500_get_link(108): update link duplex speed failed [D][esp-idf:000]: E (721) esp_eth: esp_eth_start(272): phy get link status failed [D][esp-idf:000]: E (2517) w5500.mac: emac_w5500_transmit(534): issue SEND command failed
So the problem is presumably somewhere in the Ethernet setup. But where?? I would very much appreciate any help an expert may be able to give to determine whether there is a bug in the ESPHome code or something I can do differently in the config.
Attachments
240513 0850 test 2 log - error when RST not defined.txt 240513 0901 test 3 log - error after INT wire snipped.txt 240513 0913 test 4 log - INT restored (back to original).txt 240513 0924 test 5 log - manual IP added (no difference).txt 240513 0939 test 6 log - clock speed set to 80MHz.txt
nagyrobi
dominik4545
The problem
I am trying to configure an AZDelivery W5500 Ethernet module.
The configuration yaml compiles and loads correctly, but after that all requests are timed out. Attempts to reinstall the code over ethernet, or to access the module from a browser also give timeout errors.
Which version of ESPHome has the issue?
2024.4.1
What type of installation are you using?
Docker
Which version of Home Assistant has the issue?
core-2024.5.3, but I did not get as far as connecting to Home Assistant via Ethernet. It works fine when connected by WiFi.
What platform are you using?
Debian Linux (running natively)
Board
Espressif Devkit v4 AZDelivery W5500 Ethernet module
Component causing the issue
Ethernet W5500 SPI
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
During set-up I observed the following. I do not know if these are connected issues or just documentation errors.