Early Morning Amnesia

This is the result from my work from the Ultimate RoadTest. A road test that was sponsored by element14 and Texas Instruments.

Read on to find out why it is here.

 

 

Unlike what the deer says the Energy Harvesting Solution To Go RoadTest Challenge is sponsored by Würth Elektronik, element 14, Energy Micro and Linear Technology.

 

 

The EFM32 offers five power modes. These are described in many document including page 4 of http://cdn.energymicro.com/dl/pdf/efm32_introduction_white_paper.pdf.

 

Power Mode NameDescription
EM0Run
EM1Sleep
EM2Deep Sleep
EM3Stop
EM4Shutoff

 

For modes EM0 through EM3, the EFM's RAM remains intact. However for EM4 the RAM contents are lost.

 

For my projects, I will work on the assumption that they will reach a run out of power state.

When these projects are woken up from such a state they will need to know their previous state in order to resume operation.

The best way to do this is to have them know their state prior to running out of power.

The easiest way to do this is;

  • To use non-volatile RAM that contains the projects' current state
  • a mechanism to ensure that the contents of this RAM are valid
  • a mechanism to ensure that the project has successfully changed from one state to another.

 

I'm no stranger to this technology. About 30 years ago I worked on a Home Computer System that had battery backed non-volatile memory that could resume operation when power was restored.

Some 30 years later and that technique is still perfectly valid.

 

These techniques are equivalent to the techniques used for synchronous storage replication and transaction based computing.

 

The issue with the EFM32 is that it does not have any non-volatile RAM.

To address this  Energy Micro have produced an application note that allows Flash RAM to emulate EEPROM.

http://downloads.energymicro.com/an/pdf/an0019_efm32_eeprom_emulation.pdf

 

But I think this approach is unsuitable for my projects because;

  • it is far complex for simple products
  • the speed of this complex procedure could affect operation and performance
  • the number of writes in the products' life time could exceed the number of rewrites available from the Flash RAM and stop operation prematurely.

 

To accomplish this function I will need to resort to an additional device.

 

The device selection

I could use the non-volatile RAM (and required battery) from 30 years ago but its size is too big and its parallel interface and pin count is inappropriate for this application.

Instead of Flash RAM I could use EEPROM but its power requirements, speed and (and maybe its rewriteability lifetime) may hinder operation.

It is not uncommon that FLASH and EEPROM to use internal voltage pumps to generate the voltage to rewrite their memory cells. This increases their power consumption.

 

What I will use is an Ferroelectric RAM aka FRAM or FeRAM.

These devices are available from element14;

    http://au.element14.com/jsp/search/browse.jsp?N=2101+203669&Ntk=gensearch&Ntt=FM24C&Ntx=mode+matchallpartial

    http://au.element14.com/jsp/search/browse.jsp?N=2101+203669&Ntk=gensearch&Ntt=FM25C&Ntx=mode+matchallpartial

 

This type of RAM is small, low power and depending upon the type have up to 10 ^14 accesses (that is a million times more than the number of rewrite cycles of an EEPROM).

 

The EFM32 operates at around 3 or so volts so I will use an 3 volt FRAM.

The lowest power FRAM currently available only requires a maximum current of 300uA for a rewrite.

I don't have one of these lying around so I will use a FM25V05 (512K bits arranged as 64K x 8). This is a SPI device and uses up to 3mA fo a rewrite.

It's overkill but should do the job admirably.

I can use its extra capacity and performance to store bit mapped images for the e-paper.

It also has some extra features such as the ability to read out its Manufacturing ID and Part ID.

The VN version also includes a unique readable Serial Number.

 

I'm no stranger to high speed SPI Serial RAM. I have used it for several previous projects including my WiFi/Internet Talking deer on a SUV (as per the attached video) where FRAM was used for program strage and Serial Static RAM was used as additional storage for a voice buffer.

It is to give you an idea of the performance possible from such devices.