Microcontroller Reset

[jmar1900]

Are you guys aware of any microcontoller architecture/family that preserves state, ie. pin muxes, GPIO, ADC/DAC pins during and after CPU reset?

[KL27x]

Such a tease. Why would you want this? Is the micro going to be connected to a different circuit every time it power cycles?

Why not load the configuration from EEPROM on boot, and save change to EEPROM whenever the program changes the configuration?

W/e you are asking seems very specific/niche. Perhaps if you give a hint, you may find a solution.

[ataradov]

Any MCU can do this - simply don't connect a reset pin. What would reset do if it does not change anything?

[BrianHG]

Any MCU can do this - simply don't connect a reset pin. What would reset do if it does not change anything?

Yup, use a high priority interrupt input and create your own software reset.  This way you may preserve any IO, peripheral controls, or CPU registers you like.

[KL27x]

Just making your own reset, yeah that works.
Don't forget to wipe the stack and reinitialize all memory.

If it's just a matter of keeping pins held hi/lo/high impedance, (doing whatever they were last doing) throughout a pin reset, just do an interrupt that keeps hold of the pointer until the reset pin is let go. And then you can even execute a software reset instruction at that point.

Is this perhaps for debugging purposes? When reset is performed, state of the pins can be checked, kind of like a breakpoint?
 

[KL27x]

Oh, I got one potential reason.

Emergency stop (or halt) on a systems control board, initiated by higher processor in the system.

Basically telling the ports,

Program:  Freeze! Someone done @#$@up, again. Just hold still until we sort it out. Ted coming over to do a head count. Yes, timers, that means you, too. Recording all pertinent info for when he arrives.
RA0:         This @#$, again!
RA1:         It's probably ATTiny over in the speed control unit. He's always #$%ing running into the weeds.
RA0:         How would you know that?
RA1:         What do you mean?
***     They turn just in time to see Ted arrive. Program hands over a briefcase.
Program:   How long?
Ted:         Should be any second, now. I gotta run.
***     a few uS later RA0 and RA1 are awash in the great white light of the RESET.
RA0:         Good morning, One!
RA1:         Good morning, Zero!

[colorado.rob]

Emergency stop (or halt) on a systems control board, initiated by higher processor in the system.

Do you really want a reset for that? Make one of your interrupt pins very high priority so nothing preempts it.  Handle all of the Emergency Stop functions there.

[KL27x]

^Exactly what I suggested to elaborate on what they suggested. But if reset is necessary, which at times may be the case, it can be done after ISR is performed. Rather than to go thru the all the things involved in a reset, aside from pin configuration, "manually."

Will that satisfy OP's requirement? I don't know. I'm just guessing at what he is planning to do with this feature. 
Or why he would find it useful. There's something he's thinking about.

*The interrupt handler would require that there are no other highest order interrupts which might be in service (or in the weeds). If the processor must be reset vs program branch via control by external source, there is probably a reason.

[John Coloccia]

My guess is OP wants to do something coming out of a watch dog timer reset. It would be helpful to know what he's actually trying to accomplish.

[KL27x]

That is a very good guess. But if i am reading ur mind, this entails sleep, which preserves the pin state. And during wake, going high Z for a few microseconds compared to lenghtybsleep periods would have to pose a problem. I havent thought of a practical problem, there, which is not easily fixed, but it's a lot easier for op to tell us then to try to come up with every situatuon i have never thought about.

Is the OP asking a noob question or is he an experienced embedded programmer and silicon design engineer with a very good idea and practical problem? I am not smart enough to assume one way or the other.

It is easy enough to restore the previous pin state if u can just store it in a protected area of memory like in blueskulls micro with the special feature. Or perhaps store this info in a condensed code in a byte or three of eeprom. Many micros can also tell difference btn software/hardware reset and power cycle, if that is necessary. If a reset, some can even differentuate between software and physical reset vector. It is the "during" the reset that is particularly problematic. I think reserving highest order interrupt is closest i can get with the micros i know and my knowledge, and then doing a selective manual reset in software. But that doesn't help in case of device "latchup" due to external conditions, say a transient exceeding max electrical specifications. In case such as this, clearing pin configuration may be necessary to start the machine back up.

[BrianHG]

Another partial solution, as hinted above, is to hard wire the reset to that it can only be pulsed for the minimum amount of time possible to do a valid reset.  The first operation in the software code should be to set the tristates of the IO ports.  If you are using a pic, it actually maintains the output data, inputs and analog inputs aren't important as all the IO revert to input states anyways, all you need to worry about is just the outputs.  In my design cases, if I must, I usually have a pull-up or pull-down resistor if something needs to be forced at reset.

As for telling what state you are starting up in, PICs have a register which tells you if you just came from a power-up, or brown-out, or watch-dog timer timeout, or reset pin trigger.  I'm sure other MCUs have similar power-up status registers, or I hope they do.

[jmar1900]

Ahhh, a reason for my question ;^)

I need to maintain GPIO and DAC output values for a non-service affecting requirement.

Hard resets on parts I'm familiar with will reset the pin muxes and i/o pins to a "safe state" (tri-state).

Of course, I can attempt a "soft reset" in software, but this can turn out to be very complex and not work every time.

And, as pointed out, there are unexpected watchdogs and other exceptions.

Also, I am looking at a situation which seems to *require* a reset: the STM32 ROMed bootloader.

Speaking of which, I find the STM32 bootloader autobaud "feature" somewhat flaky. Anybody else?

[mikerj]

W/e you are asking seems very specific/niche. Perhaps if you give a hint, you may find a solution.

It's a fairly common requirement in my work where an in-service firmware upgrade must be followed by a hard reset (customer requirements) but not affect the operating of the device it's controlling.  Previously this required the use of latches and external DACs etc.

The ADuCM320 is a Cortex M3 part that supports this requirement, and also has other features such as dual banked memory to make upgrading even simpler.  It also includes some very nice analog peripherals (high resolution voltage and current DACs and ADCs).