cancel
Showing results for 
Search instead for 
Did you mean: 

[STM32F405] flash strange behaviour

_marco95_
Associate II

Hello all,

I'm trying to lock the flash in level 1 mode. To do so, I'm using the provided ST APIs. In particular, I'm doing:

 

 FLASH_Unlock(); // unlock flash to deal with it
 FLASH_OB_Unlock(); // unlock option byte to deal with it
 if(FLASH_OB_GetRDP() != SET) // check current protection status
 {
      FLASH_OB_RDPConfig(OB_RDP_Level_1);
      FLASH_OB_Launch(); // launch the option byte writing procedure
      
      
  }
FLASH_OB_Lock(); // lock option byte
FLASH_Lock(); // lock flash

 

Now, looking at the function implementations of the library, I can see something I'm not understanding in FLASH_GetStatus:

 

FLASH_Status FLASH_GetStatus(void)
{
  FLASH_Status flashstatus = FLASH_COMPLETE;
  
  if((FLASH->SR & FLASH_FLAG_BSY) == FLASH_FLAG_BSY) 
  {
    flashstatus = FLASH_BUSY;
  }
  else 
  {  
    if((FLASH->SR & FLASH_FLAG_WRPERR) != (uint32_t)0x00)
    { 
      flashstatus = FLASH_ERROR_WRP;
    }
    else 
    {
      if((FLASH->SR & (uint32_t)0xEF) != (uint32_t)0x00) 
      {
        flashstatus = FLASH_ERROR_PROGRAM; 
      }
      else
      {
        if((FLASH->SR & FLASH_FLAG_OPERR) != (uint32_t)0x00)
        {
          flashstatus = FLASH_ERROR_OPERATION;
        }
        else
        {
          flashstatus = FLASH_COMPLETE;
        }
      }
    }
  }
  /* Return the FLASH Status */
  return flashstatus;
}

 

 Specifically, it is checking the SR register with mask EF. Looking at datasheet it means that we are taking into consideration also the reserved bits an the bit 0.

I created an other project using stm32cubeIDE version 1.15.0 and found out that in the new version of library the implementation is a bit different

 

if(__HAL_FLASH_GET_FLAG((FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | \
                           FLASH_FLAG_PGPERR | FLASH_FLAG_PGSERR)) != RESET)

 

The library does not check reserved bits and does not check EOF bit.

So, what bits should I check?

With debugger I read the content of SR register and the value is 0xC0 which means that I have the PGSERR and PGPERR bits set to 1.

Now, If I ignore that 2 bits everything work as expected and the flash get protected but I need to understand If I can safely ignore them and why that bits are set? The procedure I'm performing should be correct.

Is there something documented in some ERRATA?

Thanks for the answer.

Marco. 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Yes, clear those flags and use the intended HAL_FLASHEX_* functions.

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

View solution in original post

4 REPLIES 4
TDK
Guru

The debugger can do things that cause PGSERR and PGAERR to be set when the program starts. Clear those flags on program start if you want.

FLASH_OB_GetRDP and FLASH_OB_RDPConfig aren't meant to be called directly, but rather via HAL_FLASHEx_OBGetConfig/HAL_FLASHEx_OBProgram.

 

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

Hello I will try to log the flash register without any debugger interaction to see if this could cause the issue.

 

I will also try to find  HAL_FLASHEx_OBGetConfig/HAL_FLASHEx_OBProgram if are defined somewhere into the code.

So, your advice could be to make a reset of flags at the beginning?

Thanks,

Marco.

 

Yes, clear those flags and use the intended HAL_FLASHEX_* functions.

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

Hello, looks like that debugger was causing that bits to be set