How to tell the difference between a hard power cycle and the nPORRST line going low

Hi David,

During a power-up event, the TPS device release the reset to MCU with a certain delay time after VDDx have crossed the undervoltage thresholds. The SYSESR shows the source for different resets encountered, and 15th bit tells if the reset was caused by Vcc (VDDx from TPS device) being out of range (nPORRST was asserted).

nPORRST will init MCU and RAM, all the data in RAM will be lost. If you want to hold the variable values, please use FEE (Flash EEPROM Emulation, Bank 9 of Flash) will save the variables.

Regards,

QJ

Hi QJ,

Thanks for your response. If I'm reading it right, there is no way to tell if a reset was caused by the TPS reset, or a hard power cycle.

Where is the TPS reset line recommended to connect to? It is important for my application to know if the TPS watchdog failed.

Thanks,
David

Hi,

I really need an answer on this, it's critical that my application can tell if the reset was caused by the TPS watchdog or not.

Thanks,
David

David,

David Sabol said:

How can I tell the difference between the two reset conditions?

As I understand it, this is the crux of your concern.   I don't know the answer.  I don't think you can distinguish the two by any register on the MCU. 
So the place I'd look is in the TPS register set.   I haven't looked through that yet though.

David Sabol said:

Right now I am planning on putting a value at a known address in RAM and setting it to a specific value in my program.  I'm assuming if power is lost it will lose its value, but if the nPORRST is pulled low it will retain its value (until the RAM is initialized).

Unfortunately, I think you'll find that the SRAM content *may* be retained even if there is momentary power loss.  It all really depends on how long and how low the power rails dip.  And while we spec a minimum operating VCC,  this doesn't mean that the converse (RAM will be corrupted) is true when you go below this spec.   So I wouldn't use RAM values as a way to distinguish between a power loss and a PORRSTn for other reasons. 

David Sabol said:

Also, can I create a section of RAM that I can prevent from being initialized?

Not so easily done because of ECC.   You would want to test the contents of this area of RAM and be able to determine that they are valid and scrubbed of ECC errors as well.  Otherwise if you leave the RAM uninitialized and turn on ECC, you'll likely get double bit errors in that area. 

I think QJ's response about using FEE was assuming that the problem statement is saving values while power is off.  But I don't think that approach is relevant to the question of whether you can determine a true power loss v.s. a PORRSTn assertion for some other reason. 

Thanks for your response.

I've read through the TPS datasheet, and unless I missed something, there is no register or way to tell that is has caused just caused a reset. There is a watchdog count register, which causes a reset when it hits 7, but I can't rely on monitoring that since if spi comms dies I won't be able to read the count.

It seems like the answer to "How do you tell from the Hercules that the TPS just caused a reset?" is to connect the reset line to the nRST line and not the nPORRST line.

Thank you for your help.

David

Hi David,

I was just skimming the TPS datasheet as well. The TPS65381 team does have their own forum (they monitor the automotive forum), so I think we should eventually move this post to or ask the question as well on their forum.

When I skimmed the TPS datasheet, I found the VMON_STAT1 and VMON_STAT2 registers. These seem to have bits indicating when the rails have been detected as going out of range.

There's also a separate "SAFETY_ERR_STAT" register that catches things like a watchdog reset.

So I *think* the answer is that you have to check the TPS chip over the SPI from Hercules after a power on reset to get additional information as to why it pulled power on reset.

Let me know what you think about these registers - and if they look promising we can confirm w. the TPS team. (If not it's probably time to ask the TPS team what other way we can distinguish between reset sources..)

Hi Anthony,

Thanks for taking a look at the data sheet.

I did some testing this morning, and it looks like all three of those registers will show errors while it is running, but if a reset is caused (whether by the TPS watchdog, or a power cycle) both VMON STAT registers show no errors, and the SAFETY_ERR_STAT does not show a watchdog reset error, even after I stop servicing the watchdog so it resets.

I can post in the automotive forum and ask.

Thank you for your help,
David

Hi David,

Just wanted to check if you're getting any help on the TPS side with respect to the watchdog status question. Would be good for us to know this too.

Hi Anthony,

They are looking into it, but said there is no direct way to detect it.

e2e.ti.com/.../1419302

Since TI recommends using the TPS chip in conjunction with the Hercules, I would expect that this is something that anyone who uses the watchdog would want to know, it doesn't do a lot of good if the system is resetting but you have no idea why. Maybe most people who use the TPS chip either don't use the watchdog or don't enable the watchdog reset.

Thanks for following up,
David