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

LM49251: I2C Bus Lock w/STM32L4

Dirk Mahoney
Prodigy 20 points
Part Number: LM49251

Hello everyone,

Background:

I2C Bus Lock using LM49251 with an STM32L4. 15K external pull-ups on both SDA and SCL. Trying to use the CubeMX HAL code where possible. Vdd: 3v3, HPVdd: 1v8, I2CVdd: 1v8. STM32 Vcc: 1v8.

Disclaimer:

As this does appear to be a general case of I2C bus locking, I was hesitant to post this issue in this forum. But after losing much hair and sanity, I come here in the hope that there's something magical and special about the LM49251 that it won't recover from this situation by the 'usual' methods, and that there is a software method by which the communications to the LM49251 can be restored when needed.

Problem:

It appears that our device is suffering the occasional brownout reset when batteries become problematic, sometimes several times in row if power is really unstable. The successive resets will occasionally result in the I2C bus becoming 'locked' as a result of the STM32 abandoning its 'initialization' conversation with the LM49251, and the LM therefore expecting SCL oscillations that will never come. SDA is sometimes held high, and sometimes low.

Challenges:

The hardware cannot be modified to include an MCU-controlled reset circuit for the LM49251, as this is for an existing device that is already designed, manufactured, and selling into the market.

Progress so far:

After having researched STM32 and I2C bus lock and reset issues, we have tried implementing various incarnations of readily-available code that implements an I2C unlock procedure that should free the slave from it's waiting state and allow communications to resume. The main source for this was the link below, even though it's mainly directed at STM32F4s...

electronics.stackexchange.com/.../i2c-busy-flag-strange-behaviour

Other methods used in place of, as well as in conjunction with the above, was a forced reset, and the changing of the GPIO versus I2C clock init ordering as mentioned here...

electronics.stackexchange.com/.../stm32-busy-flag-is-set-after-i2c-initialization

And finally, have tried by both software and hardware, raw SCL toggling (in bursts of 17 cycles or more) to no avail.

Help! :)

Thanking you all in advance.

Dirk

  • 0
    TI__Guru* 84915 points

    Hi, Dirk,

    Welcome to E2E and thank you for your interest in our products!

    The I2C problems that we have faced in the past with this device are related to a bad power supplies stability. Do you have details about the power supplies ripple or if they are stable when the I2C problems start? Our audio devices are tolerant to power supplies sequencing but having a constant variation may result in this kind of events.

    Best regards,
    Luis Fernando Rodríguez S. 

  • 0 in reply to Luis Fernando Rodriguez S.
    Prodigy 20 points

    Hi Luis,

    Thank you for the reply. We are currently investigating your suggestion regarding power stability. In the meanwhile, could you please tell me if there is any sequence of signals we could emit on the I2C bus in order to force the LM49251 to 'unlock' itself and reset it's internal state machine? As we are investigating this issue for an existing product, a software resolution to this problem is highly desirable.

    Thanks,

    Dirk

  • 0 in reply to Dirk Mahoney
    TI__Guru* 84915 points

    Hi, Dirk,

    I would recommend to check the registers associated to the device shutdown. For example, shutdown control register will need to be placed in normal operation and the Class-G and LM49251 should be both enabled. I also recommend to read the rest of registers in order to understand what it the current state of the device.

    Please let me know if you have additional questions or comments.

    Best regards,
    Luis Fernando Rodríguez S.