• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 235 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.

BQ35100: How to issue the "New Battery" command

James Ball
Prodigy 10 points
Part Number: BQ35100
Other Parts Discussed in Thread: BQSTUDIO

I have a BQ35100 which I'm using in EOS mode. I can successfully read and configure the device, except to initiate the new battery.

I have forced the EOS alert on my device and wish to clear and reset the BQ using the New Battery (0xA613). The problem is if I send this command, then read the Battery Alert register (0x0B) it still shows EOS and has not been cleared as expected.

My current procedure:

1. GE enable

2. Wait for IntComp = 1

3. Send New Battery (0xA613)

4. Read Battery Alert register (0x0B)

5. GE disable

If I separate the above commands to happen one at a time triggered manually, I was able to the the EOS alert clear. When I put the sequence together as above, the alert does not get cleared (reading 0x19). I've tried upto 500ms delays but no success. I don't want to just try and guess at delays.

What is the correct procedure to set the new battery? Do you have a sample code or script I can use as reference?

I believe my code is functioning correct as I am able to start and stop the active modes which use the same write sub command function.

  • 0
    TI__Guru** 102395 points

    Hello James,

    You can use the BQStudio communication as a reference, if it is working and your code is not there may be something missed in the driver code. You can use a logic analyzer to compare with your MCUs implementation.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    Hi Wyatt,

    Thanks for the suggestion. I was hoping I would not have to reverse engineer it but may be faced with that approach.

    I was hoping someone might be abe to point to something missing in the sequence. I don't think I missed anything from the data sheet, and all my other commands write and read as expected.

    It is a little time consuming to simulate the EOS condition. I've got my device in that condition now. I'd prefer not to just experiment but have a clear understanding of what the correct procedure should be.

    Thanks,
    James

  • 0
    Prodigy 10 points

    OK. Think I have a reasonable solution and understanding, but this definitely wasn't documented in the datasheet or TRM.

    To find the issue, what I did was poll the control status register every 100ms after issuing the "new battery" command. What I saw was surprising!. Immediately after the new battery command and for ~1s (10 polls) the status register was normal (same as before issuing the command). On the 11th poll I got an I2C error. On the 12th is see the INITCOMP=0! After another ~500ms the INITCOMP goes to 1.

    Looks like the chip is resetting itself. For the first ~1s there is no indication this is occurring, then the INITCOMP goes to 0 for a few hundred ms. After the INITCOMP=1 again, I see that the EOS condition is cleared and I can now disable the chip.

    Here's my new sequence:

    1. GE enable

    2. Wait for IntComp = 1

    3. Send New Battery (0xA613)

    4. Delay 1300ms

    5. Wait for IntComp = 1

    6. Read Battery Alert register (0x0B)

    7. GE disable

    In step 6 above the register now shows that the EOS has been cleared! Hope this helps someone else with the same issue. Some people wouldn't;t see this issue if they didn't;t try to disable the chip directly after sending the command.

    -James

  • 0 in reply to James Ball
    Prodigy 10 points

    Can TI confirm this solution is correct? If so, the documentation should be updated to include this procedure?

  • 0 in reply to James Ball
    TI__Guru** 102395 points

    Hello James,

    After the new battery command, after the gauge stop conditions, or any reset. Anytime the gauge is doing computations or initializing you should wait for the INITCOMP to set. This is the correct flow.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    Hi Wyatt. Thanks for the confirmation.

    After sending the stop command, the TRM states that you should wait for G_DONE to be asserted, so this is clear and works as expected. The issue with the new battery command is there seems to be no indication that the device is "busy" for over a second after issuing the new battery command. After this 1s delay, looks like the device resets and then you can look for INITCOMP. 

    Anyway, sounds like my procedure is correct, just wanted to highlight it for others as it is not described in the documentation (at least not that I found).

    Thanks!