STM32F429ZI Flash Problem. MCU sets FLASH->SR bits: PGPERR and PGSERR all the time even it is cleared just before.

[slawek]

MCU sets FLASH->SR bits: PGPERR and PGSERR all the time even immediately after it is cleared.

It causes a problem with erasing flash memory.

I am using RTOS(TIM1 as a base), Timers and Systick as well but I think those shouldn't be a problem.

Code is executed from flash but from different regions, so it isn't overlapping.

I was thinking if cache can make this problem, but after turning of cache before I have still the problem.

I was doing flashing other sectors on STM32F1 and there was no problems with it, but if I remember correctly there are no such flags.

[berendi]

I suspect there is a corrupted or uninitialized pointer somewhere that tries to write the flash.

If it's a null pointer, you can catch it by mapping RAM at address 0, see SYSCFG->MEMRMP. Move the beginning of the RAM up by a few words in the linker script, place some guard value at 0x20000000, and see if it changes.

[jwoerle]

Thanks for sharing this answer. This thread and the following thread solved a similar issue of me:

https://community.st.com/s/question/0D50X00009XkWriSAF/stm32f407-flash-programming-error-pgserr-and-pgperr

It was actually a bug introduced by me:

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.

[slawek]

The clue seems to be good. I had no time to do exactly what you mentioned yet, but I turned off some tasks and I think the guilty one is default task with LWIP initialization (because it looks that it helped). I would need to investigate more because I would need to have both Ethernet and Flashing at same time.