Description

The CYGPKG_DEVS_FLASH_AMD_AM29XXXXX_V2 AMD 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 like cyg_flash_program.

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.

	Note
	Many eCos targets with AM29xxxxx or compatible flash devices will still use the older driver package CYGPKG_DEVS_FLASH_AMD_AM29XXXXX. Only newer ports and some older ports that have been converted will use the V2 driver. This documentation only applies to the V2 driver.

Configuration Options

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. CYGNUM_DEVS_FLASH_AMD_AM29XXXXX_V2_PROGRAM_BURST_SIZE 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. CYGNUM_DEVS_FLASH_AM29XXXXX_V2_ERASE_BURST_DURATION 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 CYGNUM_DEVS_FLASH_AMD_AM29XXXXX_V2_ERASE_REGIONS 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.