STM32F407 Flash programming error (PGSERR and PGPERR)

[Kacper Kowalski]

Posted on January 03, 2018 at 10:32

In FLASH banks 0 and 1 I placed a simple bootloader which jumps to bank 4 where the main code is placed. Banks 2 and 3 are used as emulated EEPROM (see AN3969 application note). I wrote some unit tests to check if my application properly uses the emulation and to test if the data from EEPROM is properly read and written. I upgraded HAL from version 1.5.1 to 1.7.2 and where I could I replaced HAL with LL (for GPIO, TIMERs, UART) and then some issues appeared. After startup when the first test starts writing variable to EEPROM (by EE_WriteVariable) I get PGSERR and PGPERR, so the data is not written to emulated EEPROM. Before the upgrade all tests were passing. I use STLINKv2 for debugging. The program runs under FreeRTOS.

#stm32-f4 #hal_flash

[Kacper Kowalski]

Posted on January 05, 2018 at 09:36

The error was caused (no idea why) by improper initialization of TIM2. I wanted to make TIM2 generate simple UpdateIT which also wasn't working after the change. After the change from HAL to LL I focused on fixing the emulated EEPROM issues and postponed fixing of TIM2 operation later. When I couldn't figure out what was the problem with EEPROM I decided to fix TIM2 issues. After getting TIM2 working I also got rid of problems with emulated EEPROM. I really don't know how those two things influenced each other.

[Jaws]

Hi

I am encountering the exact same issue but with TIM5. I tried to switch to TIM7 as I didn't see any issues with the timer setup. That didn't help.

What exactly did you do to solve the timer issue?

[Jaws]

I found a solution to my issue.

Before setting up my timer I did a HAL_TIM_Base_DeInit() on a timer instance (type TIM_HandleTypeDef), that did not have any data on it. This must have messed up some register - perhaps FLASH_CR.

Anyway, removing the call to HAL_TIM_Base_DeInit() in my timer init function fixed the problem.

[jwoerle]

Hey,

I have the same issue on 2 applications with Bootloader and EEPROM Emulation (STM32F4 and STM32F7) but thanks to this thread, I could solve the problem.

I have a watchdog running and reset it frequently with

HAL_IWDG_Refresh(&hiwdg);

For debugging purpose, I disable my watchdog init

// disable for debugging purpose
// MX_IWDG_Init();

This causes problem in the Flash interface, where the FLASH_WaitForLastOperation() function fails.

My solution is to also disable the HAL_IWDG_Refresh() function in debugging.

[JPenn.1]

I very recently (4 days ago from this post) had the same issue with EEPROM emulation as the OP. I found a write to address 0x00000000 in the code. In my case I tracked it down to the ADC initialize function that passed an ADC address of 0x00000000 from an initialized structure. It appears an unintended write to an address in FLASH sets these error bits.

[dimsu]

Hi guys,

similar situation happened to my project too. Using STM432F413, I faced with a problem when the FLASH_WaitForLastOperation() began returning errors. Diving into debugging, I found that the PGSERR and PGPERR bits were flagged sometimes.

In my case, it was connected with the periodical IWDG resets while the Wtachdog itself was not initialized and run.

After I initialized IWDG, the Flash writings became working without issues.