• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 649 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ34Z110: bq34z950-compatible 1-wire battery keeps dropping connection to DQ line

Christopher Theriault
Prodigy 10 points
Part Number: BQ34Z110
Other Parts Discussed in Thread: BQ2050, BQ34Z950, EV2400

Tool/software:

scope_plots.pdf

We're working with this battery (www.bren-tronics.com/bt-70716bv.html) from Bren-Tronics using the 1-wire interface.  The battery specs say it is compatible with the BQ2050 and BQ34Z950 TI interfaces, but this forum does not allow me to pick BQ34Z950 as a part number.  The battery connects to an STM32F411 which polls the battery over the DQ line.  From what we can see on the o'scope, our timings and voltages are in spec, but every so often we get repeated failures where the battery does not respond to the signal over the DQ line.  We can tell when the battery has attached itself internally to the DQ line as this causes a slight drop in voltage.  If this voltage drop is not present, then we know the battery will not respond to any of our commands.  It is unclear what might be causing this and hopefully someone here can give some insight.  Attached is a PDF showing o'scope comparisons between our widget and a commercial charger, along with our DQ line circuit schematic and the results of both a success and failure communicating with a battery.  Both our widget and the commercial charger send out a burst of byte requests to the battery every 3 seconds or so and inside a burst there appear to be no additional timing delays between bytes.  Even so, if we see that the battery is failing to attach to the DQ line it will not respond to even one byte requested. 

  • 0
    TI__Mastermind 25665 points

    Hi,

    Unfortunately, the link shared did not work.

    The schematic looks ok.

    Do you know why sometimes the voltage drops and connects and sometimes not?

    Regards,

    Diego

  • 0 in reply to Diego
    Prodigy 10 points

    Hello-

    To manually navigate to the product page, visit bren-tronics dot com, pick "Product Directory" from the top, then scroll down and expand out MBITR PRC-148, 7.0 Ah.

    We don't know why at times the battery fails to clamp to the DQ line.  This is the crux of the issue- if we knew what *could* cause this type of behavior from the battery, then we would know what to look for in our system.  As it is we only know that we appear to be following the specifications correctly as regards to voltages and timings.

  • 0 in reply to Christopher Theriault
    TI__Mastermind 25665 points

    Hi,

    Does the BQ34z950 have any issues communicating HDQ with the MCU or EV2400?

    Regards,

    Diego

  • 0 in reply to Diego
    Prodigy 10 points

    Not that we can see.  If the battery responds, it responds correctly with 8 bits and the value of the byte itself is in line with our expectations.  To our knowledge the batteries do not reply erroneously.  The only unexpected battery behavior is that it clearly doesn't clamp to the DQ line at times, and if it doesn't, no reply at all comes out on the DQ line.

  • 0 in reply to Christopher Theriault
    TI__Mastermind 25665 points

    Hi,

    This sounds like an issue with the battery communication and not the gauge then.

    Regards,

    Diego

  • 0 in reply to Diego
    Prodigy 10 points

    We're open to the issue being an error in the protocol on our end, but it is not clear what this might be.  As can be seen from the PDF our timings are comparable to a commercial charger.  The charger starts by requesting register 0x09 which is "Capacity Inaccurate Count".  We start by requesting register 0x0D followed by 0x0E which is the "Compensated Capacity" high and low byte pair.  Nothing in the battery documentation indicates any kind of preferred order in what registers you read.  If communications get really bad we'll just see our requests for 0x0D going out over and over unanswered.  If our voltages on the DQ line are in spec, the timings are in spec, and we're requesting reads of valid registers, what else is there to look at?

  • 0 in reply to Christopher Theriault
    TI__Mastermind 25665 points

    Hi,

    Not sure your approach appears correct.

    What address are you using?

    Regards, 

    Diego

  • 0 in reply to Diego
    Prodigy 10 points

    Can you be more specific in saying "not sure your approach is correct"?

    We request the following register values every 3 seconds in this order:

    CACH (0x0D), CACL (0x0E), PPD (0x07), PPU (0x08), RSOC (0x5A), TMPH (0x52), TMPL (0x53)

    If the battery does not respond within 35ms to one of these register requests (the spec says 30ms is the maximum battery timeout) we error out and abort for that sequence without attempting to read any of the other registers during that window.  There does not seem to be anything in the bq2050/bq34z950 documentation that indicates there is any particular order in which you request register data or that the battery needs to "rest" or something after requesting X bytes.  As stated, if the battery is not pulling down the voltage on the DQ line slightly we know already it will not be responding to any transmission from the STM32.  In very rare cases this happens immediately and the battery is already in the unresponsive state when all we've done is sent out 0x0D.  In theory the fact that we start every register read request with the BREAK pulse means the battery should be resetting itself, but it clearly doesn't.

  • 0 in reply to Christopher Theriault
    TI__Mastermind 25665 points

    Hi,

    Understood, what are your timing parameters?

    Regards,

    Diego

  • 0 in reply to Diego
    Prodigy 10 points

    We're following these specifications that were provided by the battery manufacturer:

    Comparing these timings with the o'scope plots in the previously attached PDF we cannot find any violations.  There also does not appear to be any difference in our signal output between when the battery does and doesn't respond (except as explained, when the battery correctly attaches itself to the DQ line, there is a slight drop in voltage).  The manufacturer outlines this behavior via this table:

    Images in this post are copyright Bren-Tronics.

  • 0 in reply to Christopher Theriault
    TI__Mastermind 25665 points

    Hi, 

    The timing specs I provided are from the BQ34z950 datasheet, if the cell manufacture provided different specs please contact the cell manufacture with this issue.

    The BQ34z950 has different parameters related to timing, I am asking what these parameters are configured to on your gauge?

    Can you pull your configuration from the gauge?

    Regards,

    Diego

  • 0 in reply to Diego
    Prodigy 10 points

    BREAK 3125ms, Tsv 3375ms, 1-bit 650ms, 0-bit 1875ms, BREAK recovery 1500ms    

      

  • 0 in reply to Christopher Theriault
    TI__Mastermind 25665 points

    Hi,

    The Break you have is 3125ms, the spec from the ds is 3ms, this will cause a timeout.

    Regards,

    Diego