Production programming of battery-backed SRAM

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" <> 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" <> wrote in message news:<o->...
> 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"
<> 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"
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.

Universal Electronics One-For-All remotes used to have their code and IR
library in one battery-backed SRAM. I worked on a product that used it, but we
had to open them up to solder some wires here and there inside. All it took was
one short and we'd end up with a nice brain-dead remote. The company was very
very happy once they switched to using non-battery backed NVM.

"Spehro Pefhany" <> schreef in bericht
news:...
>
> 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"
<> wrote:

>"Spehro Pefhany" <> schreef in bericht
>news:.. .
>>
>> 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"
Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com