Skip to main content
Visitor II
February 13, 2024
Solved

STM32H723 Flash is filled with 0 after erase and write

  • February 13, 2024
  • 3 replies
  • 4786 views

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?

    This topic has been closed for replies.
    Best answer by Makandra

    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.

    3 replies

    Graduate II
    February 13, 2024

    >>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.

    MakandraAuthor
    Visitor II
    February 14, 2024

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

     

    MakandraAuthor
    Visitor II
    February 14, 2024

    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.

    Super User
    February 14, 2024

    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.

    MakandraAuthorAnswer
    Visitor II
    February 15, 2024

    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.