EEPROM usage hangs sometimes

[jgromes]

Hi, I'm trying to use this library together with EEPROM, but for some reason, calls to EEPROM methods (put/get) seem to hang when using LowPower - the following sketch hangs at EEPROM.put() and never reaches EEPROM.get() or another loop.

Board: Nucleo L452RE-P
STM32 core version: cloned from repo
Sketch to reproduce:

#include <STM32LowPower.h>
#include <EEPROM.h>

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
  LowPower.begin();
}

void loop() {
  // print stuff to serial port
  Serial.println("loop");
  delay(100);

  // sleep twice
  digitalWrite(LED_BUILTIN, HIGH);
  LowPower.deepSleep(1000);
  digitalWrite(LED_BUILTIN, LOW);
  LowPower.deepSleep(1000);

  // EEPROM put - hangs here
  Serial.println("eeprom put");
  delay(100);
  EEPROM.put(0, 0xFF);

  // EEPROM get
  Serial.println("eeprom get");
  delay(100);
  uint8_t val = 0;
  EEPROM.get(0, val);
  Serial.println(val);
}

Thanks!

[jgromes]

It seems to be the write operation that's causing the hangup. EEPROM.put();, EEPROM.write();, EEPROM[i] = value; and eeprom_buffer_flush() will all hang, while read operations are fine.

[fpistm]

This is not link to EEPROM.
Using debug in the optimization menu does not hang.
The main issue I guess is the deepSleep().
If we kept only the blink part, delay is not correct.
Unfortunately, I will not have time to check that soon. I put it in my huge list... 😭

[jgromes]

This is not link to EEPROM.

I respectfully disagree, hangup only appears when using both EEPROM and LowPower at the same time. When either one is removed, the sketch no longer hangs.

The main issue I guess is the deepSleep().

I don't think that's the case - the hang also appears when using idle(), sleep() or shutdown().

Using debug in the optimization menu does not hang.

Sorry, I'm not entirely sure what you mean there - could you please point me to some more information on this? Thank you.

[fpistm]

This is not link to EEPROM.

I respectfully disagree, hangup only appears when using both EEPROM and LowPower at the same time. When either one is removed, the sketch no longer hangs.

I told that because, as a first issue the low power mode seems not properly set, in that case before digging in EEPROM. This should be fixed to ensure be in a proper clock and power config.

The main issue I guess is the deepSleep().

I don't think that's the case - the hang also appears when using idle(), sleep() or shutdown().

That's what I said, there is an issue with low power mode.

Using debug in the optimization menu does not hang.

Sorry, I'm not entirely sure what you mean there - could you please point me to some more information on this? Thank you.

In the Arduino Tools menu: Optimize instead of Smallest choose Debug.

Anyway, even if it's not hangs the timing is not correct and rely on the fact Low Power mode is not properly set. I've tested RTC and the timing is correct so all drive me to issue with Low Power mode config.

[jgromes]

I will check using the debug menu, thanks. In the meantime, is there a workaround? For example, calling HAL functions directly or changing the configuration?

[fpistm]

Don't know. This will require some investigation. And as said I will not be able to dig into this soon. Any help are welcome.

[jgromes]

Seems the behavior depends on selected optimization, it hangs with -Os, but doesn't with -O1, -O2, -O3 and -g.

As was mentioned previously, the timing is off - LowPower.sleep(1000) only sleeps for about 650 ms.

[fpistm]

Hi @jgromes
Some update
@Yannick-Marietti met the same issue on an Disco L475VG.
But without LowPower bust simply calling the RTC begin and after a write to the EEPROM.
As the LowPower init the RTC, I guess this is linked.
It seems an interupt is raised while it should not:
RTC_WKUP_IRQn = 3, /*!< RTC Wakeup interrupt through the EXTI line */

I will have to investigate deeply.

[jgromes]

Thank you very much for keeping an eye on this issue. Please let me know if there are any updates, or if you need help with something (e.g. testing).

[ABOSTM]

Hi @jgromes ,
Problem is not linked to RTC, just a combination of circumstances:
Sometimes, eeprom_buffer[] address was aligned on 2 bytes (16 bits),
but due to cast on (uint64_t *) compiler uses a asm instruction LDRD to read Double word.
This instruction needs some 4bytes/8bytes alignment (depending on core/architecture used).
Misalignment cause hardfault.
It is now fixed

[jgromes]

That's absolutely brilliant, thank you so much!

[HappySamuel]

Hi

Is that mean EEPROM.write() from <EEPROM.h> is safe to use now? Does this apply the same to using on STM32F103Cx series?

Best,
Samuel

[ABOSTM]

Hi @HappySamuel,
Yes, bug is now fixed.
Even for STM32F103Cx

[HappySamuel]

Hi @ABOSTM , @fpistm

Is there a way to check how many times left for able to do EEPROM write for the STM32F103Cx series left??

Best,
Samuel

[fpistm]

Hi @HappySamuel
Unfortunately not. If you really need access several time to EEPROM, the best way is to use an I2C EEPROM, I guess.
Here the characteristic of the STM32F103Cx Flash:

[HappySamuel]

Hi @fpistm

Any suggested examples or libraries to use I2C EEPROM?

Best,
Samuel

[fpistm]

Hi @fpistm

Any suggested examples or libraries to use I2C EEPROM?

Best,
Samuel

https://www.arduino.cc/reference/en/libraries/exteeprom/

[HappySamuel]

Hi @fpistm

Thank you for the sharing. Will test it out when i have an I2C EEPROM.

Best,
Samuel