Forums

Production programming of battery-backed SRAM

Started by Clive Wilson April 7, 2004
Dear All,

I'm not sure if what I'm about to propose is achievable, won't work, or just
plain wacky.

I'm attempting to design an ARM7-based system which has no Flash, on-chip or
off. There is a requirement to have NVRAM, i.e. battery-backed. So I'm thinking,
can I manage with only the NVRAM?

One major concern of mine is how to initially insert the run-time code in the
NVRAM in the first place. Can I use a cheap JTAG wiggler-style programmer? If so
would the NVRAM take kindly to having the JTAG removed from it whilst powered
up? Secondly, what about field reprogramming? I figure we could handle this OK,
jumping to a boot routine elsewhere in the NVRAM, which will then rewrite the
app code area, then jump back to this area and start-up again.

Has anyone here tried doing this kind of thing before, or should I just go with
the flow and add a Flash device to the system?

Your ideas and comments would be gratefully received.

Kind regards,

Clive Wilson


On Wed, 7 Apr 2004 19:06:07 +0100, "Clive Wilson" <cwilson@spinnakerinternational.com> wrote:

>Dear All, > >I'm not sure if what I'm about to propose is achievable, won't work, or just >plain wacky. > >I'm attempting to design an ARM7-based system which has no Flash, on-chip or >off. There is a requirement to have NVRAM, i.e. battery-backed. So I'm thinking, >can I manage with only the NVRAM? > >One major concern of mine is how to initially insert the run-time code in the >NVRAM in the first place. Can I use a cheap JTAG wiggler-style programmer? If so >would the NVRAM take kindly to having the JTAG removed from it whilst powered >up? Secondly, what about field reprogramming? I figure we could handle this OK, >jumping to a boot routine elsewhere in the NVRAM, which will then rewrite the >app code area, then jump back to this area and start-up again. > >Has anyone here tried doing this kind of thing before, or should I just go with >the flow and add a Flash device to the system? > >Your ideas and comments would be gratefully received. > >Kind regards, > >Clive Wilson >
Relying on SRAM is pretty risky - much less resilient to glitches, ESD, CPU crashes etc., and of course there is the issue of the battery running out. I wouldn't do it unless there are exceptionally good reasons (e.g. space). Instead of programming the RAM, another approach is to provide for temporary connection of a ROM containing a bootloader, which copies itself to RAM. I did this many years ago on an 8-bit system (private project, not for production), where the system was 'jumpstarted' using a 32 pin DIL testclip which was clipped over the SRAM chip. Obviously a 32 bit system poses more of an interconnection challenge, but not impossible. For If all you need is NV memory, use a serial eeprom - smaller, cheaper. Flash is not expensive - I think having some 'permanent' boot code will save you grief in the long run, even if it just contains a bootloader to load SRAM from an external source or serial eeprom etc.
"Clive Wilson" <cwilson@spinnakerinternational.com> wrote in message news:<o-KdnaKT2dqB3und4p2dnA@giganews.com>...
> Dear All, > > I'm not sure if what I'm about to propose is achievable, won't work, or just > plain wacky. > > I'm attempting to design an ARM7-based system which has no Flash, on-chip or > off. There is a requirement to have NVRAM, i.e. battery-backed. So I'm thinking, > can I manage with only the NVRAM? > > One major concern of mine is how to initially insert the run-time code in the > NVRAM in the first place. Can I use a cheap JTAG wiggler-style programmer? If so > would the NVRAM take kindly to having the JTAG removed from it whilst powered > up? Secondly, what about field reprogramming? I figure we could handle this OK, > jumping to a boot routine elsewhere in the NVRAM, which will then rewrite the > app code area, then jump back to this area and start-up again. > > Has anyone here tried doing this kind of thing before, or should I just go with > the flow and add a Flash device to the system? > > Your ideas and comments would be gratefully received. > > Kind regards, > > Clive Wilson
In 1980 I worked on an embedded device that had two K of SRAM, one K was used as a ROM by being backed up by a battery and having write_enable fixed at the supply voltage. We put a lot of those devices in the field and never had any problems with using NV SRAM as ROM. The way we programmed it was to pull out the 1802 micro and connect a jumper to the socket from another 1802 computer which could then write to the NV SRAM on the target board. We then replaced the processor and shipped the board. However that was 24 years ago and today I think that a FLASH option would probably be a better choice. Best Wishes
Clive Wilson wrote:
> Dear All, > > I'm not sure if what I'm about to propose is achievable, won't work, or just > plain wacky. > > I'm attempting to design an ARM7-based system which has no Flash, on-chip or > off. There is a requirement to have NVRAM, i.e. battery-backed. So I'm thinking, > can I manage with only the NVRAM? > > One major concern of mine is how to initially insert the run-time code in the > NVRAM in the first place. Can I use a cheap JTAG wiggler-style programmer? If so > would the NVRAM take kindly to having the JTAG removed from it whilst powered > up? Secondly, what about field reprogramming? I figure we could handle this OK, > jumping to a boot routine elsewhere in the NVRAM, which will then rewrite the > app code area, then jump back to this area and start-up again. > > Has anyone here tried doing this kind of thing before, or should I just go with > the flow and add a Flash device to the system? > > Your ideas and comments would be gratefully received.
Many ARMs include small BOOT ROMS, to allow boot from Serial Memory. Serial FLASH is getting very cheap on a $/MByte and also sq mm basis. Battery back of ALL your SRAM will likely have Icc/Speed trade offs. ( Viz RAM : Fast <> Lowpower, BIG <> low Power ). That suggests a big/fast SRAM, and a smaller NV solution. I'd take a close look at the new MRAM parts (Cypress,Motorola), and also FRAM devices from Ramtron - then you can ditch the battery entirely, and have enough space for the first loader stub. These technologies also have no write delays. -jg
On Wed, 7 Apr 2004 19:06:07 +0100, the renowned "Clive Wilson"
<cwilson@spinnakerinternational.com> wrote:

>Dear All, > >I'm not sure if what I'm about to propose is achievable, won't work, or just >plain wacky. > >I'm attempting to design an ARM7-based system which has no Flash, on-chip or >off. There is a requirement to have NVRAM, i.e. battery-backed. So I'm thinking, >can I manage with only the NVRAM? > >One major concern of mine is how to initially insert the run-time code in the >NVRAM in the first place. Can I use a cheap JTAG wiggler-style programmer? If so >would the NVRAM take kindly to having the JTAG removed from it whilst powered >up? Secondly, what about field reprogramming? I figure we could handle this OK, >jumping to a boot routine elsewhere in the NVRAM, which will then rewrite the >app code area, then jump back to this area and start-up again. > >Has anyone here tried doing this kind of thing before, or should I just go with >the flow and add a Flash device to the system? > >Your ideas and comments would be gratefully received. > >Kind regards, > >Clive Wilson
That's wacky unless you just want it to work on a bench in the next room. One corrupt bit and your system goes down forever, until someone services it. Do you really want that? Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
> One major concern of mine is how to initially insert the run-time code in the > NVRAM in the first place. Can I use a cheap JTAG wiggler-style programmer?
Yes, you can. It's easier than flash programming, in fact, because there's less setup. Provided you keep the RAM chip unselected while depowering the circuit, and you ensure that the RAM backup battery can't energize anything else, there should be no problem when you disconnect JTAG.
> Has anyone here tried doing this kind of thing before, or should I just go with > the flow and add a Flash device to the system?
This sort of technique has been used for security purposes in crypto hardware and arcade game machines (Pang, for instance, has vital data in battery-backed SRAM. And many of Sega's System 16 arcade games - Alien Syndrome, Golden Axe [some versions], Bay-Route, etc - used a main CPU which was a custom Hitachi 68000 with battery and SRAM on a crypto array wrapped around the core (big fat plastic DIP68). Some of them used a similarly modified Z80 for the audio CPU). Everything is fine until there's a glitch, or the battery dies. Then the hardware becomes junk. This is an evil, evil way of doing things. You will burn in hell, or at least smoulder in heck, if you attempt it.
"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> schreef in bericht
news:5u1970dtc9p2ti1njm442ofdrkohjao36h@4ax.com...
> > That's wacky unless you just want it to work on a bench in the next > room. One corrupt bit and your system goes down forever, until someone > services it. Do you really want that?
Going down forever wouldn't be so bad. The chances that it goes 'funny' are much greater ;) -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
On Thu, 8 Apr 2004 09:54:14 +0200, the renowned "Frank Bemelman"
<f.bemelmanx@planet.invalid.nl> wrote:

>"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> schreef in bericht >news:5u1970dtc9p2ti1njm442ofdrkohjao36h@4ax.com... >> >> That's wacky unless you just want it to work on a bench in the next >> room. One corrupt bit and your system goes down forever, until someone >> services it. Do you really want that? > >Going down forever wouldn't be so bad. The chances that it goes >'funny' are much greater ;)
If it limps to life it (maybe) can check itself and fix itself from a SEEPROM backup or with error-correction code, but without that, sure. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com