What does a reset of a PIC microcontroller via MCLR actually clear?

Question

I'm working on a project that uses a PIC18F26K22 microcontroller, and it's behaving oddly.

Basically, sometimes if you kind of "bounce" on the reset line (I have a button on it, and I just kind of fiddle with it), it will reset and some of the interrupts will not be functional (in this case, the EUSART RX interrupt).

The reset button has a debouncing capacitor to ground, and a pull up resistor (10n/10K respectively).

I've tried adding some precautionary cleanup to the startup section of the source, but it hasn't helped. At this point, I have a manual watchdog that detects a lack of serial traffic, and manually triggers another CPU reset, at which point everything starts working correctly.

My assumption was that the registers on the chip were all reset to their "power-on" state when a reset was triggered (excepting perhaps the RCON register), but the fact that I can fairly reliably trigger strange behaviour by just resetting the chip multiple times quickly makes me think this is not true.

Is corruption of registers triggered by repeated reset a common (or even extant) thing with PICs? I'm mostly familiar with AVRs.

---

Edit: I considered switch-bounce, but the documentation for the MCLR input states:

These devices have a noise filter in the MCLR Reset path which detects and ignores small pulses.

My assumption here was that reset pulses shorter then the minimum width (2 uS, for this part) would be ignored.

---

Further edit: I've actually looked at the MCLR line with a scope. It is both bounce-free, and entirely satisfies the minimum hold time (the shortest period I saw was ~50 milliseconds, the minimum hold time is 2 microseconds). It's not MCLR bounce.

Answer 1

The reset states of all the registers are very well documented in the datasheet. That tells you exactly what you can rely on being set a certain way versus unknown after a reset. In general though, it is a good idea to explicitly set any special function register values that rely on.

Another problem might be bouncing on the reset line. Look at the electrical spec for the minimum timing of a reset pulse. You may be violating it, especially considering mechanical switches bounce and therefore can produce arbitrarily short pulses during the bounce period.

One way to deal with this is to have the switch short a cap to ground. The line will go low quickly, but after that it will take some minimum time for the switch to be open before the cap voltage rises to the minimum possible high level of the reset pin. If you do this, make sure to put a resistor between the cap (and the switch and its pullup) and MCLR. That allows a programmer to still drive MCLR as it needs to. Some PICs require fast rise times on MCLR during programming, which a cap directly on the pin prevents.

Answer 2

The design of reset circuitry poses three major issues:

1. Entering a reset state.

2. Leaving a reset state.

3. Handling "runt" pulses on the reset line which don't fully enter a reset state.

Having a reset line simply force everything asynchronously into a known state will take care of problem 1. A reset pulse may hit some parts of the circuit before it hits others, but if each circuit is forced into a state that won't depend upon the behavior of other circuits, then as long as the reset line is sufficiently low for sufficiently long, everything will end up in the proper state.

Leaving the reset state poses another wrinkle, which is that if a clock edge happens precisely at the same time as the reset is being released, some parts of the device may try to start operation on that cycle while other parts don't start operation until the next cycle. This issue can be resolved by having some circuitry to decide whether at least 3 clocks have happened following the reset. If a clock arrives just as the reset line is being released, the circuitry may not instantly decide whether the next clock pulse is the first or the second, but should be able to make up its mind about whether the succeeding one should be deemed the "second" or the "third". If none of the other circuitry which had been reset will do anything until the aforementioned signal indicates that at least three clocks have occurred, then everything should begin operation at once.

Even when the first two issues are taken care of, though, the third remains, and there's really no 100% reliable way to ensure that a device won't get glitched by "runt" reset pulses except to either (1) ensure that it doesn't see any, or (2) require that the reset signal be synchronized to the clock, delaying the effect of the reset until the third succeeding clock edge (which could mean delaying it indefinitely if the clock isn't running). There are various ways to design hardware that would allow a device to behave as though resets were acted upon asynchronously even if the reset pin only fed a single asynchronous latch, but I don't know how widely such things are used.

Based on your description, it sounds as though the PIC is wiring its reset signal so that it forces asynchronous resets of the PIC's internal registers, but has not thoroughly guarded it against runt pulses. I would expect that if you want reliable operation, the way to get it is going to be to ensure that any time the reset line goes low at all, it will go low for long enough to cleanly reset the entire chip. If the device doesn't need to keep any state across resets, it isn't likely to matter if there are runt pulses on the reset line provided that any runt pulses get followed by valid ones. If the device does not to keep state, runt pulses should be avoided entirely.

Answer 3

Another way to solve this problem and get a nice clean waveform on the MCLR pin is to use a reset supervisor chip. (Microchip also makes some of these). Some models of these have a provision for connection of your reset button and will keep re-triggering the low time on MCLR till the switch has been open for a good amount of time. The supervisor I use on my PIC32MZ board even has a connection for a capacitor the control the time of the MCLR extension of there is a bounce pulse on the switch signal.

Answer 4

A solution to most kinds of spurious behaviour is an automatic periodic watchdog. It requires adding to the program a small code that must be performed periodically and sends a pulse to charge a capacitor that is otherwise discharging with a long time constant (so the overall speed performance of the microcontroller is barely affected). In normal use, the capacitor is never allowed to discharge past a threshold that resets the controller. If an unpredicted error occurs during use the watchdog resets the controller which gets back to work. Intermittent errors will show up if the watchdog also drives a warning LED, and they should then be easier to diagnose.