More I2C Debugging
I have, in the past, jumped to conclusions about the root cause of some issue I'm debugging and it's bit me. So I've learned to try to be very sure before doing something like blaming a failure on a chip bug. The I2C failure bothered me so I spent another couple of days trying to figure it out. I started by writing a test program running on a Teensy 3.2 that accessed both the gCore's EFM8 and the SGTL5000 over I2C to see if it could duplicate the failure. It didn't. This was very interesting and made me wonder if it wasn't an ESP32 driver problem of some sort. That sent me down a rabbit hole of changing parameters in the Espressif I2C driver, but without effect. I added filters to the I2C bus in case there was noise I didn't see confusing one of the I2C state machines. That didn't work either. I looked at a lot of scope traces.
![](https://cdn.hackaday.io/images/7646781684341376734.png)
Finally I had the idea of trying to figure out who was holding SDA low after the read should have finished (kind of a Homer Simpson DOH' moment...). I put a 470 ohm resistor in series with the SDA line going to the SGTL5000 chip and a scope probe on either side of the resistor. The idea is that there will be a small voltage drop across the resistor due to the pull-up resistor current and the voltage will be slightly lower on the side with the active SDA pull-down. Bingo!!!!! In the picture below the green trace is the scope probe on the ESP32 side and the blue trace is the probe on the SGTL5000 side.
![](https://cdn.hackaday.io/images/6831261684341450763.png)
I could clearly see the ESP32 releasing SDA after SCL went high to signify an I2C STOP condition but the SGTL5000 continued to hold SDA low leading to the timeout. I don't know what's going on in the SGTL5000 and I don't know why I couldn't reproduce the failure with the teensy but I felt I had enough proof that it was the cause of the bus failure. Confident enough to decide to move forward replacing it with another codec.
New Codec Selection
By this time I was really only considering two replacement parts, the MAX9867 and the ES8388. They seem to be pretty comparable parts with the MAX9867 having better availability for me to build a few of these boards for sale on tindie. I also found some linux kernel drivers for the MAX9867 which I figured I could port. The less expensive ES8388 is available from lcsc.com but shipping is more expensive which obviates a lot of its price advantage. But the ES8388 is also found on both Espressif's audio dev boards and in the AI Thinker A1S module. In fact I had gotten some of Espressif's hands free demos running on an AI Thinker dev board at the beginning of this project. Espressif has an ES8388 driver as part of their Audio Development Framework (ADF) with a permissive license. That driver is what ultimately swayed me to use the ES part.
Rev 2 Board
After creating a new part for the ES8388 I was off modifying the hardware. I could get rid of a 1.8V regulator but added several more capacitors. Also took the time to clean up a couple of other minor things that bothered me in the rev 1 layout.
![](https://cdn.hackaday.io/images/2772881684342399102.png)
Proto board order from PCBWay and a lcsc.com order for ES8388 parts are going out today. I'm also buying some more IP101GR ethernet PHY chips from lcsc for my tCam-POE. Since Group Gets doesn't seem interested in that I may build a few for tindie to see if anyone is interested.
Additional parts from Mouser and a stencil from Osh Stencils can go out later in the week. In the meantime I'm going to look at the other firmware issues with a hack in place that ignores I2C timeouts from the SGTL5000 in my existing prototype.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.