• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 115 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.

TPS274C65: Reading SW_STATE without disturbing it

user7026557
Prodigy 20 points
Part Number: TPS274C65
Other Parts Discussed in Thread: TPS2HCS08-Q1

Tool/software:

We're using the TPS274C65AS in a system with a host microcontroller, DSPI=0, CRC_EN=0. In some circumstances, the microcontroller might need to restart or will otherwise lose its in-RAM state, which will also cause the in-memory copy of what SW_STATE ought to be to get lost. Saving this shadow copy to persistent storage on each change would cause significant wear, so we'd like to avoid that.

We now want to be able to read back the current state of SW_STATE from the TPS274C65 without accidentally changing the state of any output (and thereby possibly powering down/starting a device downstream). However, as far as I can tell, this is not possible because every read will implicitly set the current switch state from the lower nibble in the first byte of the transaction. E.g. reading SW_STATE will return the current state of SW_STATE, but since we had to supply some new value as part of the SPI transaction header, the outputs will toggle accordingly after the transaction ends.

Is there any way we can query the value of SW_STATE without disturbing it? I haven't tried it but I could imagine playing some trick like doing multiple operations without releasing CS or something like that, depending on if that is even possible and how SW_STATE is latched, but none of that is really specified in the data sheet. I'd appreciate any input.

Thanks!

  • 0
    TI__Mastermind 35675 points

    Hello,

    I see what the concern is- There wouldn't be a way to query the STATE pin without any sort of initial setting of it. I am guessing the scenario here is that after the TPS274C65 has been configured, the MCU loses power/power cycles and then the value in the "shadow" variable on your MCU is lost? In this case I would recommend having the initial write to disable the SW_STATE (thus putting it to a known good state), and then setting it accordingly.

    The TPS274C65 does the VDD rail on it- are you powering the MCU from the same rail? The first byte read of very transaction will be a copy of FAULT_STATUS_TYPE which does specify SUPPLY_FLT.

    SPI just reads clock ticks so you could have a pause between the first byte and the second byte during the SPI transaction. During that pause you check the SUPPLY_FLT bit and if it is set, you assume that a supply fault has happened and set the SW_STATE to 0 as a safeguard.

    What is the application here? Devices like the TPS2HCS08-Q1 would have an limp home mode that would but state in a known state during certain faults... it is a 12V automotive device though. 

    Best Regards,
    Tim

  • 0 in reply to Timothy Logan
    Prodigy 20 points

    Hello,

    thank you for your reply!

    > What is the application here? Devices like the TPS2HCS08-Q1 would have an limp home mode that would but state in a known state during certain faults... it is a 12V automotive device though. 

    This is an industrial 24V design where we want to avoid toggling downstream devices in either direction (from off to on or the other way around) in such a scenario. So while your suggestion works for cases where there is a "known good" state we can always set, this is not the case in our scenario.

    We're going to work around this problem by adding some more wear-resistant memory and store the latest state there on each change.