What happens if block configuration shall be updated?
From NvM’s point of view, after a configuration update the NvM only reads blocks with parameter NvMResistantToChangedSw set to true.
From FEE’s point of view, it is possible to add and remove blocks and to update the block configuration (size, datasets, …) of each block. Every block which should be readable after the block configuration update must get the same BlockID as before (preconditioned that the size of this block has not changed). It is highly recommended to enable FeeBlockIdFixed for every block to enforce this.
In case the size of a block has been changed, but the data is still in flash with old length, read requests on this block will result in MEMIF_BLOCK_INVALID until the block is written again with a new length.
However, if you want to add new blocks it might have tremendous consequences on the start-up performance. In case the Block ID of the new block is higher than all other Block ID’s (which is most likely if you add new blocks), the FEE will need much more flash requests to process jobs on this block. The more blocks you add, the worse the performance gets. This situation remains until two sector switches are executed. Afterwards, the performance of the recently added blocks remains the same in older blocks.
Therefore, it is highly recommended to execute two Fee_ForceSectorSwitch requests right after adding blocks to FEE configuration. Nevertheless, the first start-up before executing the two requests will still have a bad performance and might not cope with start-up timings.
To avoid such a situation and if you know that blocks might be added later, you can add dummy blocks to your configuration. Later, if the blocks shall be added, you can adapt the dummy blocks and there will be no bad performance. As long as the dummy blocks are not needed, WriteAlignemnt * NumberOfDummyBlocks bytes are wasted in flash.