What I say below applies to the space managed by SecureStorage. Flashing your program is a different matter.
So no, nothing is erased for you in the SecureStorage space. In the api, you indicate which block to write, and the system just writes that block at the correct location in flash memory. And it will write that whether that block was erased or previously written.
The way that the flash works is that when it is erased, every bit is set to ‘1’. When you write, the 1 cells stay 1 and any 0’s that you are writing get set to 0. You can write over a block multiple times, but you can only set 1’s to 0’s. You cannot set 0’s back to 1. Only erasing does that, and it sets all bits back to 1. But it does that for the whole secure storage area (all the blocks).
So, let’s say that there are 128 blocks of 32 bytes. Calling .Erase() will set all the bits in all 128 blocks to ‘1’. That is, the whole of SecureStorage space will be set to 0xff.
Now lets say you want to write 64 bytes of data. Write that to blocks 0 and 1. Later, when you want to write another 64 bytes with different values, don’t erase - just write the next 64 bytes to blocks 2 and 3.
When reading, you want to read the last set of 64 bytes that have valid values (since those will be the most recently written).
When writing, if you reach block 127, you’ve run out of space. NOW you need to erase the whole 128 blocks with .Erase, and you can store your data in blocks 0 an 1.
My practice is to write data with a preamble of a signature and length - for example 0xAA55 [len] [data], On reading, if I see 0xAA55, I know I have a block of config data, and the next block is [len] bytes away (potentially plus some buffer to make it align with a block boundary). When the current start plus [len] is 0xffff, then I know that the block that I am on is the last in the chain, and represents the most recent config data.
Hope that helps.