STM32H723 Flash is filled with 0 after erase and write

[Makandra]

Hello

I am running a NUCLEO-H723ZG board.

User data is saved to internal flash from within the application according to the following procedure: unlock the flash, erase, program. None of the operations return errors. When monitoring the memory, everything looks correct.

The sector used is sector 7. Starting address 0x080E0000.

Here comes the issue: the next time deploying the application/powering on the board, lots of areas in the sector are filled with 0. For instance:

0x080E0000-0x080E0040 are only 0, even though I have written (non 0) to them.

0x080E0040-0x080E0200 are OK

0x080E0200-0x080E0240 are 0.

0x080E0240-0x080E0400 are OK. And so on. This pattern repeats over the entire sector.

The size of the 0-areas seems to vary every time deploying and re-run the application.

I have found a workaround that seems to work: Delete 2 sectors, starting sector 6. Sector 6 will now be corrupt as described above, while sector 7 can be used.

Does anyone have a clue what might be the issue and a solution to the problem?

[Tesla DeLorean]

>>Does anyone have a clue what might be the issue and a solution to the problem?

Your code is malfunctioning, but we're not psychic, present the code, and perhaps instrument it better so you can understand what's happening without using a debugger.

[TDK]

While it might be a convenient explanation, flash doesn't spontaneously change states. It is very well behaved, these are commercial chips which are not subject to random misbehavior.

The overwhelmingly likely scenario is that your code doesn't do quite what you want it to and has bugs that need to be fixed/addressed.

[Makandra]

I guess this would be the bare minimum to recreate the issue...

int main(void)
{
	HAL_Init();
	SystemClock_Config();

	const UINT address = 0x080E0000;
	UINT *flash_data = (UINT*) (intptr_t) address;
	UINT status = 0;

	if (*flash_data == 0xFFFFFFFF)
		status = 1;	//Empty
	else if (*flash_data == 0)
		status = 2;	//Corrupt
	else
		status = 3;	//Written data

	//Breakpoint here to check status value
	status = HAL_FLASH_Unlock();
	if (status != HAL_OK)
		while (1)
			; //Error

	FLASH_EraseInitTypeDef erase;
	UINT sector_error = 0;
	erase.Banks = FLASH_BANK_1;
	erase.TypeErase = FLASH_TYPEERASE_SECTORS;
	erase.VoltageRange = FLASH_VOLTAGE_RANGE_3;
	erase.Sector = FLASH_SECTOR_7;
	erase.NbSectors = 1;
	status = HAL_FLASHEx_Erase(&erase, (uint32_t*) &sector_error);

	if (status != HAL_OK)
		while (1)
			; //Error

	UINT data[] =
	{ 1, 2, 3, 4, 5, 6, 7, 8 };

	status = HAL_FLASH_Program(FLASH_TYPEPROGRAM_FLASHWORD, address, (uintptr_t) data);

	while (1) //End
		HAL_Delay(100);
}

[Makandra]

I would like to clarify that the issue is not presented if resetting the chip either with the reset button on the NUC or through the reset button in eclipse.

[Makandra · Accepted solution]

I think I have found the cause.

When running debug, the application is reset and run for a short while prior to the debugger is attached. During this short run, the application has enough time to erase and start program, but does not finish the operations.

Solution: Do not automatically erase and program in the start of the application. For this scenario, adding HAL_Delay(1000) before the erase solves the problem.