cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L151CB Internal EEPROM bugs out

MLorr.2
Associate II

Hello everyone,

For my current project, I am building a logger of sorts. Supposed to aquire data (from the ADC channels) over important time periods : looking for months of logging, with only a couple of notable events per week.

I was thining of storing such events on the internal EEPROM (4k), so they would be preserved in case power goes out. For that, I used the RM0038 and the HAL library on STM32 cube to write bits of code to read, write and clear EEPROM. (about 6 words per event)

I think I can successfully read it, with :

uint32_t EEPROM_Read_int32(uint32_t pos)

{

  uint32_t* uint32_pointer;

  uint32_t data;

  uint32_pointer = (uint32_t*) (0x08080000+pos);

  data = *uint32_pointer;

  return data;

}

I had decent success writing on it with

void EEPROM_Write_uint32(uint32_t pos, uint32_t data)

{

HAL_FLASHEx_DATAEEPROM_Unlock();

HAL_FLASHEx_DATAEEPROM_Program(TYPEPROGRAMDATA_WORD, 0x08080000+pos, data);

HAL_FLASHEx_DATAEEPROM_Lock();

}

But terrible luck with erasing data with

void EEPROM_Clear(uint32_t pos)

{

HAL_FLASHEx_DATAEEPROM_Unlock();

HAL_FLASHEx_DATAEEPROM_Erase(TYPEERASEDATA_WORD, 0x08080000+pos);

HAL_FLASHEx_DATAEEPROM_Lock();

}

When I want to clear EEPROM most of the time // when i want to write on EEPROM some times, the program just bugs out and I have to restart the card.

I assume it is because it is trying to write on already occupied words and clear empty words, but it does not work even with a check before using the read fonction.

Using step by step debug, it fizzles when I reach

"*(__IO uint32_t *) Address = 0x00000000U;"

Anyone has enough insight on EEPROM to help me solve this issue ?

Also, let me know if you wish more information.

This discussion is locked. Please start a new topic to ask your question.
4 REPLIES 4

What does "bugs out" mean in the context of where the processor is executing code?

Stuck in a while(1) in the Hard Fault Handler?

Best to have code in there that can output actionable data.

Alignment issues?

Something a watchdog would catch?

If you have a heart-beat interrupt toggling a pin, does that stop?

If interrupts still working, report address of code it is interrupting.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
TDK
Super User

What arguments are you passing? What are the HAL return values?

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

For the clear function, I for now enter a basic number, like "EEPROM_CLEAR(1);"

"HAL_FLASHEx_DATAEEPROM_Unlock();" correctly returns HAL_OK.

The function then calls FLASH_WaitForLastOperation(Timeout) which also returns HAL_OK

Then it goes to the line "*(__IO uint32_t *) Address = 0x00000000U;" and is stuck on this line, it does not go to a hardfault or ...

It just stays there. I get a E31 error when I try to pause the program.

The clearest I can be is that the program stops responding, as if it does not find the cell where it's supposed to write / cannot write to it.

It is not stuck on a while(1), nor it goes to the error handler.

I used LED's and live variables to find out where exactly it was going wrong.

I doubt it is alignment issues because reading data at the same adress works perfectly.