cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L4 Flash erase fail with HAL_FLASH_ERROR_PGS and HAL_FLASH_ERROR_WRP

rshar.21
Associate II

Hi Everyone,

I have written a firmware which write some meta data in STM32L4 internal flash memory. But sometimes it happens that code gets stuck in a loop while erasing the flash memory. 

uint32_t UserFunctionForErasingFlash(void) {
  FLASH_EraseInitTypeDef EraseInitStruct;
  uint32_t SectorError = 0;
  uint32_t Success=1;

  EraseInitStruct.TypeErase   = FLASH_TYPEERASE_PAGES;
  EraseInitStruct.Banks       = GetBank(MDM_FLASH_ADD);
  EraseInitStruct.Page        = GetPage(MDM_FLASH_ADD);
  EraseInitStruct.NbPages     = 2;

  /* Unlock the Flash to enable the flash control register access *************/
  g_unlock_erase_flash = HAL_FLASH_Unlock();
//  clear_flash_flags();
  if(HAL_FLASHEx_Erase(&EraseInitStruct, &SectorError) != HAL_OK){
    g_erase_error_code = HAL_FLASH_GetError();
    Success=0;
    Error_Handler();
  }

  /* Lock the Flash to disable the flash control register access (recommended
  to protect the FLASH memory against possible unwanted operation) *********/
  HAL_FLASH_Lock();

  return Success;
}

Above is the code snippet, where I checked FLASH_UNLOCK is happening perfectly. And also Bank and page number are also correct. But Erasing the flash memory is giving error HAL_FLASH_ERROR_PGS and HAL_FLASH_ERROR_WRP.

 

To understand the reason, I uploaded the code again, and it gets stuck here (2 times I checked it). But when I started debugging line by line, then it worked perfectly. After erasing, write also happen correctly. 

 

Has anyone encountered a similar issue or have insight, how can I recreate this issue and why erasing the internal flash is giving this issue and how can I resolve it?

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

After you unlock the flash but before you do anything with it, check for and clear all error flags. The debugger does stuff that can cause them to be set.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

11 REPLIES 11
TDK
Guru

After you unlock the flash but before you do anything with it, check for and clear all error flags. The debugger does stuff that can cause them to be set.

If you feel a post has answered your question, please click "Accept as Solution".

Hi @TDK 

Thanks for your reply. But this issue I faced in the working board and gets stuck in the infinite loop (as you can see in the code snippet) To debug this I have to put a debugger to know the reason, and code got stuck in same place. 

 

I can assume that flag might be set getting because of the debugger, but can you suggest what can be the reason flags getting set without debugger because I have got this in multiple boards. 

I debug 3 times without breakpoint and code used to hand there but when I started debugging step by step from that time it started working, can you suggest what can be the reason for it?

> I can assume that flag might be set getting because of the debugger, but can you suggest what can be the reason flags getting set without debugger because I have got this in multiple boards. 

Probably a software bug. Perhaps you are not completing a flash page write. Perhaps only writing a partial flash page. The issue is likely with the programming, not the erase code you've posted.

If you feel a post has answered your question, please click "Accept as Solution".

@TDK wrote:

The issue is likely with the programming, not the erase code you've posted.


+1

 


@rshar.21 wrote:

giving error HAL_FLASH_ERROR_PGS and HAL_FLASH_ERROR_WRP.


@rshar.21  Where, exactly, do those errors occur?

Did you look those codes up?

HAL_FLASH_ERROR_PGS =  Programming Sequence error;

HAL_FLASH_ERROR_WRP = Write protection error.

 

Hi @TDK 

I verified few things in firmware before I reply here.

 


@TDK wrote: 

Perhaps only writing a partial flash page. 


You're right, Firmware does full page erase and then partial write in flash. Then again to write more data it try to erase page and gets stuck.

And also as you can see the code, I have not followed the right practice of erasing/writing in flash (like checking busy bit, clearing error flags etc.).

 

But out of thousands of board, I found this on 4 boards only (everything is same hw, fw etc). Any suggestion why this got triggered in 4 boards. 

 

And if you can advice, clearing the FLASH before write/erase will solve this or should I add anything else also?

 

 

@Andrew Neil 

For debugging a uploaded a code and when it went to Error_Handler(), I read g_erase_error_code value which is 0x24(which I believe a combination of 2 errors 0x20(HAL_FLASH_ERROR_PGS) and 0x4(HAL_FLASH_ERROR_WRP)). 

Let me know if you need any other detail?


@rshar.21 wrote:

But out of thousands of board, I found this on 4 boards only (everything is same hw, fw etc). Any suggestion why this got triggered in 4 boards. ?


It's often the case that code which is not quite right will "work" in many (or, even, most) situations - it may be only the edge cases which your code fails to handle where the problem becomes visible.

Dor_RH
ST Employee

Hello @rshar.21

To resolve issues related to STM32L4 flash erase failures, specifically HAL_FLASH_ERROR_PGS (Programming Sequence error) and HAL_FLASH_ERROR_WRP (Write Protection error), it is crucial to ensure that flash memory operations are executed correctly and all necessary precautions are taken. Follow these steps:

  • Unlock the Flash: use HAL_FLASH_Unlock() to unlock the flash memory, allowing write and erase operations.
  • Clear Flash Error Flags: use the __HAL_FLASH_CLEAR_FLAG macro to clear all possible flash error flags before starting the erase operation.
  • Erase the Flash Pages: call the HAL_FLASHEx_Erase function to erase the specified pages.
  • Lock the Flash: after the erase operation, lock the flash memory using HAL_FLASH_Lock() to prevent accidental writes.

Also, you can refer to: 

  • STM32L4 Reference Manual: for detailed information on the flash memory programming sequence and error handling.

Dor_RH_0-1724413421153.png

 

  • STM32CubeL4: contains numerous examples that may assist you with FLASH operations, such as:
    • FLASH_EraseProgram
    • FLASH_FastProgram
    • FLASH_DualBoot
    • FLASH_WriteProtection

I hope my answer has helped you. When your question is answered, please select this topic as solution that answered you, it will help others find that answer faster.

Thanks for your contribution.

Dor_RH

> But out of thousands of board, I found this on 4 boards only (everything is same hw, fw etc). Any suggestion why this got triggered in 4 boards. 

It's most likely that all boards behave the same, given the same code.

> And if you can advice, clearing the FLASH before write/erase will solve this or should I add anything else also?

You should follow the guidelines for writing to flash to fix the issue. In particular, writing complete flash pages (64 bits) at a time.

If you feel a post has answered your question, please click "Accept as Solution".

Hi @TDK ,

I do write a 64-bit at a time. when you mention partial write, I thought you are saying that I should finish writing in whole 2KB page.

I think clearing all the error flags before writing/erasing will be enough, isn't it?