Motherboard Forums


Reply
Thread Tools Display Modes

Production programming of battery-backed SRAM

 
 
Clive Wilson
Guest
Posts: n/a
 
      04-07-2004, 06:06 PM
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


 
Reply With Quote
 
 
 
 
Mike Harrison
Guest
Posts: n/a
 
      04-07-2004, 06:47 PM
On Wed, 7 Apr 2004 19:06:07 +0100, "Clive Wilson" <(E-Mail Removed)> 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.





 
Reply With Quote
 
 
 
 
Jeff Fox
Guest
Posts: n/a
 
      04-07-2004, 09:13 PM
"Clive Wilson" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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
 
Reply With Quote
 
Jim Granville
Guest
Posts: n/a
 
      04-07-2004, 10:17 PM
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

 
Reply With Quote
 
Spehro Pefhany
Guest
Posts: n/a
 
      04-07-2004, 10:51 PM
On Wed, 7 Apr 2004 19:06:07 +0100, the renowned "Clive Wilson"
<(E-Mail Removed)> 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"
(E-Mail Removed) Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
 
Reply With Quote
 
Lewin A.R.W. Edwards
Guest
Posts: n/a
 
      04-07-2004, 11:18 PM
> 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.
 
Reply With Quote
 
Gary Kato
Guest
Posts: n/a
 
      04-08-2004, 01:04 AM
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.
 
Reply With Quote
 
Frank Bemelman
Guest
Posts: n/a
 
      04-08-2004, 07:54 AM
"Spehro Pefhany" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
>
> 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)


 
Reply With Quote
 
Spehro Pefhany
Guest
Posts: n/a
 
      04-08-2004, 12:38 PM
On Thu, 8 Apr 2004 09:54:14 +0200, the renowned "Frank Bemelman"
<(E-Mail Removed)> wrote:

>"Spehro Pefhany" <(E-Mail Removed)> schreef in bericht
>news:(E-Mail Removed).. .
>>
>> 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"
(E-Mail Removed) Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Production Programming of Flash for FPGAs and MCUs rickman Embedded 15 11-24-2011 08:30 PM
cortex programming in production colin_toogood@yahoo.com Embedded 4 03-03-2008 11:02 AM
Interfacing AT91SAM9260 with cheap SRAM or SRAM? Mark Embedded 2 10-26-2006 08:50 AM
CFP: SECOND CALL FOR PAPERS. Special Issue: Operational Control of Wafer Production. Production Planning & Control International Journal Rub?n Ruiz Embedded 0 01-24-2005 03:34 PM
CALL FOR PAPERS. Special Issue: Operational Control of Wafer Production. Production Planning & Control International Journal Rubén Ruiz Embedded 0 07-26-2004 03:04 PM


All times are GMT. The time now is 10:11 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment