USE_PARAMETER_BLOCK without FLASH_FILE_SYSTEM

[aaronlawrence]

I don't want the Flash file system, but I do want to use the parameter block.

Defining USE_PARAMETER_BLOCK without FLASH_FILE_SYSTEM in Config.h, doesn't work because in lpc23xx.c
fnWriteBytesFlash does nothing if FLASH_FILE_SYSTEM or SPI_FILE_SYSTEM is not defined.

I also don't understand why the parameter system stores bytes to quadwords. Surely each time parameters are written we just erase the whole sector and write the parameters as a single block?

[mark]

Hi Aaron

Generally it should be possible to use the uFileSystem without uParameterSystem or vice-verse so I will try testing the configurations to verify on the last NXP project release. Once I known whether there is a problem I will report back.

The reason why the parameter system (in the NXP project) uses quad-words to store each byte is due to the fact that the FLASH has a check sum for each quad-word in the memory. This doesn't allow a quad-word to be modified once it has been written.

This is due to a the property of the uFParameterSystem which allows the parameter content to be written on a byte bases. Note that this doesn't allow content to be changed on a byte basis if the value is not blank! In order to comply with this basis characteristic (for compatibility between all processors) there was no alternative but to make each single byte occupy the smallest programmable entity (quad-word). For most chips the smallest entity tends to be 16 or 32 bits and so the NXP FLASH memory represents a less suitable solution to meet this requirement; each byte takes up a lot of space...


However, there are various other methods if this is not suitable. One fairly new one to the project is USE_PARAMETER_AREA and is especially suitable in NXP projects where the swap block is not of interest and optimum memory use is. It is also not yet described (it was added recently in an NXP based project where this operation was the most suitable) so I will make a first description here:

1) When this define is used USE_PARAMETER_BLOCK and USE_PAR_SWAP_BLOCK should be disabled. Also FLASH_FILE_SYSTEM is not needed (I am quite sure of this since I worked recently on this project using the V1.4 release as base).
2) The parameters are essentially compatible.
3) When the parameters are saved they are saved as a single block with each byte occupying a single byte - therefore only complete parameter block writes are performed - no multiple smaller blocks are possible)
4) When a new write is performed, the FLASH sector is not deleted but instead a new block is simply added in FLASH following the original block.
5) When parameters are copied back from FLASH, the routines will automatically search for the last block in the list and use that (old blocks are not deleted but are ignored).
6) At some point further writes are no longer possible since there is no more space and so the complete FLASH sector is deleted and the write is then performed at the start of the sector again. There is a risk that all parameters are lost should power fail during this instance - if that is an issue in a project then the swap block is the way to go...
7) There is an important point to be considered when working with NXP FLASH. This is that a single FLASH sector should never be written more that 16 times without a sector delete taking place. If more writes are performed there is a risk of data corruption due to programming stress build up. Therefore the best parameter block size is (sector size / 16). This will automatically cause a delete once every 16 parameter block updates. Larger sizes are also OK. Smaller sizes are best avoided - so just add extra dummy parameters to keep the minimum.

For extra details about the NXP FLASH see the following http://www.utasker.com/forum/index.php?topic=136.0 and in particular the Philips application's link!

Regards

Mark

[aaronlawrence]

OK, this sounds like what I want but I don't have this code.

In the meantime, I hacked the fnWriteFlashBytes etc to work even with just USE_PARAMETER_BLOCK defined. Although the code all steps through OK and the IAP calls get a zero result, memory does not change after the write. Is there some kind of protection enabled?

[mark]

Hi Aaron

There is no protection that I know of.

Regards

Mark

[mark]

Hi Aaron

I can confirm that the FLASH write is not enabled when only the parameter system is active.
You probably corrected this with (at 4 locations) :

#if defined FLASH_FILE_SYSTEM || #defined USE_PARAMETER_BLOCK || defined USE_PARAMETER_AREA

Note that USE_PARAMETER_AREA is there but there is no real project configuration for it.


I wanted to add it quickly but it proved to be a bit more complicated due to the fact that it assumes all parameters to be  in a single block which is read and written together. The demo project has two areas (networks and general parameters) and so these need to be put into a single block for it to operate - I couldn't make a quick change to show it.

But here are the calls in case you do decide to follow that route:

1) To retrieve the parameter block:

    if (fnGetPar(PARAMETER_BLOCK_VERSION, (unsigned char *)&temp_pars->temp_parameters, sizeof(PARS)) != 0) {
        uMemcpy(&temp_pars->temp_parameters, &cParameters, sizeof(PARS)); // no valid parameters available - set defaults
    }

Note that the first value in the parameter struct should be a byte indicating the version number of the block (if a new block type is used simply change the version number so that it deletes the old type and starts with a new one).

2) To save the parameter block
    fnSetPar(0, (unsigned char *)&temp_pars->temp_parameters, sizeof(PARS));

3)
The parameter area is activated and configured with:
    #define USE_PARAMETER_AREA
        #define PARAMETER_BLOCK_START   FLASH_SECTOR_27_OFFSET

Here the final small sector is used (assumes 512k chip). Otherwise a small one towards the start of FLASH could be used, when a large 32k is overkill.


I then tried to see whether the parameters were saved with the change above (just USE_PARAMETER_BLOCK). I didn't see any problems. Which sector are you actually using to save the parameters to?

Regards

Mark

[aaronlawrence]

Yes that's what I did.
But USE_PARAMETER_AREA is a better fit anyway. So don't worry about USE_PARAMETER_BLOCK.

Next hardware rev we are changing to LPC2368, not least to get away from these stupid 32kB Flash sectors at the top.

Having merged to v1.4.3 I see the USE_PARAMETER_AREA code, but I haven't had a chance to try it yet. Few other things in flight ...