• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 298 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.

Original question:

i2c bus is always busy

MSPM0G3507: i2c controller problem

Andy Hsu
Prodigy 80 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: BQ40Z50,

Tool/software:

Hi,

I have problem with reading registers from BQ40z50 via smbus/i2c through MSPM0G3507 

It works well for a lot of time, but suddenly the I2C stop working and SCL is pulled down. Below is my data through Logic Analyzer 

I tried to find the issue through debug mode, I found the i2c controller status was busy, hence I can't read or write the command to BQ40Z50.

if(dl_I2C_getControllerStatus(I2C_1_INST)&dl_i2c_controller_status_busy_bus)

{
    return BQ40Z50_BUSY;    

}

Is there any way to solve this problem? Or if there is any issue besides the controller was busy?    

Best Regards,

Andy

  • 0
    Guru 100405 points

    As near as I can tell, the clock is being stretched after the first (data) bit of a write to the BQ40Z50, i.e. mid-byte (very unusual). I've never seen the MSPM0 I2C halt mid-byte, so my first guess is that it's the target that's stretching.

    The BQ40Z50 is capable of stretching the clock, but the data sheet/TRM (SLUSBS8B/SLUUA43A) don't say when/why it will do this. Searching the Forum for "BQ40Z50 AND stretch" turns up some information but no hard clues, e.g.:

    https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1124391/bq40z50-r1-clock-stretch?tisearch=e2e-sitesearch&keymatch=bq40z50%2520AND%2520stretch#

    Is that "33" over at the left a command? The TRM refers to a "0x0033" command [Ref sec 12.1.59]  which puts the chip into "ROM mode", which sounds like some kind of diagnostic thing.

    The Power Management Forum people might have some better answers.

  • 0 in reply to Bruce McKenney
    Prodigy 80 points

    Hi Bruce,

    Is there any way to solve the stretching problem? 

    Bruce McKenney said:
    Is that "33" over at the left a command? The TRM refers to a "0x0033" command [Ref sec 12.1.59]  which puts the chip into "ROM mode", which sounds like some kind of diagnostic thing.

    No this is about reading command "0x0016" which is 'BatteryStatus' and the data comes up with 0033(hex).

    How can I find Power Management Forum people?

    Best Regards,

    Andy

  • 0 in reply to Andy Hsu
    Guru 100405 points

    SMBus imposes a clock-low timeout (25ms or 35ms, I've seen both mentioned), after which all agents should "reset".

    The BQ40Z50 cites a 25ms maximum for its clock stretching [Ref SLUSBS8B Sec 7.33], but I don't know what its recovery action is.

    The MSPM0 can detect a timeout [Ref MSPM0 TRM (SLAU846B) Sec 20.2.3.6], but all it does is inform you that it happened.

    At the I2C level, the only recourse for SCL-low is to reset/power-cycle the target; the BQ40Z50 appears to run off the battery, and I don't see a reset pin, so I don't know if this can be done.

    The MSPM0 Controller side is capable of clock stretching [Ref MSPM0 TRM Sec 20.2.3.7] but the listed causes all occur on a byte boundary.

    It's also (remotely) possible that there's something (noise?) on the bus wires that the logic analyzer can't see.

    The Power Management Forum is over here:

    https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum

    Maybe you can include a link to this thread in case the MSPM0 people can contribute.