• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 65 subscribers
  • Views 468 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.

TPS6594-Q1: Setting new LONGWIN interval results in instant PMIC reset

Michal Matyl
Prodigy 95 points
Part Number: TPS6594-Q1

Hello.

We had a HW board update recently and we couldn't run MCU SW because WDog stopped behaving and we ended up with 15 resets and PMIC shuts down shortly after power up.
For identification HW team gave me this number: SLVUC99 which refers to PDN-0C.

For some background: I set up WDog on MCU domain of TDA4 using PDK v7, then updated PDK to v8 and resolving compatibilty issues I still had fully working WDog until this recent HW update.
There's potentially tons of changes related to that update but we started debugging with the basics - check WDog I2C comms - and already got interesting observations.

We have identified the problem solely with PDK's Pmic_wdgSetCfg() interface called during initialization. The interface reads 0x405 WD_LONGWIN_CFG register (it's 0xFF by default) and writes new value 0x03 in our case. And that causes MCU reset immediately when 0x03 writing is completed. When we applied the default value 0xFF as new LONGWIN configuration, the WDog keeps operating normally. The SW also runs normally when the WDog is disabled.

HW team say the HW update included PTPS6594-Q1 to TPS6594-Q1 change and also PMIC's NVM and firmware change.

I don't have initialization time measurement but for me this looks like we are setting new LONGWIN interval (375ms according the DS) that has already elapsed and maybe due to some new FW bug this results in instant PMIC reset ?

Do you have any other ideas why we observe such PMIC's behavior.

Best regards

  • 0
    TI__Guru 64491 points

    Hello,

        The 15 resets and then PMIC shutdown is indicating an issue that is leading to safe recovery.  This is different from the WD_LONGWIN_CFG which should simply perform a warm reset on the processor.

    The long window should only be updated when the wd is in the long window.  

    How is the DISABLE_WDOG pin being handled?  Is this pulled high in the HW?  

    I will need to investigate the PDK v8.

    Regards,

    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 95 points

    For "WDog disabled" I mean we commented out WDog_Init() and WDog_Trigger() handlers to leave WDog in long window just to check if the problem is or is not WDog related.

  • 0 in reply to Michal Matyl
    TI__Guru 64491 points

    Hello,

    In the PDN-0C which you reference, the GPIO8 of the primary pmic (TPS65941213) is configured as the DISABLE_WDOG feature.  I would recommend comparing how this pin is configured/changed between your two different setups.  Please use this document as a reference since the DISABLE_WD function is the same: https://www.ti.com/lit/ug/slvuc32/slvuc32.pdf#page=8 .

    I am investigating what happens if you attempt to change the long window to a value less than the current place in the long window.  Is it possible in your setup to first disable the watchdog and then configure the long window?

    Have you referenced the example found in the low level driver?

    Regards,
    Chris

  • 0 in reply to Chris Sterzik
    Prodigy 95 points

    Hello,

    HW team says there were no HW changes to DISABLE_WD configuration.

    As mentioned, we are using PDK's Pmic_wdgSetCfg() interface to configure the WDog. I've just checked it configures the windows, then clears WD_PWRHOLD and then enables WDog. I also skimmed through the datasheet and I noticed "Flow Chart for Q&A" implies that "setting Long-Window shorter than time in which Wathcdog has been in the Long-Window" will reset Long-Window interval (which is my expectation), but the note for Long-Window configuration chapter says in this case "time-out function of the Long-Window will no longer operate". It's kind of contradiction I didn't notice earlier, but anyway it looks like neither of the two applies to our case.

    Currently there's no HW sample available for me. We did remote debugging session for described issue. So I'm not able to investigate the issue further.

    Best regards

    Michal

  • 0 in reply to Michal Matyl
    TI__Guru 64491 points

    Ok.  Let us know if you are able to make additional progress.

    Thanks,

    Chris