0
\$\begingroup\$

I've written a little watchdog firmware that runs on an ATtiny85. The idea of the firmware is to:

  1. wait 10 seconds after power up and ignore signaling during that time
  2. after that expects a signal to be pulled low no more frequently than once every 100ms and no less frequently than once every 65 seconds, and failing one of expectations it asserts a reset signal for 10us, and then resets itself resuming at step (1).

Obviously (and arguably gratuitously) I programmed this in Arduino using the ATtiny board description, which maps the pins like so:

enter image description here

My fuse settings are programmed as follows via AVRDude:

avrdude -p t85 -c dragon_isp -P usb -u -U efuse:w:0xff:m
avrdude -p t85 -c dragon_isp -P usb -u -U hfuse:w:0xdf:m
avrdude -p t85 -c dragon_isp -P usb -u -U lfuse:w:0xe2:m

These settings correspond to:

  • Internal RC Oscillator @ 8MHz, 6CK/14 CK + 64ms
  • Clock output on PORTB4 disabled
  • Do not divided clock by 8 internally
  • Brown-out detection disabled
  • Do not preserve EEPROM memoryy through the Chip Erase cycle
  • Watchdog Timer NOT always on
  • Serial program downloading (SPI) enabled
  • Debug Wire disabled
  • Reset enabled
  • Self programming disabled.

For the purposes of debugging, it outputs a 100ms pulse width 50% duty cycle square wave during that initial 10 second period, and a 200ms pulse width 50% duty cycle after the initial 10 second period.

For good measure, here's the schematic snippet that goes with this:

enter image description here

The vast majority of the time, the debug signal behaves as described. On very rare occasions though, I've observed a flat low signal on the debug output, no square wave. I've looked at the power and reset lines of the ATtiny85 on a scope in this condition, and there doesn't appear to be any indication of a stuck-in-reset or powered-down condition occurring.

How on earth, then, could my program fail to start up? Could it be because brownout detection is disabled? Should I set the Watchdog Timer always on fuse? I'd really like to understand how this could be happening occasionally.

\$\endgroup\$
5
  • \$\begingroup\$ Yes, it's a very forgiving watchdog function, never mind that :-) \$\endgroup\$
    – vicatcu
    Dec 20, 2017 at 22:14
  • \$\begingroup\$ IS that really what you want? more frequently than once every 100ms and no less frequently than once every 65 seconds i.e. 65s<t<100ms? or the reverse 100ms<t<65s for repeat interval, t \$\endgroup\$ Dec 20, 2017 at 22:53
  • \$\begingroup\$ @TonyStewart.EEsince'75 I see the typo you were pointing out now... I updated it to say "no more frequently than" instead of "more frequently than" \$\endgroup\$
    – vicatcu
    Dec 20, 2017 at 22:59
  • \$\begingroup\$ How can you verify if a valid POR occurs on startup perhaps due to contact bounce? \$\endgroup\$ Dec 20, 2017 at 23:02
  • \$\begingroup\$ @TonyStewart.EEsince'75 was that comment rhetorical? The question is, how can a loaded avr, with (eventually) stable power and reset, and configured to use the internal RC oscillator as a clock source, not execute the loaded program (and what the heck is it doing if not executing the loaded program)...? \$\endgroup\$
    – vicatcu
    Dec 21, 2017 at 1:54

1 Answer 1

1
\$\begingroup\$

I suggest using a proper reset chip and enabling the internal watchdog timer (as well as writing your program to use it properly).

If you want belt and suspenders, use an external WDT or even a windowed WDT. If you don't care so much, consider the internal BOR if the datasheet guarantees it will work (over temperature) with your combination of clock frequency and power supply voltage.

There are plenty of ways for a microcontroller to hang, so don't use them for safety-critical applications without a lot of careful design and precautions. For example, simply bringing the power up slowly, or allowing it to dip briefly can often do the trick.


Question has been raised about what exactly as supervisory chip such as ADM805 or the equivalent internal circuit should do:

To make sure the micro starts up and does what is supposed to do, you want it to start in a known state. It should start executing code from the appropriate memory location, and the CPU must do the correct things with the program counter to keep it in the code as written. None of these things are assured without a clean reset signal. You want the reset (usually it is active low for modern micros) to be asserted from a very low supply voltage, so low that the micro cannot get into any mischief if there are actuators or whatever attached to it, or non-volatile memory that could be corrupted, up until it is within the proper supply range. The reset should be asserted after the supply voltage is valid for some time, usually tens or hundreds of milliseconds- for example if there is a crystal oscillator you want it to stabilize. If the supply voltage should dip lower the reset should again be asserted for some time. When the supply voltage is dropping when the device is turned off, it should hold the micro in reset until the supply voltage drops so low it cannot cause any issues.

The sloppy way to do this is with an RC circuit or RC+diode circuit on a reset pin, because it only works some of the time. Ideally you have a brownout reset and timer circuit that is hardware. The BOR must be guaranteed to turn off for supply okay (over temperature and tolerances) and must be guaranteed to assert the reset for supply voltage too low (but still in the acceptable range for operation) all the way down to a low voltage (typically < 1V). Some internal BOR circuits meet that spec for most normal operating conditions and some don't.

It cannot be emphasized too strongly that it is a hardware function and you cannot substitute for it with firmware. The BOR and timer should be combined with power supply design that meets the requirements and cannot glitch for too short a time to actuate the BOR.


Even if you absolutely guarantee the reset, things can still go wrong in operation, for example from an unanticipated energy of EMI impulse, soft error in the CPU due to radiation etc. To mitigate consequences of such an occurrence, many micros detect invalid program memory addresses, stack pointer errors, and can perform checksum calculations on their own program memory. In combination with programming techniques the likelihood and consequences of failure can be reduced to acceptable numbers for safety-critical systems.

\$\endgroup\$
6
  • \$\begingroup\$ Thanks Spehro, I'm trying to sort out a problem with an existing system though. And what I've got here is in fact a windowed (very wide / forgiving) wdt function. Also I'm not in a safety critical application here, but it is designed to run for long periods of time without user intervention, and the wdt function is supposed to be an independent fail safe mechanism Uncool if it doesn't start up. \$\endgroup\$
    – vicatcu
    Dec 20, 2017 at 22:17
  • \$\begingroup\$ What are some examples of "proper" reset chips, by the way? \$\endgroup\$
    – vicatcu
    Dec 20, 2017 at 22:22
  • \$\begingroup\$ STM6xxx series, for instance \$\endgroup\$
    – MrGerber
    Dec 20, 2017 at 22:33
  • \$\begingroup\$ ADM805 series, for example \$\endgroup\$ Dec 21, 2017 at 0:16
  • \$\begingroup\$ Ok... so what do chips like these do that my program running on an ATtiny85 doesn't? Maybe you can extend your answer to include some details to that effect? Obviously, I'm not measuring the system voltage at all. \$\endgroup\$
    – vicatcu
    Dec 21, 2017 at 2:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.