KSZ8863 Ethernet Driver (beta) failing in I2C client mode (IDFGH-13769) #40
Comments
github-actions
bot
changed the title
|
This is what the 50 MHz RMII clock from the KSZ8863 looks like when we probe it at the IO0 (REF_CLK) header pin of the ESP32-PICO-DevKitM-2. Is this adequate? If not, could this be the reason that we are not seeing activity on IO19 (EMAC_TXD0) and IO22 (EMAC_TXD1)? The serial monitor also says "simple_switch_example: L2 TAP write error, errno: 0".
|
|
The RMII REF CLK is 50 MHz square wave. You see something similar to sine wave but that might be expected. It depends on your oscilloscope bandwidth and you also need to disable 20 MHz filter (if it's there) on voltage input. If the oscilloscope bandwidth is low or filter is enabled, higher harmonics of the signal are filtered out and you cannot see the square wave. It's expected behavior, please try to search the web. Anyway, have you tried to shorten wires as I suggested on forum? Did you double check the reference schematics with your setup. Did you double check the Kconfig configuration is in line with your HW setup? If so, please send me log of unmodified "simple switch" example. |
The scope is rated up to 200 MHz and the probes 350 MHz. The scope settings are configured for no bandwidth limit.
We tried shortening the wires and providing more ground connections between the two dev kits, but we can only shorten it so much. The Kconfig configuration is correct as far as I can tell. The I2C does work (without REFCLKO_3 enabled) and the RMII worked once as I was able to capture the Wireshark traffic. We don't have a schematic since it's just dev kits. I just have this table showing our board-to-board connections and modifications. Pins on the same row are connected together. We've reviewed it multiple times against reference schematics and the datasheets and cannot find anything that looks incorrect. One of our engineers is going to prototype a custom PCB using the reference design and we'll try that (since the wires between dev kits are not ideal). I'll try to run the base example unmodified and copy the serial log output here. One thing I added that looked missing from the example was to set Port 3 MII Mode Selection to MAC mode. This is register 53 (0x35), bit 7. Is this not correct? I added the following function to esp_eth_ksz8863.c:
|
@kostaond, I've run the unmodified simple switch example from this repo on our custom PCB prototype, which mostly follows the pin assignments from our "dev kits prototype". If the schematic would be of help, we'd prefer to share that in private. Just let me know what's an appropriate method. Below is the serial monitor log running the example. At timestamp 18457, I connect a single DHCP client into Ethernet port 1. At timestamp 40467, I connect Ethernet port 2 to a switch on our office LAN which has hundreds of devices. You can see the MAC table entries continue to grow over time. I'm also able to access the DHCP client on port 1 from my laptop, which is connected to the office LAN, so the switch appears to be working across those two ports. I also have Wireshark capturing network traffic from our office LAN, but I do not see any broadcasts for "This is ESP32 L2 TAP test msg" (I saw it work one time with our previous "dev kits prototype", screenshot is below the serial monitor log). I probed EMAC_TXD0 (GPIO19) and EMAC_TXD1 (GPIO22) with a scope and it appears to be transmitting real data. The two things from the log that stand out are the I2C warning
|
I'm not sure if I follow. Simple switch example workflow is to connect to DCHP Server. You should got the IP address and be able to ping your device at that address. I don't see it in your logs... Here is example what should have seen. Please send me schematics and your |
Yeah, these are expected. I need to migrate to new I2C driver and suppress that io command error since it is expected. |
|
Closing since issue was user's board hardware related. |
espressif-bot
added
Status: Done
Checklist
How often does this bug occurs?
always
Expected behavior
I expect the I2C communications to work with the RMII clock generated by the KSZ8863 and for the Ethernet/RMII to work properly.
Actual behavior (suspected bug)
The I2C communications fail to get ACK'd by the KSZ8863 when the RMII clock (REFCLKO_3) is enabled on it. The I2C traffic generated by the ESP32 also appears to sporadically generate invalid I2C traffic.
Error logs or terminal output
No response
Steps to reproduce the behavior
Project release version
v0.2.6
System architecture
Intel/AMD 64-bit (modern PC, older Mac)
Operating system
Windows
Operating system version
Windows 10
Shell
CMD
Additional context
This issue was originally posted on the forum with full details and screenshots of various analog/digital captures: https://esp32.com/viewtopic.php?f=13&t=41997&p=138041#p138041.
The text was updated successfully, but these errors were encountered: