cancel
Showing results for 
Search instead for 
Did you mean: 

Help with HAL_FLASHEx_DATAEEPROM_Program() function on STM32L0

Tobias Witte
Associate II

Hello all,

I have a problem with the HAL_FLASHEx_DATAEEPROM_Program() function and maybe someone can help me. I am using an stm32L073. The address range oft he EEprom ist from 0x0808 0000 to 0x0808 17FF. I tried a simple test for writing to the EEprom like the following:

HAL_FLASHEx_DATAEEPROM_Unlock();

   HAL_FLASHEx_DATAEEPROM_Program(FLASH_TYPEPROGRAMDATA_WORD, 0x08080100, 0x12345678);

HAL_FLASHEx_DATAEEPROM_Lock();

This didnt work. So I start to debug. In the function HAL_FLASHEx_DATAEEPROM_Program() there is the following call:

status = FLASH_WaitForLastOperation(FLASH_TIMEOUT_VALUE);

In the function FLASH_WaitForLastOperation the program goes without timeout into the if statement if (__HAL_FLASH_GET_FLAG(FLASH_FLAG_EOP)) but the program runs also into the last if-statement and returns HAL_ERROR. I found out that the __HAL_FLASH_GET_FLAG(FLASH_FLAG_WRPERR) flag is set. So I looked into the reference manuel for the stm32L073 and read the folowing:

Write protection error flag (WRPERR)

If an erase/program operation to a write-protected page of the Flash program memory and

data EEPROM is launched, the Write Protection Error flag (WRPERR) is set in the

FLASH_SR register. Consequently, the WRPERR flag is set when the software tries to:

• Write to a WRP page.

• Write to a System memory page or to factory option bytes.

• Write to the Flash program memory, data EEPROM or Option bytes if they are not

unlocked by PEKEY, PRGKEY or OPTKEY.

• Write to the Flash program memory, data EEPROM or Option bytes when the RDP

Option byte is set and the device is in debug mode or is booting from the RAM or from

the System memory.

When I out command the __HAL_FLASH_GET_FLAG(FLASH_FLAG_WRPERR) everything is fine and the 0x12345678 value is written the to address 0x08080100. Do someone know why the WRPERR-Bit is set? I thought with the HAL_FLASHEx_DATAEEPROM_Unlock() call the EEprom is free for write access.

Regards

Tobias

3 REPLIES 3
bdanf
Associate

Not an answer, but found same problem. Made same change to FLASH_WaitForLastOperation() in file stm32l0xx_hal_flash.c (for stm32l071cb device). Comment out single line __HAL_FLASH_GET_FLAG(FLASH_FLAG_WRPERR) in ORing of err bits. Also note SR read back as 0x080023DD.

Tried other code to reset err flags in project file by direct writes to SR after call to HAL_FLASHEx_DATAEEPROM_Unlock() and before call to HAL_FLASHEx_DATAEEPROM_Program. This did not resolve problem.

Need to keep project moving, not going to dig further into this issue. Correction works.

colinh
Associate II

If you need to fix this correctly I think I may have the answer (apologies if it's 2 years too late - I discovered your post while researching the same issue)

I am guessing you have some variables declared in your EEPROM space? The compiler will try to initialise them as part of the c startup code causing a WRPERR.

If so, you need to add a __no_init to the variable. There is also a "do not initialize" linker option but I haven't tried that yet.

example:

__no_init uint16_t config1 @ ".eeprom";

dmeehan
Associate

I found that using:

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_WRPERR);

Prior to unlocking the NVM was sufficient. I didn't investigate the reason for the WRPERR and it only appeared to be present when FLASH_TYPEPROGRAMDATA_WORD was used, using BYTE program didn't seem to be affected.