Trouble programming flash with HAL_FLASH_Program

[TMalt]

I have troubles writing succesfully to flash on a STM32G07 chip.

The application is similar to this:

uint64_t data;

HAL_FLASH_Unlock();

HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, addr, data);

HAL_FLASH_Lock();

I started getting hardfault in lock because of error in programming. I found out that this was related to timeout on the wait for operation to finish inside program function. So I added a check that program returning HAL_OK before calling lock . But this just moved the problem.

The behavious is very strange.

I can see that PGAERR and PGSERR in the FLASH SR register are being set.

My data is aligned at a 64-bit boundry I have added check that both data and the address i program to will have addr & 0x07 == 0.

I suspect some other interrupt could interefere in some way. But adding __disable_irq(); does not help.

Data is programmed like 25-50% of the times rest I simply get no data programmed.

[Pavel A.]

What if instead of FLASH_TYPEPROGRAM_DOUBLEWORD you use something less? FLASH_TYPEPROGRAM_WORD?

-- pa

[TMalt]

That is not an option on this CPU, it can only program 64-bit.

[TMalt]

I observed that the CFGBSY is going on even when no programming takes place..... Tried to disable nearly all code, but still CFGBSY keeps on toggling.

Could this in any way be related to the debugger / breakpoints???

Seems to change behavious when I have no breakpoints on target!

[KaaN0]

Hi I also have this problem. I wrote the function for programming and page erasing sequences all over again according to reference manual. It has something to do with breakpoints definitely. After I put the breakpoints, FLASH->SR changes and CFGBSY bit never resets. If you try to write FLASH->CR while CFGBSY bit is set, you get hardfault. I also tried HAL_FLASHEx_EnableDebugger() but nothing changed.

[waclawek.jan]

> I can see that PGAERR and PGSERR in the FLASH SR register are being set.

From RM0444:

PGAERR is set if one of the following conditions occurs:

[...]

– In fast programming: the data to program doesn’t belong to the same row than the

previous programmed double words, or the address to program is not greater than

the previous one.

PGSERR may be a consequence.

> After I put the breakpoints

Debugging *is* intrusive. You usually don't have enough control over what exactly the debugger does when it breaks into the running program. Find other ways to monitor your program's paths (toggle pins, observe using oscilloscope/LA; use debug prints to whatever port is convenient).

JW

@kaan kılıç​  change your username from User15750360464975656633 to a normal nick.

[JHuan.11]

@TMalt​ do you had solved this problem? I meet the same problem too.

[TMalt]

Problem is not really solved. But it is clearly related to debugging, so I have changed my code so that I can debug without writing to flash. Little annoying but solvable.

[JHuan.11]

Thanks for you quickly reply. i solved my issue. since i don't init IWDG and always call HAL_IWDG_Refresh() in while loop. after init IWDG, there are no any issue now. hope can help you.

[TMalt]

Great feedback! This might solve my problem also.

I comment out the IWDG init when debugging so I have a "unused" call to the HAL_IWDG_Refresh() in a thread loop still running. I will try to verify if removing this resolves the problem.