• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 649 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BQ40Z50-R2: Unable to make START condition on I2C line

Roman Khazanskii
Prodigy 190 points
Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQ40Z50, BQSTUDIO, EV2400

The problem is as follows: sometimes I2C communication works perfectly and sometimes it doesn't. When it doesn't it looks like this (that should be a START on I2C line):

My MCU tries to be a master on I2C line and perform START condition, however, it is unable to do so. Sometimes it literally just happens for several times and several second (about 15) and then suddenly it is able to perform START and complete transfer.

To reproduce this try:

1) Go to SEALED mode

2) Try reading a register that is not available for reading in SEALED mode, for example, 0x54 OperationStatus (not to be confused with Manufacturer Access register 0x0054 OperationStatus which is available in SEALED mode).

3) Try reading something else after this.

3) Observe broken START.

I wasn't able to find anything similar in I2C or SMBus standart or in documentation for BQ40Z50

  • 0
    TI__Intellectual 1365 points
    Hi Roman,
    It looks the host causes the glitch. The gauge is working as a slave mode if broadcast function is not enabled. When it is a slave mode, the gauge is input state.
  • 0 in reply to Jasper Yi
    Prodigy 190 points
    That's interesting, I will post a question on related forum. Meanwhile, I need to clarify some things:

    1) If gauge is in slave mode, it shouldn't save anything by itself, right?
    So why do I see something sent in I2C when my host MCU is stopped by debugger? Is it normal?

    2) To go to SEALED or UNSEALED mode I have to do this:
    send SEAL/UNSEAL
    wait about 100 ms
    read Operating Status register, look into SEC0 and SEC1 bits (current status). Check if it is correct. Repeat the whole thing if it isn't.

    And my code repeats this cycle several times before I finally read correct status back.

    If I don't read Operating status and try reading some other register instead, I get that "faulted start" again.

    Is it normal? There was no mention of this in datasheet.
  • 0 in reply to Roman Khazanskii
    TI__Intellectual 1365 points
    1. It is not normal. When I tested on the EVM, I could not see any transaction on both SCL/SDA lines if a host doesn't send a command.
    2. No, even you don' read operationStatus()(0x0054), it should read a register correctly. I forced the gauge to go into "sealed mode" and write a different command(0x0053) to see a "faulted start" but could not see any abnormal waveform.
  • 0 in reply to Jasper Yi
    Prodigy 190 points
    Any ideas what can I be doing wrong?
  • 0 in reply to Roman Khazanskii
    TI__Intellectual 1365 points

    How about connecting EV2400 to your board and send a word command in bqstudio ? If you compare the scope shot between them , it would give some hints.

  • 0 in reply to Jasper Yi
    Prodigy 190 points

    Okey, so I tried going back to factory firmware and gauge stopped talking by itself. That's nice.

    Problems with going into sealed/unsealed mode also seem to vanish after repeated firmware reprogramming. That really makes me uncomfortable.

    I'm not sure what's happening anymore; here's .srec file that I used. May be you will be able to see something in it.

    3AH_Battery.zip

  • 0 in reply to Roman Khazanskii
    TI__Genius 14985 points
    Hi Roman,
    Is your issue closed? It sounds like you might have enabled the BCAST (broadcast mode) bit in your original configuration which would allow the host to master the bus sometimes, but that going back to factory defaults which has the bit cleared solved your issue. Let us know if you are still having issues with this or not. Thanks!
  • 0 in reply to dMax
    Prodigy 190 points
    I think we can close this; since this issue is resolved by MCU hard reset I believe it's caused by faulty I2C implementation in MCU and not in gas gauge. I managed to produce a kludge.