• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 48 subscribers
  • Views 266 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.

INA229: Device sends invalid data on MISO until INA229 is power cycled.

Boris
Prodigy 20 points
Part Number: INA229

Hello,

I've noticed an issue where occasionally the INA229 starts sending invalid / unexpected data on MISO back to the STM32 main micro. This usually happens when the micro (not INA229) is soft reset or power cycled. After this occurs the INA229 keeps sending invalid data until it is power cycled. Sending a reset command via CONFIG register does not fix the issue.

Valid Data Example: Requesting Device ID by sending 0xFD, correctly receives 0x2291

Invalid Data Example: Requesting Device ID by sending 0xFD, Receiving 0x40 before the command is even sent out. 

Once the INA229 gets in this state I cannot get it to send rational data back until a full power cycle. Sending reset command does not work. In both examples CS is pulled low at all times (only one device on the bus).

Any help to understand what causes this issue and how to fix it would be appreciated.
Thank you!

  • 0
    TI__Mastermind 19355 points

    Hey Boris,

    Is it possible that you are resetting the MCU during a communication? Maybe the INA229 is in mid transaction and waiting for an MCU response. Can you try to see if the communication resumes after releasing chip select and then pulling it back low? 

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 20 points

    Hi Mitch,

    That was my initial thought as well though I've noticed that sometimes this issue occurs while resetting mid MCU communication but have also observed it when a reset occurs after a SPI transaction is completed. The datasheet says that a CS line is optional as long as there is only one device present and is always pulled low. Is there an option that doesn't involve the CS line?



    Thanks,
    Boris

  • 0 in reply to Boris
    TI__Mastermind 19355 points

    Hey Boris,

    Could you look at the communication with a scope line instead of a logic analyzer to make sure all the voltage levels and signal timing are within the datasheet limits?

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 20 points

    Hey Mitch,

    I've reviewed the datasheet timing requirements and looked at the SPI transaction with oscilloscope, everything looks okay to me. Here's an oscilloscope trace of the Invalid Data Example where the INA229 sends back data before the command is even sent out.

    The voltage levels all look good to me, clock and data signals have no significant skew.

    Thanks,
    Boris

  • 0 in reply to Boris
    TI__Mastermind 19355 points

    Hey Boris,

    Thanks for sending the scope shot. I agree  that nothing looks out of place here. Since this issue only happens after an MCU reset, could you monitor the communication lines as well as the power and ground on the INA during the MCU's reset? I'm wondering if a weird signal gets sent during reset, or if the power drops low on the INA (but maybe not fully off).

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 20 points

    Hey Mitch,

    Just reproduced this issue three times, in all three times the micro gets reset mid SPI transaction with bus sensor. If we can assume that's the issue  (I will still try to reproduce when reset occurs not during SPI transaction and issue still occurs) is there anything that can be done besides a power cycle? Like mentioned earlier, sending the reset command does not work.

    All examples below show the reset occurring in the middle of SPI comms with the INA229.

    Instance 1:
    - Digital:

    - Analog:


    Instance 2:
    - Digital:

    - Analog:


    Instance 3:
    - Digital:

    - Analog:


    Thanks,
    Boris

  • 0 in reply to Boris
    TI__Mastermind 19355 points

    Hey Boris,

    Yes, can you please try to reproduce when they device is not mid communication? My best guess is that the communication is being offset if the chip select is low and the clock toggles when not expected (ie, during power cycle while in mid communication or from clock noise). Besides a power cycle, I would recommend releasing the chip select, as that pin is designed to synchronize communication with the device. Although the device does work with the chip select held permanently low, it is possible communication gets messed up from unintended or interrupted clock signals. 

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 20 points

    Hey Mitch,

    I will continue to try to reproduce the issue when the device is not mid SPI transaction. I will try with CS working as well though I'm running into a different issue with the CS on the INA229EVM board that is discussed here.

    I will update this thread with new findings.

    Thank you,
    Boris

  • 0 in reply to Boris
    TI__Mastermind 19355 points

    Boris,

    Ok, thank you, keep me posted!

    Regards,

    Mitch