path: root/doc/www.ganssle.com_articles_anmi.txt

   [1]The Ganssle Group logo
   [2]The Ganssle Group logo
     * [3]Click here for a navigation menu

     * [4]Firmware
       Classes
          + [5]Public Training
          + [6]On-Site Training
     * [7]Newsletter
          + [8]Subscribe
          + [9]Back Issues
     * [10]Expert
       Witness
     * [11]Blog
     * [12]Videos
     * [13]Tool & Book
       Reviews
          + [14]Tool Reviews
          + [15]Jack's Books
          + [16]Other Embedded Books
     * [17]Special
       Reports
          + [18]Designing Ultra-Low Power Systems
          + [19]Surprising Scope Probe Issues
          + [20]2020 Salary Survey
          + [21]Debouncing Contacts
          + [22]Watchdog Timers
          + [23]Microprocessor History
          + [24]Being a Consultant
          + [25]Write-only Memory
          + [26]Process Improvement for the Boss
          + [27]Commenting Code
          + [28]Testing RAM
          + [29]Getting Into Embedded Work
          + [30]Code Inspections
          + [31]Automatic Bug-Finding
          + [32]eXtreme Instrumenting
          + [33]Math Approximations - Trig
          + [34]Math Approximations - Other Functions
          + [35]Better Resumes
     * [36]Articles
          + [37]All Articles
          + [38]Analog, Filtering, etc
          + [39]Communications
          + [40]Debugging
          + [41]Fun Embedded Stuff
          + [42]Hardware
          + [43]Historical
          + [44]Managing Projects
          + [45]Math in Computers
          + [46]Memory
          + [47]Philosophical and Career
          + [48]Real Time
          + [49]Software & Firmware
          + [50]Tools for Embedded Developers
          + [51]Sailing!
     * [52]Random
       Rants
          + [53]Electronics
          + [54]Business Issues
          + [55]Software Engineering
          + [56]Products and Reviews
          + [57]Philosophy of Engineering
          + [58]Miscellaneous
          + [59]History of Electronics and Embedded
          + [60]Software
          + [61]Random Thoughts
          + [62]Fun Stuff
          + [63]Real-Time Issues
     * [64]Humor
     * [65]Contact/Search
          + [66]Contact Info
          + [67]Advertise With Us
          + [68]Search This Site
          + [69]Jack's Bio
          + [70]Expert Witness
          + [71]Our Privacy Policy

The Perils of NMI

   NMI is a critical resource, yet all too often it's misused.

   Published in Embedded Systems Programming, April 1991
   For novel ideas about building embedded systems (both hardware and
   firmware), join the 40,000+ engineers who subscribe to [72]The Embedded
   Muse, a free biweekly newsletter. The Muse has no hype and no vendor
   PR. [73]Click here to subscribe.
   LA104 Logic Analyzer October's giveaway is a LA104 mini logic analyzer.
   I reviewed it in [74]Muse 406. .Enter the contest [75]here.

By Jack Ganssle

   Wise amateurs fear [76]interrupts. Fools go where wise men fear to
   tread. Normal sequential code is hard enough to understand, code, and
   debug. Toss in a handful of asyncronous events that randomly change the
   processor's execution path, perhaps thousands of times per second, and
   you have a recipe for disaster.

   Yet interrupts are an important fact of life for all real time systems.
   No experienced programmer would dream of replacing a clean interrupt
   service routine with polled I/O, particularly where fast I/O response
   is required.

   In fact, interrupts are the both the best and worse microprocessor
   feature. Well thought out interrupt-driven code will be reasonably easy
   to write, debug and maintain. A poorly conceived interrupt routine is
   probably the worst possible software to work on. Because interrupts are
   so important to embedded systems, it is vital to become proficient with
   their use.

   If interrupts are tough to work with, then the non-maskable interrupt
   (NMI) is the true killer of the business. Be careful before you connect
   a peripheral to your processor's NMI input - think through the problems
   carefully.

   Almost every processor has some sort of NMI signal, though it may be
   called something else. On the 68000, a level 7 interrupt cannot be
   masked, and is equivalent to NMI. Some 8051-family CPUs have no
   non-maskable interrupt, an idea that is sort of appealing in terms of
   enforcing interrupt discipline.

   I'm a firm believer in restricting NMI to those conditions that are
   truly unusual and of momentous importance. Quite a few designers use
   NMI as a general purpose interrupt, a practice that usually spells
   disaster.

   When timing gets tight, the code can easily disable a conventional
   interrupt. Indeed, the very assertion of an interrupt signal
   automatically turns all interrupts off until the software explicitly
   reenables them, giving the code a clean window to process a high
   priority task. Not so with NMI. An NMI at any time will interrupt the
   CPU - no ifs, ands or buts. As long as the hardware supplies NMIs to
   the processor, it will stop whatever it's doing and vector through the
   NMI handler.

   The very fact that NMI can never be disabled makes it ideal for
   handling a small but vital class of extremely high priority events.
   Chief among these is a power failure. If a system must die gracefully,
   then hardware that detects the imminent loss of power can assert NMI to
   let the software park disk heads, put moving sensors into a "safe"
   state, copy important variables from RAM to non-volitile storage, and
   generally prepare for being down.

   Modern power supplies have little reserve capacity. Old linear designs
   had massive filtering capacitors that acted like batteries with several
   seconds of reserve capacity. Today's off-line switchers use
   comparatively tiny capacitors; smart electronics does the filtering.
   When the AC power goes down, the switcher's output quickly follows
   suit.

   During the short time it takes for power to trail away the code may
   very well be executing with interrupts disabled. Only NMI is guaranteed
   to be available at all times. Power fail is such an important event,
   that NMI is really the only option for notifying the software of
   power's impending demise.

   Perhaps more should be said about power fail circuits at this point,
   since so many suffer from serious design flaws. Most embedded systems
   ignore power fail conditions. Running ROM based code with no dangerous
   or critical external hardware, they can restart without harm from the
   top when power resumes. However, two types of systems require
   power-fail management hardware and software. The first category are
   those systems controlling moving objects; a disk controller should park
   the head, a robot should stop all motors, and an X-ray system should
   shut down the beam.

   The other class are systems that preserve transient data through a
   power-up cycle. A data acquisition system might need to keep logged
   data even when power goes down, an instrument sometimes has to save
   painfully collected calibration constants, and a video game should
   remember high scoring individuals' initials and totals.

Decaying Power

   Far too many designs rely on nothing more than battery backed up static
   RAMs or some true non-volitile device like an EEPROM to store data
   through multiple on/off cycles. More often than not these schemes work,
   but all will sooner or later fail. Let's consider what happens when the
   AC power fails.

   Without AC, the power supply stops working. The computer continues to
   run from the energy stored in the supply's output capacitor. The amount
   of time left before the computer goes haywire is proportional to the
   size of the capacitor in microfarads and inversely proportional

   Until the computer's 5 volts decays to about 4.75 it continues to run
   properly. At the 4.75 volt level most of the system's chips are no
   longer operating in their design region. No one can predict what will
   happen with any certainty.

   At about 4.8 to 4.9 volts the well-designed power fail circuit will
   inject an NMI into the computer (some detect missing AC cycles, a
   better but more expensive approach). Probably the system has only
   milleseconds before Vcc decays to the 4.75 volt region of instability.
   The NMI routine should quickly shut down external events and save
   critical variables.

   After processing the power fail condition, the computer and external
   I/O is all in a safe state. The voltage level continues to decline past
   4.75 volts, eventually reaching zero. Unfortunately, the supply's
   capacitor decays exponentially. It will provide something between zero
   and 4.75 volts for a comparatively long time (perhaps seconds).

   What does the CPU chip, memories, and glue logic do with, say, 4 volts
   applied? No one knows. No vendor will guarantee any behavior under the
   4.75 volt level. Frequently the program just runs wild, executing
   practically random instructions. Your carefully saved data or
   meticulously protected I/O could be destroyed by rogue instructions!

   No power fail circuit is complete unless it clamps the reset line
   whenever power is less than the magic 4.75 volt level. A suitable
   circuit keeps the CPU in a reset state, preventing wild execution from
   corrupting the efforts of the NMI power save routine. Motorola sells a
   3-terminal reset controller for less than a dollar which will hold
   reset down in low Vcc conditions.

   Consider another case: suppose the power grid's sadly overload
   summertime generating capacity experiences a brownout. If the line
   drops from 110 VAC to, say, 80 volts, what happens to the +5 volt
   output from your system's power supply? Most likely it will go out of
   regulation, giving perhaps 3 or 4 volts until the 110 input level is
   reestablished. Hopefully the power fail circuit will assert an NMI to
   the processor chip. Using the conventional resistor/capacitor unclamped
   reset circuit, the reset input will decline only to the 3-4 volt level,
   not nearly low enough to force a reset when power comes back.

   The reset clamping circuit will not only keep the CPU in a safe state;
   in this brownout case it will also insure that the system restarts
   properly when +5 volts is reestablished.

   Regardless, NMI is the only reasonable interrupt choice for power fail
   detection.

NMI Abuse

   Unfortunately, NMI is widely abused as a general purpose interrupt. Use
   NMI only for events that occur infrequently. Never substitute it for
   poor design.

   It's not too unusual to see a divider circuit driving NMI, generating
   hundreds or thousands of interrupts per seconds. Usually these designs
   start life using a reasonable maskable interrupt. As the programmers
   debug the system they find the CPU occasionally misses an interrupt, so
   they switch over to NMI. This is a mistake. If the code misses
   interrupts, there is a fundamental flaw in its design that NMI will not
   cure.

   Your code will miss interrupts only if some bottleneck keeps them
   disabled for too long. Always design the code to keep interrupts
   disabled only while servicing the hardware. Reenable them as soon as
   possible. With good reentrant design, interrupts should never be off
   for more than a few tens of microseconds.

On the Edge

   Quite a few processors implement NMI as an edge sensitive interrupt.
   This guarantees that even a breathtakingly short pulse will set the
   CPU's internal NMI flip flop, so the interrupt simply cannot be missed.
   It might, however, cause several kinds of nasty problems.

   Suppose the input comes from the real world, perhaps after having been
   transmitted a few feet. Without proper pulse shaping circuitry, the
   signal could easily have ragged edges or even multiple, closely spaced
   transitions. Maskable interrupts live quite happily with short bouncing
   on their lines, since the first transition will make the processor
   disable the input and start the ISR. Even the fastest code will take a
   few microseconds to service and reenable the interrupt, by which time
   the transients will be long gone. NMI cannot be disabled; every bit of
   bounce will reinitiate the NMI service routine. The result: one real
   interrupt might masquerade as several independent NMIs, each one
   pushing onto the stack and recalling the ISR.

   Edge sensitive inputs respond when the input voltage crosses some
   threshold. Imperfect digital circuits give a rather broad window to the
   threshold. If the NMI input signal is perfectly clean but moves slowly
   from the idle to the asserted state, it stays within the threshold
   region for far too long, sometimes causing multiple NMI triggers.

   Finally, the edge sensitive nature of the NMI signal renders it
   susceptible to every stray bit of electrical noise. A clean NMI driven
   by a gate on the other side of a circuit board might pick up unexpected
   noise from other parts of the circuit.

   Edge sensitive NMI inputs must be clean, noise free, and should switch
   quickly and cleanly.

   Remember that debugging NMI service routines is sometimes tough. How
   will you single step in an NMI service routine if, while debugging,
   dozens more NMIs keep coming? Most of us debug code by stopping at a
   breakpoint and looking at the registers and variables. If, when
   debugging the NMI handler, another comes along while we're stopped,
   after resuming execution the service routine will re-invoke itself,
   probably corrupting a non-reentrant value.

   In summary, NMI is a valuable feature. Don't abuse it; restrict its use
   to those few situations where only an NMI will solve a problem.

   Do you need to eliminate bugs in your firmware? Shorten schedules? My
   [77]Better Firmware Faster seminar will teach your team how to operate
   at a world-class level, producing code with far fewer bugs in less
   time. It's fast-paced, fun, and covers the unique issues faced by
   embedded developers. [78]Here's information about how this class,
   taught at your facility, will measurably improve your team's
   effectiveness.

   Free Embedded Muse newsletter - twice/monthly, hard-hitting technical
   info that goes to 40,000+ engineers. Click [79]here to sign up or enter
   your email here:
   ____________________ Submit

   Latest [80]Embedded Muse: Replies to 'Is Assembly Dead' and 'on Taking
   Charge'.

   Latest [81]blog: Is a heart rate of 72,123 beats per minute possible?

   [82][ganssle-dot-com-ad.jpg] Advertise with us! Reach 200K embedded
   developers per month. More info [83]here.
     __________________________________________________________________

   The Ganssle Group - [84]info@ganssle.com - copyright TGG, all rights
   reserved. Contact info [85]here.

References

   1. http://www.ganssle.com/
   2. http://www.ganssle.com/
   3. http://www.ganssle.com/navigation.html
   4. http://www.ganssle.com/onsite.htm
   5. http://www.ganssle.com/classes.htm
   6. http://www.ganssle.com/onsite.htm
   7. http://www.ganssle.com/tem-subunsub.html
   8. http://www.ganssle.com/tem-subunsub.html
   9. http://www.ganssle.com/tem-back.htm
  10. http://www.ganssle.com/expertwitness.html
  11. http://www.ganssle.com/blog/index.html
  12. http://www.ganssle.com/video/video-list.html
  13. http://www.ganssle.com/tools.htm
  14. http://www.ganssle.com/tools.htm
  15. http://www.ganssle.com/book.htm
  16. http://www.ganssle.com/bkreviews.htm
  17. http://www.ganssle.com/spcl_reports.htm
  18. http://www.ganssle.com/reports/ultra-low-power-design.html
  19. http://www.ganssle.com/item/perils-of-scope-probes.html
  20. http://www.ganssle.com/salsurv2020.html
  21. http://www.ganssle.com/item/debouncing-switches-contacts-code.htm
  22. http://www.ganssle.com/item/great-watchdog-timers.htm
  23. http://www.ganssle.com/item/history-of-the-microprocessor.html
  24. http://www.ganssle.com/item/becoming-a-consultant.htm
  25. http://www.ganssle.com/misc/wom.html
  26. http://www.ganssle.com/item/guide-to-managing-firmware-teams.htm
  27. http://www.ganssle.com/item/writing-great-comments-firmware.htm
  28. http://www.ganssle.com/item/how-to-test-ram.htm
  29. http://www.ganssle.com/item/becoming-an-embedded-developer.htm
  30. http://www.ganssle.com/inspections.htm
  31. http://www.ganssle.com/item/automatically-debugging-firmware.htm
  32. http://www.ganssle.com/item/instrumenting-firmware-for-debugging.htm
  33. http://www.ganssle.com/item/approximations-for-trig-c-code.htm
  34. http://www.ganssle.com/item/approximations-c-code-exponentiation-log.htm
  35. http://www.ganssle.com/item/creating-great-resumes.htm
  36. http://www.ganssle.com/articles-subj.htm
  37. http://www.ganssle.com/articles.htm
  38. http://www.ganssle.com/articles-subj.htm
  39. http://www.ganssle.com/articles-subj.htm#Communications
  40. http://www.ganssle.com/articles-subj.htm#Debugging
  41. http://www.ganssle.com/articles-subj.htm#Fun
  42. http://www.ganssle.com/articles-subj.htm#Hardware
  43. http://www.ganssle.com/articles-subj.htm#Historical
  44. http://www.ganssle.com/articles-subj.htm#Managing
  45. http://www.ganssle.com/articles-subj.htm#Math
  46. http://www.ganssle.com/articles-subj.htm#Memory
  47. http://www.ganssle.com/articles-subj.htm#Philosophical
  48. http://www.ganssle.com/articles-subj.htm#realtime
  49. http://www.ganssle.com/articles-subj.htm#Processes
  50. http://www.ganssle.com/articles-subj.htm#Tools
  51. http://www.ganssle.com/jack/
  52. http://www.ganssle.com/randomrants.htm
  53. http://www.ganssle.com/randomrants.htm#electronics
  54. http://www.ganssle.com/randomrants.htm#business
  55. http://www.ganssle.com/randomrants.htm#softwareengineering
  56. http://www.ganssle.com/randomrants.htm#products
  57. http://www.ganssle.com/randomrants.htm#philosophy
  58. http://www.ganssle.com/randomrants.htm#misc
  59. http://www.ganssle.com/randomrants.htm#history
  60. http://www.ganssle.com/randomrants.htm#software
  61. http://www.ganssle.com/randomrants.htm#random
  62. http://www.ganssle.com/randomrants.htm#fun
  63. http://www.ganssle.com/randomrants.htm#realtime
  64. http://www.ganssle.com/jokes.htm
  65. http://www.ganssle.com/contact.htm
  66. http://www.ganssle.com/contact.htm
  67. http://www.ganssle.com/advertise.html
  68. http://www.ganssle.com/search/search.html
  69. http://www.ganssle.com/bio.htm
  70. http://www.ganssle.com/expertwitness.html
  71. http://www.ganssle.com/privacy-policy.html
  72. http://www.ganssle.com/tem-subunsub.html
  73. http://www.ganssle.com/tem-subunsub.html
  74. http://www.ganssle.com/tem/tem406.html#article4
  75. http://www.ganssle.com/contest.html
  76. http://www.ganssle.com/articles/aintrp.htm
  77. http://www.ganssle.com/onsite.htm
  78. http://www.ganssle.com/onsite.htm
  79. http://www.ganssle.com/tem-subunsub.html
  80. http://www.ganssle.com/tem/tem407.html
  81. http://www.ganssle.com/blog/blog/heart-rate.html
  82. http://www.ganssle.com/advertise.html
  83. http://www.ganssle.com/advertise.html
  84. mailto:info@ganssle.com
  85. http://www.ganssle.com/contact.htm