about the AT45DB161D SPI_EEPROM use!

[tr111]

Hello:
     I have the AT45DB161D chip,but the config.h only" chip size EEPROM_16K, EEPROM_32K or EEPROM_64K". this too small,the AT45DB161D  is 16-megabit. How can I use the chip size?
     In the uTasker SPI_EEPROM.doc "The necessary circuit for the SPI EEPROM is shown in appendix A. It is shown for connecting to a number of Freescale evaluation/demo boards."
     Can AT45DB161D  also use the The necessary circuit like you do??

[mark]

Hi

There are some notes about configuring for the AT45DBXXXX in the SP5 release notes (http://www.utasker.com/software/V1.3/SP_M5223X_Notes.txt - 8. SPI FLASH SW uploads).

Presently the code supports one device specifically to allow software uploads - see also the users' guide to using it with the M5223X:
http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF

The configuration uses #define SPI_SW_UPLOAD and then some details about the device used as follows (in app_hw_m5223x.h).

Code: [Select]

#define SPI_FLASH_PAGE_LENGTH 264                                        // standard page size (B-device only allows 256)
//#define SPI_FLASH_PAGE_LENGTH 256                                      // size when power of 2 mode selected (only possible on D-device)
#define SPI_FLASH_BLOCK_LENGTH (8*SPI_FLASH_PAGE_LENGTH)                 // block size - a block can be deleted
#define SPI_FLASH_SECTOR_LENGTH (64*4*SPI_FLASH_PAGE_LENGTH)             // exception sector 0a is 2k and sector 0b is 62k
#define SPI_FLASH_PAGES         1024                                     // 256k part expected
#define SPI_DATA_FLASH_SIZE    (SPI_FLASH_PAGES*SPI_FLASH_PAGE_LENGTH)
The settings which you have been looking at (SPI_EEPROM) are for use with smaller SPI based EEPROM devices, which is described here:
http://www.utasker.com/docs/uTasker/uTaskerSPI_EEPROM.pdf
This allows the uFileSystem to operate in these external devices.

When using the SPI FLASH the uFileSystem is still internal but the SPI FLASH can be used for SW uploads as well as for direct access by the application (but not as a part of the file system).
We have additional support for multiple SPI FLASH devices in our development version which will be released at some time in the future. Possibly it will eventually be integrated to work with the uFileSystem as well.

There is also a circuit diagram for wiring the AT45DB041D at:
http://www.uTasker.com/docs/M5223X/spi_flash_freescale.PDF
The same wiring is used for all devices of this type (irrespective of their internal size).

Regards

Mark

[tr111]

MarK:
     that your mean is:M95128, M95256, M95512 can use as uFileSystem when define SPI_FILE_SYSTEM!
     The ATMEL AT45DBXXX can only use as SPI_SW_UPLOAD,but in the future it will use as the uFileSystem ?
     I will waiting  for this!
     I think the uTasker is well!

[mark]

Hi

This is correct. The AT45DBXXX is supported for SW updates in V1.3 SP5 but the uFileSystem is in internal FLASH.

It is however possible to use the SPI FLASH (not using the file system command like uOpenFile(), uGetFileLength(), uGetFileData() etc. since these will be directed to the internal FLASH) by using the following commands:
   fnEraseFlashSector();     (erases an 8 page block)
   fnWriteBytesFlash();
   fnGetParsFile();

These are used by the file system so are lower level commands, but these can be used to save and read data - as long as the address of the data is managed by the user. The first address of the SPI FLASH is that after the end of the internal file system and reads and write can span multiple SPI FLASH pages. To delete multiple blocks it is necessary to call the erase routine from a loop until the required amount are deleted.

Regards

Mark

[tr111]

Mark:
     that uOpenFile(), uGetFileLength(), uGetFileData() can't use to the M95128, M95256, M95512  too ??
    to use theM95128, M95256, M95512 must to use the
     fnEraseFlashSector();fnWriteBytesFlash();fnGetParsFile()

[mark]

Hi

When SPI_FILE_SYSTEM is specified, M95128, M95256, M95512 are used for the file system so all file system commands (like uOpenFile(), uGetFileLength() etc.) work.

It is only when using SPI_SW_UPLOAD that these command are reserved for the internal file system.

Note that with SPI_FILE_SYSTEM there is NO internal file system - it is all in the external device.
Also FLASH_FILE_SYSTEM (internal file system define) should not be set together with SPI_FILE_SYSTEM.
Futher, SPI_SW_UPLOAD and SPI_FILE_SYSTEM should not be used together.

Regards

Mark

PS. The SPI_FILE_SYSTEM was popular with the NE64 since the NE64 has very limited FLASH resources.
It is being contemplated as how to best utilise the new SPI FLASH capabilities - a possibility is that the uFileSystem will remain in internal FLASH and a second file system be introdued to make the most of the larger data capacities (like a mini-FAT) but it is too early to define which way the development will actually go.
For anyone interested in taking advantage of the fact that multiple SPI FLASH devices can be controlled in a linear memory mapped solution then there is a working development version available for Beta testing.

[tr111]

Mark:
      you must be a doctor!So professional!

[Thomas]

Are there any plans to support the Atmel dataflashes in the near future on the AT91SAM7X platform too? Will be using an AT45DB161D or 081D on our board, with filesystem and parameters on external flash.

[mark]

Hi Thomas

You can expect a version for the SAM7X within the next few days supporting single (and probable also multiple devices) equivalent to the present M5223X support (as explained above) which allows SW uploads to external SPI FLASH and also user reading and writing (lower level than the file system).

If there is interest in the parameters and uFileSystem being also in external SPI FLASH this can also be arranged as second step - in fact it is only a small step so doesn't represent any big development effort (mostly a set up thing).

Watch the SAM7X forum for notification when a pre-release is available (or possibly a complete SP release).

Regards

Mark

PS: the ATMEL SAM7X EVAL has an AT45DB131C on it, so this will be used for testing. This is compatible with the others that I have listed so configuring for 161D or 08D is a matter of a couple of defines.
In addition the devices are checked on start up so the code also knows which device(s) are present so could theoretically automatically dimension everthing. However I don't think that this is really practical for production work, where the types should really be defined!!
The SW support update simply checks that the device is not too small to accept the largest SW expected (256k for the SAM7X - possibly 512k if the largest SAM7X is used). If the device is too small it disables the interface but if a 1M or 2M etc. device if found it will simply accept it. Any space above the area which is destined for the upload (after first 256k for example) is free to be used by the application directly for what ever it wants to use it for.
Should no SW upload space actually be required the whole FLASH space is free for application use.