1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Production programming of battery-backed SRAM

Discussion in 'Embedded' started by Clive Wilson, Apr 7, 2004.

  1. Clive Wilson

    Clive Wilson Guest

    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
    Clive Wilson, Apr 7, 2004
    #1
    1. Advertising

  2. 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.
    Mike Harrison, Apr 7, 2004
    #2
    1. Advertising

  3. Clive Wilson

    Jeff Fox Guest

    "Clive Wilson" <> wrote in message news:<>...
    > 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
    Jeff Fox, Apr 7, 2004
    #3
  4. 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
    Jim Granville, Apr 7, 2004
    #4
  5. 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
    Spehro Pefhany, Apr 7, 2004
    #5
  6. > 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.
    Lewin A.R.W. Edwards, Apr 8, 2004
    #6
  7. Clive Wilson

    Gary Kato Guest

    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.
    Gary Kato, Apr 8, 2004
    #7
  8. "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)
    Frank Bemelman, Apr 8, 2004
    #8
  9. 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
    Spehro Pefhany, Apr 8, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nick
    Replies:
    0
    Views:
    301
  2. Rubén Ruiz
    Replies:
    0
    Views:
    341
    Rubén Ruiz
    Jul 26, 2004
  3. Rub?n Ruiz
    Replies:
    0
    Views:
    335
    Rub?n Ruiz
    Jan 24, 2005
  4. Replies:
    3
    Views:
    272
    GMM50
    Nov 1, 2005
  5. Mark
    Replies:
    2
    Views:
    422
Loading...

Share This Page