Rewriting internal flash sectors with IAP

The assumption is that same page (256 bytes) can be written again and again as long as no bits are set from 0 to 1 (this is supported by an application note by NXP...)

Not sure if this is a correct assumption. The application note says that data should be written 16 bytes at a time due to the ECC mechanism. But the datasheet says: "Data must be written to the flash in blocks of 256 bytes." This could be your answer.
Besides, there is always a possibility of bugs in the code.

The assumption is that same page (256 bytes) can be written again and again as long as no bits are set from 0 to 1 (this is supported by an application note by NXP...)

Not sure if this is a correct assumption. The application note says that data should be written 16 bytes at a time due to the ECC mechanism. But the datasheet says: "Data must be written to the flash in blocks of 256 bytes." This could be your answer.
Besides, there is always a possibility of bugs in the code.

Thanks for your reply. Data is written in pieces of 256 bytes, but only 4 bytes are added at a time. That should not be a problem I think - the application note itself suggests writing more data. But I will try.

If you write data in smaller blocks than what the flash use for ECC, and the formware then computes and saves ECC, you can't later change the other bytes part of the same block. While your changes performs the "correct" change between zero and one, the ECC bits will sometimes need to chaneg 1->0 and sometimes 0->1. This not possible without an erase.

And since it isn't a parity (intended to detect errosr) but an ECC, it have the ability to "correct" some errors. So if you do multiple writes, you can get a garbage ECC - and that ECC can result in a "repair" of the actual data bits.

Yes that was the problem! Thanks a lot, one of our clients was/is furious - but at least now there is a prospect for a fix...

Multiple writes to the same 256-byte block without an erase are likely to reduce data retention time.