TM4C1294NCPDT: RST pull-up when using hibernation: to VBAT or to VDD

TM4C129 Manual said:

When the Hibernation module wakes, the microcontroller performs a normal power-on reset. The
normal power-on reset does not reset the Hibernation module or Tamper module, but does reset
the rest of the microcontroller. Software can detect that the power-on was due to a wake from
hibernation by examining the raw interrupt status register (see “Interrupts and Status” on page 548)
and by looking for state data in the battery-backed memory (see “Battery-Backed
Memory” on page 545).

Robert

Pawel Hoffmann said:

Yes, this I know. But where should the RST pin be pulled-up?
If it is to VDD I assume I can get another reset

Why?

What testing have you done that would show that?

Robert

Pawel Hoffmann said:

So I need clear declaration - best from TI person, is it: VBAT or VDD?

Thus - you are asking the "authors" of the "unclear declaration" to (now) provide clarity.     (claiming outsiders - to be 2nd best)

Proper, "Back-Up" power-source distributor ICs "effectively diode OR" the outputs of supply and battery - so that (only) the highest voltage among those two - powers (volatile memory) and/or MCU Reset...    (it is assumed by such chip designers that the "supply" voltage exceeds that of the battery - when it (supply voltage) is (indeed) present.)

I don't know - nor have interest in (s-l-o-w) 129 series - yet is it not likely that VDD "drives to (near) zero" (i.e. why maintain VDD if "low power consumption" is desired?) when the MCU is in "power-down (i.e. hibernate) mode?

Robert> This I haven't tested. I don't know how to test it. I'm not SW developer in this project. This is my conclusion because when I have VDD LOW in hibernation and RST is pulled to VDD for uC it is like power on reset when VDD goes high.

Bob> OK so in hibernation my VDD should be 0V (it isn't). And VBAT is 3,3V so current is flowing as you say. And this makes VDD over 0V. So I change the pull-up to VDD.

cb1_mobile> this is my first question on this forum. I don't want to offend members to be worse or 2nd best. Just the users can have only observations on their use. You say you ar not interested in 129... And I'm asking how it is done inside chip, what only TI guys can know and answer. As Bob did. Also datasheet is something what has revisions. If something is not clear (maybe to more people then just me) maybe it can be made more clear in next revision. I have assumption that this forum can have also this result - making the documentation better.

Thank you for answers.

I will change pull-up to VDD and make further measurements. As pull-up is 100k this can't influence hibernation current as much as I have it. There can be additional reasons. 

Changing to 100K (far higher than "norm") may make the MCU more sensitive to "noise/other" (even slight) power disturbances...  

May I note that, "Long standardized techniques" (sometimes compromised w/in MCU implementations) may render such (MCU compromised) other than, "Best/Brightest!"    Your review of past/standard "methods" to achieve such "Reset and/or Volatile Memory powering" - under "normal supply" or battery power - provides you a "superior grasp" of your situation...

Pawel Hoffmann said:

Robert> This I haven't tested. I don't know how to test it.

By actually running it and seeing if you get two distinct resets and how often?

Pawel Hoffmann said:

I'm not SW developer in this project.

As long as someone writes the SW it's an easy test.

Pawel Hoffmann said:

This is my conclusion because when I have VDD LOW in hibernation and RST is pulled to VDD for uC it is like power on reset when VDD goes high.

???

Robert

Pawel Hoffmann said:

. I have 100k pull-up on RESET tied to the supply which is active all time - VBAT. Maybe it should be tied to VDD?

Perhaps is not so good the idea to pull up MCU reset pin via 100k tied to VBAT as Robert indirectly (answered) very 1st posted comment, CB1 noted the (what if) section in data sheet is absent.

The MCU should not reset twice during wakeup from 100k to VDD when street power returns. Seemingly the MCU reset pin reacts to the return or absence of street power at all times reports in software register such conditions that caused Hibernate, POR, BOR etc. Seems there is no way to stop MCU from doing a POR when street power returns, less we somehow hold down the reset pin? Note the hibernate module has 16 slots 32 bit wide NV memory for software to save other application data besides the system state information automatically being saved during BOR. 

Seemingly the application picks back up where it was interrupted by BOR event using the system state data that was saved as the BOR event occurred. You have to test that occurs seamlessly and not just start the application over after the BOR. Perhaps LED blink rate can help with determining the application is running from saved system state data (BOR) event or otherwise a normal POR event. 

Might the language w/in your very first post - have led poster "BP" (and others) to such conclusion?

Pawel Hoffmann said:

I have 12V power supply ... I have 100k pull-up on RESET tied to the supply which is active all time

More clarity IS required - to prevent such uncertainty.     As the "highlight" reveals - the "tie of RESET" (may) indeed be to 12V supply!  

Noted too - the post you "awarded" - (to me) does NOT (AT ALL) answer your specific question!    (it presents - instead - a caution - yet NOT any answer!)

Your use of, "I have 100k pull-up on RESET tied to "VBAT" - rather than "supply" - would have better clarified.

And that WAS my suggestion to you.    

Your question demanded direction: VBAT or VDD? - such was (clearly) NOT provided by the awardee...   (cautioned ONLY - don't exceed 3V3!)   

That's well done - far clearer to even (others) who may land here (now or in the future) and benefit from your good work! (which IS the central purpose of such forum)

It "would" prove of interest if you (here or w/in another forum thread) reported your "new Power Consumption results" - brought about by your latest connection to Reset.

My interest (really is) in assisting you - and my (earlier) reference to "Dedicated Supply Switch-Over ICs" I believe - provides the best insights as to "how you may best reduce (unwanted) power consumption..." (MCU methods alone - due to size/cost constraints - do not (always) prove best...)

First answer by Robert was a quote from datasheet about the hibernation but with no hint at all to me. I got it as totally irrelevant to tell if it is VDD or VBAT. Bob on other hand pointed me exactly to solve my problem. Why do you ask so much? Is it a person gets lots os points when I mark the answer that this is the one which solved the problem? I really do think that answer by Bob was exactly what I have needed and that's why I marked it.

Regarding my results and external switch over IC: This uC when properly used is able to have very very low hibernation current - single uA. So I don't see any need to have external circuits. It was just to use it properly. And what I was doing not proper was the RST pull-up. Which has to be VDD. And I had voltage divider with constant on supply connected to ADC. This were to sources of leakage to the VDD making it non 0V and increasing hibernation current. I also have serial debug adapter in my project. If I leave it powered and attached to the device (adapter TX being high) it also injects current to TIVA RX pin also making VDD non zero and increasing current consumption. So conclusion is this uC can hibernate at very low currents but you have to be really sure EVERYTHING what is powered during hibernation has to be disconnected from it.

Pawel Hoffmann said:

I really do think that answer by Bob was exactly what I have needed and that's why I marked it.

Believe you clarified point earlier post about supply=VBAT not 12v and I missed the post however in hind sight it would seem more plausible 3v3 LDO regulator drawing current not the rail diodes. The B- rail diodes seemingly should only have nanoamp reverse current leakage under most conditions, especially when being reversed biased on the reset pin.  Microamp leakage might suggest the MCU 2v LDO is somehow improperly sinking current via the reset pin B+ rail diode into VBAT supply or via VBAT powered hibernate module. What should the reset pin care if it is held high during hibernate mode ? yet had no effect as Robert pointed out to stop the POR event on Wake events. 

Pawel Hoffmann said:

you have to be really sure EVERYTHING what is powered during hibernation has to be disconnected from it.

Actually the datasheet comments all external connections have to be powered off but not disconnected seemingly that is one reason why 3v3 LDO has it's EN pin tied to MCU HIB piin.