cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H503 OTP BUG

Mike1992
Associate II

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)
{
}
}
}

OTP_BUG.jpg

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

2 REPLIES 2
TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".

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));