Other Parts Discussed in Thread: BQ25708, BQ40Z50, TCA9517
This question/note is related to the content here:
In the problem, the TCA9800 is used to isolate the system CPU (Microchip/Atmel SAMG55) from a "smart battery" pack and our battery charge controller. The smart battery uses a BQ40z50 battery manager. Our charge controller is the BQ25708. The problem occurs when the charge controller turns on and supplies charge to the battery pack. It exhibits itself with corruption of the data line with sporadic noise at roughly the switching frequency of our charge controller. Here's a scope presentation:
And here's what it looks like in a protocol analyzer:
The noise appears to present itself when an ACK is expected.
After a lot of head scratching, it occurred to me that the TCA9800 B side, which is the side that services our charge controller and smart battery pack with data and clock, determines a low based upon how much current it detects is being drawn from an external device. Given that we have two "client" devices on the SMBUS (the CPU twi/SMBUS is on the A side of the TCA9800) I wondered if the electrical interface of each device SMBUS lines were, when combined, causing the problem.
When we first designed our system, 100 ohm series resistors were used in SMBD and SMBC at the smart battery connector for the purpose of damping any ringing during level transitions. Could this (low) series resistance be adding just enough resistance that devices on the buss have insufficient ability (perhaps due to RDS ON in their output switching fets) to draw sufficient current from the TCA9800?
When I removed the 100 ohm series resistance, the problem went away entirely. I have been unable to bring it back (so far)!
Questions:
1. Is my theory sensible?
2. The electrical interfaces of both the BQ40z50 and the BQ25708 are not adequately defined (AFAIK) in the data sheet. I'm not sure the SMBUS specification deals with current sinking/sourcing ability of the interface, nor whether these are relevant in situations where the buss is shared between (in this case) the devices we are using.
3. What happens when ACK is expected? It appears it's at this point in the SMBUS signal state that the noise appears.
4. Since the noise is at the switching frequency of the BQ25708, it seems reasonable to assume this device is our culprit. Is it?
I suppose this kind of issue could be solved with a more selective interface/DSP on the CPU side... for example, having a minimum clock and data width. But this doesn't help when the CPU is out of the equation.. which occurs when the battery pack sends charging data on the bus which is picked up by the charge controller and acted upon (the "smart" side of the house). With a mangled SMBUS, those comms would be ruined, as would any safety features we wish to implement through monitoring for alarms. Therefore it was imperative to solve this.
Hopefully we did so, but I'd like to hear from TI on this particular scenario.