• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 415 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.

BQ24250: The BQ24250 hangs I2C Comm.

Michael Nikonov
Prodigy 90 points
Part Number: BQ24250
Other Parts Discussed in Thread: BQ25601

Hi , 

I have strange conditions with BQ24250, which hangs I2C line.

I have a project , which includes BQ24250 (Charger) , STM32L4R5 (MCU) , 3 x CY3866LTI(PSoC) and bq27421(fuel gauge) , all together shares same I2C line . MCU is a master and all other ICs are slaves .

PSoCs have 0x21,0x22,0x23 addresses and according to datasheet , Charger have 0x6A address .

The commination from MCU to all peripherals includes REPEATED START condition , and most of time performs OK  . But once in a while , when MCU requests data from any of PSoCs ,after PSoC responded , Charger hangs the I2C line for ~542 ms.

How do I know is a Charger ? I've made investigation ,and found the condition when I2C hangs. 

I have tried disconnecting Charger and Fuel Gauge from the line ,and problem disappears when Chargeris disconnected , and Fuel Gauge connected.

The condition when Changer hangs I2C :

 

The problem happening , when MCU communicates with any of PSoC and PSoC responds with 0xD4 value as first byte.

In a picture , you can see communication among MCU and PSoCs when PSoCs firmware modified in a such way ,that it forced to respond with 0xD4 ,and I2C hangs .When Charger physically disconnected from the I2C line , the problem disappears .

After that , I've made dirty modification of the PSoCs is a such way that it will never response with 0xD4 as first byte, Charger connected back to the I2C line , and  problem disappeared.  

Another clue why it is Charger ,is because 0xD4 value is shifted left 0x6A , i.e. 0x6A << 1 = 0xD4 .And 0x6A is Charger's I2C address , so when 0xD4 appears on the line , charger "thinks" that somebody tries to communicate him ,therefore Charger hangs the line waiting for commands.

So my question is : why it's happening ? 

My thought about this , is because there REPEATED START condition , but according to Charger's datasheet , page 33 , is compatible to work in such conditions.

So , any help  : problem confirmation or explanation why it's happening , will be appreciated. 

 

  • 0
    TI__Guru*** 143830 points

    Hi Michael,

    I haven't heard of this issue before.  It appears that the second START needs a STOP but when it doesn't get one, the I2C engine is relying on the 512ms timeout to end the I2C transaction.  This was one of the first chargers with our in-house I2C engine.  You might use an oscilloscope instead of logic analyzer to look at how rounded the pulse edges are.  If there is too much capacitance on the line, it is possible that the charger is misreading the address as you suggest.

    Regards,

    Jeff

  • 0 in reply to Jeff F
    Prodigy 90 points

    Currently I don't have proper oscilloscope , but I will check it as soon as I can .

    Jeff F said:
    It appears that the second START needs a STOP but when it doesn't get one, the I2C engine is relying on the 512ms timeout to end the I2C transaction

    I want to explain problem better : 
    1 . MCU asks PSoC some data. In order to make problem happen  ,   PSoC is programmed to reply with 0xD4.

    2. After that PSoC replies with 0xD4 as a first byte (after "address stage" of the 2nd START CONDITION)  , on Logic Analyzer you may see there is 0x01 as 2nd byte, but from MCU's "point of  view" , the I2C line is busy  and it cannot perform 2nd STOP CONDITION and MCU exits I2C transaction because of timeout programmed to 25 ms. But Logic Analyzer continues to recording ,and SDA line freed up after 77ms.(This shown on following screenshots  , this the same case , but different than recording in my starting post) 

    Just to be clear : the problem appears where there is no intention to communicate with Charger .

    Same screenshot, zoomed out : 

  • 0 in reply to Michael Nikonov
    TI__Guru*** 143830 points

    HI Michael,

    Unfortunately, I do not know of a way to prevent this I2C glitch from happening.  This is one of our older chargers and there are no plans to make modifications or fix issues.  If this charger does not work for you, then perhaps the BQ25601 is a better charger for your application.

    Regards,

    Jeff

    Update, the solution is shown here:

    e2e.ti.com/.../bq24250-the-bq24250-hangs-i2c-comm-cont