FLASH_GRANULARITY

[kmjackson]

Hi Mark,

I'm trying to use an external SPI_FLASH (AT45DB642) with the PARAMETER_BLOCK_START located in tne internal flash. I'm using the EVK1105, which has an AVR32 (AT32UC3A0512). It seems that both device (AVR32 and AT45DB642) have different FLASH_GRANULARITY, (AVR32 = 512, AT45DB = 1024).  Will the different granularity cause a problem, and which one should I use for FLASH_GRANULARITY in the project.


Thanks

[mark]

Hi

As long as you don't require the uFileSystem to be in both internal and external FLASH you shouldn't have any restraints.

The uParameterSystem uses its own set of definitions and the FLASH drivers know the FLASH granularity of each area (internal 512 bytes, external 1024 bytes, for example).

In your case you need
PARAMETER_BLOCK_START just before the end of internal FLASH (say 0x80000000 + 512*1024 - 2*PARAMETER_BLOCK_SIZE when using a swap block)
PARAMETER_BLOCK_SIZE to be equal to FLASH_GRANULARITY, where FLASH_GRANULARITY is valid for the internal FLASH and can not be changed.

Since the uFileSystem is in external FLASH, where the driver knows that the FLASH page size is 1024 bytes (SPI_FLASH_BLOCK_LENGTH) you can declare files as being a multiple of these blocks in length eg.: #define FILE_GRANULARITY (4*SPI_FLASH_BLOCK_LENGTH) without needing to consider the internal FLASH page size.

Only when there is an overlap (the uFileSystem starts in internal FLASH and ends in external SPI FLASH) does the FILE_GRANULARITY have to be chosen to be a value that can be divided by both of the physical FLASH page sizes (it is essentially governed by the largest page size of the two)

Regards

Mark

[kmjackson]

Thank you,

I understand now.

[kmjackson]

Please explain this

   #define FLASH_LINE_SIZE              16                                             
 // lines made up of 16 words (theoretically 4 are necessary but it is more practical to have the size larger than a file header)


kenneth

[mark]

Hi

The FLASH in the AVR32 must be written as long words (4 bytes at a 4-byte aligned address).

It is not possible to start with 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff in FLASH and write the following sequence:
0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff

It is only possible to write:
0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Since the file system generally has a a byte header for each file (4 bytes for the length and 1 byte of the type) and writes the content before setting the header it effectively does the following sequence:

0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff (empty)
0xff 0xff 0xff 0xff 0xff 0x01 0x02 0x03 (start of content)
0xff 0xff 0xff 0xff 0x01 0x01 0x02 0x03 (file type added)
0x00 0x00 0x03 0x52 0x01 0x01 0x02 0x03 (full header added)

This sequence is however not possible for the AVR32 FLASH.

Therefore a line buffer is kept (16 bytes long) and is filled first before writing each 16 bytes (in fact longer buffers increase the write efficiency a bit).
At the start of the file the buffer will contain the start of the data and then the header will be added after all data has been written. Only when the complete header is ready is this line buffer committed to FLASH.

This means that all writes are 16 bytes long (a multiple of the 4 byte which is the smallest unit) and so the rules to writing the AVR32 FLASH are respected.

16 bytes line buffer length is not necessary but less that 8 will not work. The larger the line buffer, the less FLASH line writes are made. It is a bit more efficient to reduce the writes (each line write have a small additional overhead) and so 16 was chosen rather than 8. It should therefore be possible to change this to 8, 24, 32, etc.

Regards

Mark

[kmjackson]

Thank you for the detailed explaination.