30°C Power On 12 to 36 watts - for fanless sealed system design ...

ESE Magazine Jan/Feb 06
48
Flash storage solutions for
microcontrollers
Dave Hughes, HCC-Embedded
Flash memory provides many advantages, but designers
need to take care to extract these benefits.
IN RECENT YEARS flash based
microcontrollers have flooded the market
from all the major players – they are now
the norm rather than the exception.
Additionally the arrival of ever larger serial flash
devices with small erasable sectors has given
the possibility of extending the storage capabilities
of micros without the requirement for additional
resources.
Many new applications immediately suggest
themselves, such as field customisation, field
upgrades, dynamic configuration files, data logging,
diagnostics and more.
But can this flash be used as more than a
masked ROM substitute? Can the flash be used
reliably for these new applications? We are paying
for the more sophisticated flash solution –
but how do we extract the benefits?
Flash basics
Firstly we need to look at the issues: All flash is
different – the specifications for each device
used must be studied to get reliable results from
a flash device. It is hard to find two devices from
different product families which have identical
flash characteristics but there are some basic
features which are common to most:
● Can only write down i.e. 1’s to 0’s
● Must Erase in Blocks to set bits back to 1.
● Write in pages or Bytes depending on flash
type
● Some devices write to RAM buffer and erase
the page before writing
● Some flash types may need refreshing to
prevent bit flipping
● Some devices have cumulative write time
limits before a refresh must be done
● All devices have a typical Erase/write Cycle
limitation before errors develop
● Wear-levelling is a useful process to counter
this limitations
● Unexpected reset problem – both in write
and erase operations – if a write or erase is
broken then the results in the page are
unpredictable and it is necessary to be sure
whether a page is valid or not.
● Power Management – all flash is sensitive
to unstable voltages – if the power drops
below the specified level then erase and
write operations will have unpredictable
results.
It is this collection of characteristics on flash
devices which creates the challenge – how to
use this flash reliably?
Use a file system
These problems are quite complex to address
and there are different rules for every flash
device type which have to be taken in to consideration
in any design. One method to hide all
this complexity from the developer is to use a
file system – specifically designed for the target
flash – which means the developer can access
the flash thorough standard API calls and can
forget about the details of what happens underneath.
Using a file system has many benefits. Data
becomes position independent, this is managed
by the file system. There is a standard interface
to data which makes for easy porting and testing
across a range of platforms if necessary. And
finally, as the the flash technology is hidden
from the designer they are free to focus on their
core competences.
Connecting to a host
The “standard route” for connecting embedded
file systems to a host system would be to add a
USB Mass Storage interface and a FAT file system
but there are some disadvantages to this
approach for embedded systems developers. As
the FAT file system is not fail safe there needs to
be a check disk available. While this acceptable
when a device is connected to the PC, what happens
when it is in the field? FAT is space hungry,
requiring a minimum of 20K disk space before
storing data, which can be a significant overhead
for many flash micros. When the host accesses
the file system the target must stop access and
vice versa, as either system can modify the FAT
But can flash be used as more than a masked ROM substitute? Can it be used
reliably for new applications? We are paying for the more sophisticated flash
solution – but how do we extract the benefits?
Figure 1: uCDrive.
structures, however there is no way to inform the
host that the target has made changes or vice
versa. There are no security options on a FAT system.
And, what can be a major factor, USB can be
relatively expensive to design in.
Another possibility is to provide specialized
host drivers which interface to the embedded
device in much the same way as NFS works – the
file system is managed on the target in a reliable
way – all systems access it through API calls. A
virtual drive can then be created on the host system
to give the user seamless drag and drop, double
click access to the targets file system. HCC-
Embedded specialises in small footprint, reliable,
file systems designed for a variety of different
flash devices both using internal microcontroller
flash and externally connected small sector flash.
The uCDrive system provides this connectivity
through a serial port, and HCC will soon be providing
USB connectivity. Your embedded system
then truly appears as a standard drive .
www.hcc-embedded.com