I have included a screen shot of what I am seeing on the HDQ interface to our battery.
First, note that I am showing a data trace at my Open-Drain TX buffer and I am showing one at the battery connection (to prove this signal is getting off my board and to the battery). At one point I was showing my TX signal and my RX signal to show the feedback was getting to my RX buffer and that I was receiving data (I have since move that connection out to the battery to prove the signal is getting to the battery). That is why there are two signals on the screen shot for a 1-Wire Interface.
Next, I am trying to show a ‘1’ being sent and a ‘0’ being sent. Note: All bit cycles are 200usec long and for the ‘1’ I was using 20usec LOW but have since change that to 40usec LOW and 160usec HIGH and for the ‘0’ I send 120usec LOW followed by 80usec HIGH.
When ever I send data I also receive data and in my code all my TX data (bytes) matches my RX data (bytes).
Not shown on the screen is a LOW pulse of 250usec to ‘sync’ the initial battery data (recommended by the battery manufacture). That LOW 250usec pulse was about 2msec before the start of actual data to the battery.
I send a control byte to the battery (0x01) followed by several ‘0xFF’s to try and receive data from the battery.
When I first used the 20usec LOW pulse to the battery I would never received any response from the battery, but when I widened that LOW pulse on the ‘1’ from 20usec to 40usec, I started receiving some response from the battery but it was not a consistent response (usually one response in about 4 or 5 command packets).
Any help would be appreciated. Thanks!
What fuel gauge IC are you trying to communicate with inside the battery? It's always a good idea to include the device name in your post title so it will get to the right person.
The only reason I left that out is that we aren't manufacturing the battery. The battery is spec'd such that the interface must be "BQ2060-like". So, there might be more than one battery vendor, and as long as they are using HDQ, they may or may not be using the BQ2060. However, for this discussion, we can assume as much.
Just wanted to check in to see how debugging this issue is going.
Your input is greatly appreciated!
Digital Field Applications
If my reply answers your question please click on the green button "Verify Answer".
The bq2060A uses SMBus (two-wire like I2C). If you are using a single-wire protocol then it must be some other device in the pack. Are you sure this is HDQ? Or could it be SDQ/1-Wire?
It might be a good idea to crack open a pack and see what IC is really in there.
The bq2060A does offer the HDQ interface but it would be interesting if this is actually a bq2060A. The HDQ interface is open for use by others without TI's consent so could be uC which may show this kind of issue. We have had no issues with the HDQ on the bq2060A like the one you describe.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.