eCos Support for AMD AM29xxxxx Flash Devices and Compatibles — Overview
AM29xxxxx V2 flash driver package implements support for the AM29xxxxx
family of flash devices and compatibles. Normally the driver is not
accessed directly. Instead application code will use the API provided
by the generic flash driver package
CYGPKG_IO_FLASH, for example by calling functions
The driver imposes one restriction on application code which developers should be aware of: when programming the flash the destination addresses must be aligned to a bus boundary. For example if the target hardware has a single flash device attached to a 16-bit bus then program operations must involve a multiple of 16-bit values aligned to a 16-bit boundary. Note that it is the bus width that matters, not the device width. If the target hardware has two 16-bit devices attached to a 32-bit bus then program operations must still be aligned to a 32-bit boundary, even though in theory a 16-bit boundary would suffice. In practice this is rarely an issue, and requiring the larger boundary greatly simplifies the code and improves performance.
Many eCos targets with AM29xxxxx or compatible flash devices will
still use the older driver package
The AM29xxxxx flash driver package will be loaded automatically when
configuring eCos for a target with suitable hardware. However the
driver will be inactive unless the generic flash package
CYGPKG_IO_FLASH is loaded. It may be necessary to
add this generic package to the configuration explicitly before the
driver functionality becomes available. There should never be any need
to load or unload the AM29xxxx driver package.
The driver contains a small number of configuration options which
application developers may wish to tweak.
controls the program operation. On typical hardware programming the
flash requires disabling interrupts and the cache for an extended
period of time. Some or all of the flash hardware will be unusable
while each word is programmed, and disabling interrupts is the only
reliable way of ensuring that no interrupt handler or other thread
will try to access the flash in the middle of an operation. This can
have a major impact on the real-time responsiveness of the typical
applications. To ameliorate this the driver wil perform writes in
small bursts, briefly re-enabling the cache and interrupts between
each burst. The number of words written per burst is controlled by
this configuration operation: reducing the value will improve
real-time response but will add overhead, so the actual flash program
operation will take longer; conversely more writes per burst will
worsen response times but reduce overhead.
Similarly erasing a block of flash safely requires disabling
interrupts and the cache. Erasing a block can easily take a second or
so, and disabling interrupts for such a long period of time is usually
undesirable. Hence the driver can also perform the erase in bursts,
using the hardware's suspend and resume capabilities.
controls the number of polling loops during which interrupts are
disabled. Reducing its value improves responsiveness at the cost of
performance, and increasing its value has the opposite effect. Note
that too low a value may prevent the erase operation from working at
all: the chip will be spending its time suspending and resuming,
rather than actually performing the erase. The minimum value will
depend on the specific hardware.
There are a number of other options, relating mostly to hardware
characteristics. It is very rare that application developers need to
change any of these. For example the option
may need a non-default value if the flash devices used on the target
have an unusual boot block layout. If so the platform HAL will impose
a requires constraint on this option and the configuration system will
resolve the constraint. The only time it might be necessary to change
the value manually is if the actual board being used is a variant of
the one supported by the platform HAL and uses a different flash chip.
|2019-03-19||Open Publication License|