STM32H503 OTP BUG

[Mike1992]

Hello everyone, I encountered a problem with overwriting OTP memory both from a user application and from the stm32 programmer.
I write data to the OTP cell, close the memory using standard hal functions, turn off the power of the debug board, turn on the power, go to the stm programmer and see correctly written data.
After that, I try to change one of the memory cells and the cube programmer gives me an error (which is correct, since this memory cell has already been written once). I close the error windows and read the memory, after that I see that the memory is CHANGED, but to a random number. This is repeated only once, that is, the cell can be written twice both from the PROGRAMMER and from the application.
I tried to write the same data but to the addresses 0x08FF F000, 0x08FF F040, 0x08FF F080, and all the time the secondary cell write was triggered (the bottom picture).
I also encountered a problem with calling NMI_Handler and HardFault_Handler when trying to read memory from the application, but this was solved by adding the following code to the interrupt handler:
void NMI_Handler(void)
{
if((FLASH->ECCDR && 0xFF))
{
//the memory is empty
//ECC error due to access to uninitialized memory

//Clear the ECCD flag
FLASH->ECCDETR |= (1<<31);
}
else
{
//ECC error detected a true failure
while (1)
{
}
}
}

[TDK · Accepted solution]

You can only write to an OTP (one time programmable) cell once. Doing so twice will yield an ECC error. It's on you to adhere to this rule. The chip will not enforce it for you.

The way to avoid this is to lock the cells after you have written to them to avoid future writes.

[Mike1992]

thanks for the answer, and what about the problem with reading an already written area and calling error interrupts? can this be avoided? I read the memory area using the standard method memcpy(&read_struct, (uint32_t*)FLASH_OTP_START_ADDR, sizeof(read_struct));

[Mike1992]

what to do with error handlers? when programming OTP goes to this error

[TDK]

I'm not sure there's a good way to read twice-written data. It's not valid as the ECC doesn't match.

Reading a word that has been written once should cause no errors.

There is this which it seems like you've seen, but isn't perfectly applicable.

Handling ECC errors in STM32H5 series: Reading unw... - STMicroelectronics Community