• State TI Thinks Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 5 answers
  • Subscribers 67 subscribers
  • Views 1481 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.

BQ27220: No Unseal response

Flemming Andersen
Prodigy 90 points
Part Number: BQ27220
Other Parts Discussed in Thread: BQSTUDIO

We are doing a product design for beyerdynamic in which we use the BQ27220 chip. We now have some random case (<1%) where the chip for a given period is not responding as expected when we are trying to get Unseal access according to slubbd4 section 6.1. to read or write some parameters like design full capacity 


After Unseal request code is executed, we are doing the expected polling to make sure the device is put into stable access mode. But we sometimes never get a SEC[1:0] equal to 10 (unsealed access)
As it in most case works fine it is hard fro us to understand  what is causing this.

We already have ”some” delay’s before and after the step 4 (TI question asked in support case: CS0193398. https://ticsc.service-now.com/csm?id=csm_ticket&table=sn_customerservice_case&sys_id=eca95aa6dba0505456e4d7b2f3961973&view=csp

We have approx 10msec between step 1, 2, 3 and 4. If the return is not unsealed we poll 10 times with 200msec delay between them.

Included picture on what is executed. we also have an IC2 trace of a case where it goes as expected and one were it do not. We cannot see any direct difference between the cases.  

  • 0
    TI__Guru 52115 points

    Hi Flemming,

    I would suggest you use bqStudio to communicate with these failing bq27220 devices. Try the UNSEAL button in the Commands Window and check if you can unseal these devices successfully. 

    Andy

  • 0 in reply to Andy Liu (BMS)
    Prodigy 90 points

    Hi,

    Ok but we know the same unit works, It is a random error that comes and goes on some units, but we do not understand how to provoker it and how it "repairs" itself. We may have indication it repairs itself if the customer let it run until the battery level is so low it hit the EDV0 and turns off afterwards.

    On next turn on it seems the External host get the expected response when trying to unseal the device 

    It is only seen on <1% of the units tested (produced many hundreds of units)    

    So I am 99% sure connecting the bqStudio will just show it works at that moment and not what happens in the random cases it does not work  

    Do TI not have a 100% secure program timing sequence we can link our timing to ?  As stated we have I2C traces of a unit that response and one that does not. I can send these to you fro review on timing   

    P.s in case we are lucky to hit the error with bqStudio what do we then do ? 

    /BR

    Flemming

  • 0 in reply to Flemming Andersen
    TI__Mastermind 24870 points

    Hello Flemming,

    I am wondering if you are able to get reproduced with a beagle or aardvark i2c bus sniffer. These things are fairly hard to debug.

    For the bq27220, I think it is actually a ROM gauge. Even when it is sealed, you can POR the device and the device will boot up unsealed.

    I think it could be repeated seal/unseal requests. The gauge can only be unsealed once every 4 seconds I believe. You can try this on an EVM, send seal and unseal repeatedly, I think you may get stuck in a loop.

  • 0 in reply to Kang Kang
    Prodigy 90 points

    Hello Kang

    We have I2C traces of a good and bad case captured by the Saleae logic analyser  (https://www.saleae.com/) and we see no logic difference in these.  

    We have both the  analoge and digitale files, but they are somewhat large as the I2C is also used for control of other chips set. I can share them i just do not know how to in this forum. 

    The BQ27220 is not use as a pure ROM device in the project it is for some paramters program in RAM only. So a POR is not as far as i known possible as it will reset all the battery learning information and that is not allow according to my customer 

    Forgot to say that we only try to unseal the unit one time at turn of the external host. We only have retry on the pooling of the fuel gige response. So we should never try to unseal the Fuel gauge within 4 seconds periods as the external host is not restarted that often. The Fuel Gauge is never stopped it is always active. 

  • 0 in reply to Flemming Andersen
    TI__Guru 61906 points

    Please make sure you do not violate the specific timing requirements for this gauge. Please pay close attention to 7.3.1.3 (http://www.ti.com/lit/ds/symlink/bq27220.pdf). If you violate this, the gauge will not just stop working but some write operations may fail randomly.

    I recommend changing all I2C writes to single byte writes, not auto-increment multi-byte writes (see the //Alternative single byte method comment in the data memory update example) and add the appropriate delay.

  • 0 in reply to Dominik Hartl11
    Prodigy 90 points

    Hi, 

    I believe our code meet the timing demand, but we do not use single byte write as we did not see that as a mandatory demand in the TI documentation.  We will try to see if that gives any difference.  

    However do anyone know how the fuel gauge gets out of this bad no unseal response mode again, if it has enter this mode ?

    Our customer test on the few failing unit found indicated it was first happening when the battery level got below the shut down limited (EDV0). They did recover at some point and the fuel Gauge was not reset from the host, that we know.   

  • 0 in reply to Flemming Andersen
    TI__Guru 52115 points

    Have you seen any difference after following Dominik's suggestions?

    Andy

  • 0 in reply to Dominik Hartl11
    Prodigy 90 points

    Change to single byte writes do not help on units, that was already in a mode where it does not repsond. They still do not respond. It may secure no more unit go into this mode but it does not help us solving the full issue 

    So do anyone know how the fuel gauge gets out of this bad no unseal response mode again, if it has enter this mode ?

    Only indication we have is to let it run to battery capacity is so low that it met the turn-off voltage.

  • 0 in reply to Flemming Andersen
    TI__Expert 8425 points

    Hi Andy, Kang, Dominik,

    this issue is not resolved yet. do you have any further hints how to get the device out of the locked mode?

    "So do anyone know how the fuel gauge gets out of this bad no unseal response mode again, if it has enter this mode ?"

    Did you try to reproduce this issue?

    We can also provide sniffing data from the I2C communication between a good and a failing device if his helps to find a solution.

  • 0 in reply to Simon Jagla
    TI__Mastermind 24870 points

    Hello Simon,

    We recommend the customer provide us scope plots and we can help analyze. this is mostly host based code.

  • 0 in reply to Kang Kang
    Prodigy 90 points

    Hi,

    As I wrote some time ago. We have I2C traces of a good and bad case (same host timing) captured by the Saleae logic analyser  (https://www.saleae.com/).  

    We have both the  analoge and digitale files, but they are somewhat large as the I2C is also used for control of other chips set. I can share them i just do not know how to in this forum. 

    They are from before the single byte write change, but we should be able to make same with the new single byte write. But how can you form this see how to get the unit out of the bad mode again. If the unit is already in the bad mode before we do the FW update then it seem to be stay in this mode.   

  • 0 in reply to Kang Kang
    Prodigy 90 points

    As indicted above: 

    We have I2C traces of a good and bad case captured by the Saleae logic analyser  (https://www.saleae.com/) and we see no logic difference in these.  

    We have both the  analoge and digitale files, but they are somewhat large as the I2C is also used for control of other chips set. I can share them i just do not know how to in this forum. 

    They are from before the Single byte write, we can make some for this SW as well, but as single byte write does not get the units out of the unwanted mode, I am not sure if that they will tell anything. the Single Byte write will of course be used going forward.

    But the question is now; how to get a unit that is already in the bad no response mode before FW update (and due to this gives no unseal response using single byte write after FW update) out of this mode ?  

  • 0 in reply to Flemming Andersen
    TI__Mastermind 24870 points

    Hello Fleming,

    Please POR the units. I believe that should get it to a default state.

  • 0 in reply to Kang Kang
    Prodigy 90 points

    Hi 

    Not 100% sure what you mean here. remove power to the device ? 

    Isn't a POR a full reset of the device and we will have lost any learning of battery capacity and user have to do a full charging cycle (charge and discharge to get some learning back into the device) ?

  • 0 in reply to Flemming Andersen
    TI__Mastermind 24870 points

    Hello Flemming,

    This is a ROM device. If you remove power to the device, it will boot up as unsealed.

    Once you confirm this, you can reprogram the device through CFG Update Mode again.

  • 0 in reply to Kang Kang
    Prodigy 90 points

    Yes but as stated above we use it in more products with different batteries but same SW, so we do not use the ROM values only RAM values. This may be a wrong way to use your chip withe information we have now. 

    Furthermore if we did use the ROM values wouldn't the paramters like learned Full Battery Capacity of the fuel gauge be lost under a POR? 

  • 0 in reply to Flemming Andersen
    TI__Mastermind 24870 points

    Hello Flemming,

    I understand.

    Your RAM values will get loaded, but upon every POR, ROM values will get copied to RAM and you need to over-write them again.

  • 0 in reply to Simon Jagla
    TI__Guru 61906 points

    The gauge uses the following internal process for unsealing:

    Gauge is sealed (e.g. after a reset. This can be a power on reset because the voltage dropped below the POR threshold and then recovered):

    * gauge receives first unseal key (16-bit):

    * if the key is correct, the gauge starts a 4 second timer.

    * gauge receives second unseal key (16-bit) within 4 seconds:

    * if the key is correct, the gauge unseals and stops the timer.

    * if the key is incorrect, the gauge restarts the 4 second timer.

    --> the gauge will not accept another unseal key until this 4 second timer expired

    * if the second unseal key wasn't received within 4 seconds:

    * the internal state machine for the unseal sequence resets and the host must start the unseal sequence with the first unseal key.

    --> If you run into problems unsealing the gauge, stop for 4 seconds and make sure that there is no communication with the gauge until 4 seconds elapsed. Then make 100% sure that you write the first unseal key followed by the second unseal key while not violating any timing restrictions that are specified in the datasheet.