KSZ8863 Ethernet Driver (beta) failing in I2C client mode
Posted: Tue Sep 24, 2024 7:52 pm
We're attempting to prototype the KSZ8863 Daughter Board with an ESP32-PICO-DevKitM-2. We started with the KSZ8863 Ethernet Driver (beta) and have made the following configurations/modifications:
Why is the RMII from the ESP32 not working? I can see REFCLKO_3 is generating the 50 MHz clock properly after configuring the initial KSZ8633 registers, but then the EMAC_TXD0 and EMAC_TXD1 lines from the ESP32 stay low and do nothing (except for the one time they worked).
I've also posted this on the Microchip forums in case this is specifically a KSZ8863 issue.
Here are captures of the I2C communications working while REFCLKO_3 is disabled, and then failing after it's enabled. This happens almost every time.
- Configured the simple switch example for I2C client mode.
- Added an I2C write to the example code to configure the RMII for MAC mode (to interface with the ESP's RMII).
- Wired the RMII pins and reset pin.
- Placed the necessary components for a 25 MHz crystal to feed the KSZ8863.
- Placed a pull-down on P2LED1 and pull-up on P2LED0 for I2C client mode.
- Connected a GPIO from the ESP32 to EN_REFCLKO_3 to enable the clock at run time.
- Replaced I2C pull-ups with 4.7k Ω resistors per the schematic.
- Placed a pull-down resistor on REFCLKI_3 (since it's unused).
- Removed R21 so that X1 is not pulled down by the pull-down on REFCLKI_3.
- Soldered a wire to REFCLKO_3 (off of R22) to feed the ESP32's integrated Ethernet MAC.
- Removed R23 from SMTXD32 for the 25 MHz crystal configuration.
- Out of over 100 power-cycles/soft resets, the Ethernet/RMII between the ESP32 and KSZ8863 has worked only once (captured traffic from PHY 2 of the KSZ8863 via Wireshark).
- The KSZ8863 always fails to ACK any I2C communications when REFCLKO_3 is enabled. The analog captures of the I2C commands from the ESP32 look correct (most of the time). If REFCLKO_3 is disabled, the KSZ8863 responds fine to I2C commands. The analog captures look almost identical in either case. We require the RMII clock to be generated externally to feed the ESP32's RMII, so we need this to work.
- The I2C commands will occasionally generate nonsense traffic, and I suspect it's coming from the ESP32. For example, after the ESP32 generates a stop condition after receiving a NAK from the KSZ8663, it will generate another stop condition some time later.
- EN_REFCLKO_3 does not act as a strapping pin on reset (even though the KSZ8663 data sheet calls it one). The clock output is simply active when EN_REFCLKO_3 is high, and inactive (low) when driven low.
Why is the RMII from the ESP32 not working? I can see REFCLKO_3 is generating the 50 MHz clock properly after configuring the initial KSZ8633 registers, but then the EMAC_TXD0 and EMAC_TXD1 lines from the ESP32 stay low and do nothing (except for the one time they worked).
I've also posted this on the Microchip forums in case this is specifically a KSZ8863 issue.
Here are captures of the I2C communications working while REFCLKO_3 is disabled, and then failing after it's enabled. This happens almost every time.