Arduino_core_stm32: 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!