2012-06-01 07:59 AM
I am trying to erase and program a 16KB sector (sector 2) in the STM32F405 (rev A)on the ST3240G eval board. The problem is that two error flags (PGSERR and PGPERR)are set and cannot be cleared.
Soon after a reset, still running at 16MHz on HSI, no PLL, and before any attempt to erase or write to flash I use this sequence to clear the error flags in the status register:if(FLASH_GetStatus() != FLASH_COMPLETE)
{ // clear flash error
FLASH_Unlock(); // Unlock the Flash Program Erase controller
FLASH_ClearFlag(FLASH_FLAG_PGSERR | FLASH_FLAG_PGPERR |
FLASH_FLAG_PGAERR | FLASH_FLAG_WRPERR |
FLASH_FLAG_OPERR | FLASH_FLAG_EOP); // clear error status
test = FLASH->SR; // DEBUG
FLASH_Lock(); // Lock the Flash Program Erase controller
}
When I step through the code I see the FLASH->SR register set to 0x0000 00c0 before and after the call to reset the flags.
Is there a reason these error flags are set immediately after a reset? The flash programming guide says the default on reset is 0x0000 0000.
Jack Peacock
#flash #stm32f4xx-flash
2012-06-04 01:57 PM
Problem resolved. A programming bug (loader script error) attempted to write to flash on C runtime startup. This locked out the FLASH unit for further programming, forcing a permanent error flag until power on reset.
Jack Peacock2013-01-24 09:13 AM
Hello Jack,
Can you explain, what went wrong at your startup code? I have the same problem. It seems writing the SBC->VTOR forces the two error flags to be set. They cannot be cleared anymore.Sven2013-01-28 03:38 PM
Same here. I can't seem to be able to erase or write to flash. I just keep getting FLASH_ERROR_PROGRAM for every call after unlocking the flash. Flash Unlock seems to work correctly as my FLASH->CR goes from 0x80000000 to 0.
2013-01-28 03:58 PM
I seem to have solved my problem but I don't think it was a startup script in my case. I had to clear the flags before unlocking flash. It seemed to work after that.
2014-06-19 07:57 AM
I had the same problem with a STM32F405 board I made. Clearing the flash error flags before unlocking also resolved it. However, it isn't clear to me why the error flags are set in the first place. Any insight on this? Also, can just clearing the flags on startup cause any problems later on?
2014-09-24 08:20 AM
I am using EEPROM-Emulation on an STM32F207 as proposed by ST and came across the same problem. The software provided by ST (EEPROM-Emulation and SPL) is not clearing the error flags before accessing flash.
I am using Keil uVision 4.70 together with a ULink Pro. I found out that when I - use ETM tracing - have the program running - set a breakpoint PGSERR and PGPERR get set immediately when the breakpoint is set most of the time, leading to the flash routines returning errors. Clearing the error flags before accessing flash helped in my case.