I2C communication with ESP32-C3 based board

[martinjaeger]

I'm currently unable to talk to the bq76952 chip on the BMS 16S100 SC populated with the ESP32-C3. With the STM32 it works fine. It may be a hardware problem. However, @JochenKr experienced exactly the same issue, so it may also be a software problem.

*** Booting Zephyr OS build zephyr-v3.0.0-8-gc1a8af9fa93c ***
Hardware: Libre Solar BMS 16S100 SC ESP32C3 (v0.2)
Firmware: v21.0-78-g30b5496
E: I2C transfer error: -14
E: I2C error for subcmd_read: -14
I: detected bq device number: 0x4248
E: I2C transfer error: -14
E: I2C error for subcmd_read: -14

Here two screenshots of the (working) I2C communication with STM32G0B1:

And the same communication (with missing ACKs and responses) with the ESP32-C3:

[JochenKr]

In the meantime I found that the supply of bq76952 was missing. In my bench setup I didn't connect the CELL16+ to Bat+.

By doing this, I2C changed using ESP32-C3, but still it is not really working.

My serial output changed to this:

The I2C signals (sorry for the bad picture, I don't have a floppy drive :-) ):

[martinjaeger]

Thanks @JochenKr for double-checking. Looks very similar to my communication. It's really strange (and annoying) that it works with the STM32, but not with the ESP32-C3.

I'm wondering if there is something that keeps the chip in deep sleep mode. Maybe we should double-check the voltage levels the bq76952 sees at the WAKE pin (triggered by the button).

Didn't have much time for further testing with the ESP this week and will get back to that next week. If we can't get it to work soon I'll send you an STM32 MCU :)

[JochenKr]

I checked already. Really strange, I don't see the wake to be pulled up by the bq96952. So I added an additional pullup to 3V3 . I played around on that, but didn't make a difference.
I also added a switch to the reset pin of the bq to 3V3 and a 10k pull down. But also resetting doesn't make a difference.

[martinjaeger]

On my working board the TS2 pin is pulled up to 3.6V in SHUTDOWN mode, which is not exactly the ~5V mentioned in the datasheet. After pressing the button it goes down to 0V.

On the board with ESP32-C3 the pin is rather unstable and shows something between 1.6V and 1.8V and a button-press has no effect. I'll further investigate if there is any oscillation in the power supply.

[martinjaeger]

Ok, first problem is fixed. It was a bad solder joint in R18 (BAT power supply). Now the bq seems to be on, as I see 1.8V at the REG18 pin (C20). Communication still not working, though.

[martinjaeger]

Finally it's working! I've introduced proper error handling for the hardware initialization to prevent it from flooding the bus even though no ACKs are received. This seems to do the trick:

*** Booting Zephyr OS build zephyr-v3.0.0-12-gf51daad0d3d7  ***
Hardware: Libre Solar BMS 16S100 SC ESP32C3 (v0.2)
Firmware: v21.0-82-g90fa76d-dirty
I: detected bq device number: 0x7695
E: I2C transfer error: -116
E: I2C error for subcmd_read: -116
E: BMS hardware initialization failed, retrying in 10s
I: detected bq device number: 0x7695

I could also observe some glitches on the I2C bus during start-up. That's maybe why it fails in the first attempt and afterwards works.

I've added some preliminary commits to disable the non-working button detection during operation and to disable the ThingSet serial interface because it results in a hard fault. See the commit history for details: https://github.com/LibreSolar/bms-firmware/commits/esp32-c3-support.

[JochenKr]

I checked on my side, and it is working as well.
It shows the same behavior. At first the initialization fails, after the first retry it is working fine.

[martinjaeger]

Great. I'll keep the issue open because of the glitches at the beginning of the communication, but fixing that is not a major priority for me at the moment.

[JochenKr]

I took a deeper look into the I2C data. Seems that every answer from the bq is followed by a NACK.
The content, e.g. of this register 0x34 is correct.

NACK is marked in red:

[martinjaeger]

This NACK is sent by the receiving side (in that case the microcontroller), correct? So this could mean that the driver has a bug?

Does this happen for all communications or only during the failed initialization phase after firmware boot?

[JochenKr]

It happens on all communications.
Not sure if comes from the MCU or the bq. I'll add a series resistor to check who is doing this next week.

[JochenKr]

As the signal is released to high, it's not clearly visible by the series resistor. But most likely the NACK is sent by the receiving side. at least it is clear that the MCU is not pulling low for ACK as it does after the first data byte

[martinjaeger]

I thought this issue was solved, but it turns out that with Zephyr v3.2 upgrade the I2C comms hardly works at all. It succeeds to obtain the bq chip serial number, but afterwards only produces errors on the bus.

I've ordered a proper logic analyzer (the scope can't catch sufficient data to analyze the entire communication) and hope to find the root cause soon. I suspect it's an ESP32 driver issue, as it works perfectly fine with the STM32 and the exact same firmware.

[1278043638]

I think maybe the chip is different.If you use BQ7695202, it will have CRC detection by default.
When BQ7695202 detects invalid CRC, it will return NACKs signal.
For details, please refer to the chip manual of BQ76952. My technical level may not be enough to solve the problem.
This is my guess.

[martinjaeger]

The I2C communication is now finally working. See zephyrproject-rtos/zephyr#51405 for details. The commits have been cherry-picked to the Libre Solar Zephyr fork. They are included automatically through west update.

The glitches during start-up which make the first I2C messages to the bq76952 chip fail (described here: zephyrproject-rtos/zephyr#51250) still persist, but we can live with that and just retry to establish the communication after start-up.