Bob's Blog #10: Memory

Let’s take a stroll down Random Access Memory Lane to see how controller memory evolved over the years.


We begin in 1976. Our first repeater controller was a 6800-based microcomputer with just 2K of Static Random-Access Memory (SRAM) for the program and its data. Not only was it insufficient for an expanding program, but also it was volatile – everything in memory disappeared when power failed. After every power glitch, we had to grab a punched paper tape, put it in the Teletype machine, and wait for its contents to be uploaded to the PC. Fortunately, the repeater wasn’t far away. But still, the disadvantages of this scheme were obvious: Besides having to reload the software frequently, any DTMF-entered data wasn’t on the tape and was lost. Further, we had to punch a new backup tape every time we upgraded the program.


The next controller was a homebrew wirewrap job. We put the program, the macros, and most of the other data in Erasable Programmable Read-Only Memory (EPROM). EPROM is nonvolatile by nature, but it has other drawbacks: To modify the contents, you must pull the EPROM from its socket, erase it with ultraviolet light for 20 minutes, reprogram it, and then reinstall it. The processor did have a small amount of volatile RAM (128 bytes), and we used it to store a few DTMF-entered variables and two macros for experimental purposes.

It was those RAM-based macros that made us realize how important it was to have a large quantity of memory that was both remotely changeable and nonvolatile. We could leave the repeater operating system program in EPROM as we could save up the changes and then release them as software upgrades. But DTMF-entered data such as timer values, messages, and macros needed to be stored in nonvolatile RAM; we decided that controllers couldn’t be flexible and remotely programmable without it.

Other controller manufacturers went in other directions. Some controllers of the day weren’t highly programmable and stored data in whatever volatile on-chip RAM came with the processor. The entire controller needed to be battery-backed if settings were to be saved during outages.

Others used Electrically Erasable Programmable ROM (EEPROM), and later, flash memory (flash behaves a lot like EEPROM but requires the data to be written in blocks).

EEPROM and flash can be erased and reprogrammed in-circuit. But they both exhibit a “wear out” characteristic that shows up after a limited number of write cycles is exceeded. They also require a long time to erase and rewrite, which led controller manufacturers to create the concept of ‘unlocking’ the controller to make changes and ‘locking’ it when finished.

We chose Battery-Backed SRAM (BBSRAM). It’s nonvolatile, allows unlimited read and write cycles at full speed, and makes self-modifying macros and other on-the-fly features possible that can’t be done with lock/unlock schemes.


BBSRAM is implemented with asynchronous SRAM, sometimes called low-power SRAM. An SRAM is placed into data retention mode by lowering the supply voltage to 2 V and stopping all reading and writing. The current draw drops from dozens of milliamps to just a few microamps. The microamp current drain and the low retention voltage mean data can be retained with just one or two small batteries.

But designing such a system was a challenge at the time. Why?

• A microprocessor can misbehave and write erroneous data to SRAM while its power supply is out of tolerance. To combat the problem, specially-designed reset circuits operate at low voltage and keep the processor reset line low during power-down and power-up sequences.

• We added a watchdog timer. It’s a missing-pulse detector that resets the processor if a software routine fails to send it a pulse periodically. The idea is to restart the program if the processor gets hung up due to a hardware glitch or software fault.

• A BBSRAM power supply must be able to switch back and forth between the +5 V supply and the battery without any glitches.

• To maximize battery life, the battery must power only the SRAM and not everything to which it is connected. And, none of the pins on the SRAM can float.

• Finally, the battery, being a primary cell, must not receive any charging current from the +5 V supply.

All those things were accomplished with resistors, capacitors, zener diodes, Schottky diodes, transistors, and 555 timers. The next few wirewrapped boards, the Big Board, and the MRC-100 contained circuits of that type.

Then… help arrived in the form of two ICs from Dallas Semiconductor. The DS1232 MicroMonitor monitored the power supply and generated the necessary reset signal; it also contained a watchdog circuit. The DS1210 Nonvolatile Controller handled the battery switchover task. These ICs made BBSRAM design relatively simple, and we used them in the 5K, 6K, and 7K initially.


In version 2 of those products, the DS1210 and the RAM were replaced by a DS1643 or DS1644 Nonvolatile Timekeeping RAM module. The modules contain a real-time clock, crystal, low-power SRAM, power control circuit, and lithium coin cell.

The DS modules weren’t attractive when it came to the 7330 because we wanted far more RAM plus a Temperature Controlled Crystal Oscillator (TCXO) for the real-time clock. We ended up using a DS1670 System Monitor, a DS32KHZ TCXO, and a 512K SRAM. (The 7330 also has two 8M serial flash ICs for the operating system and audio storage.)

Since the 7330 was designed, new types of nonvolatile memory technologies have matured. There’s FRAM (Ferroelectric RAM), MRAM (Magnetoresistive RAM), PCM (Phase-Change Memory), ReRAM (Resistive RAM), and others. It’ll be interesting to see which technology comes closest to the ideal memory for new embedded processor system designs. We will be looking for one that is fast, nonvolatile, has unlimited read and write cycles, and requires no backup power.


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer