STM32F7 EEPROM write Consuming too much time.

[Vicky-S]

I have tested the EEPROM, There is no problem in storing a value in EEPROM. But "EEPROM.Write" function takes more time to store the value. It takes more than 2 secs to write a byte of data in EEPROM. And processor hangs a bit while doing so.

EEPROM writes only one byte at a time but my variables are mostly 32bit long, So i have used the simple program to store the data. It works but its taking lot of time.

I have tested to store a single byte of data too. It also taking more time and processor is hanging a bit after calling the EEPROM write function. I can see that in Serial monitor of arduino, After EEPROM write function it prints one char at a time for few secs.

[Vicky-S]

Here is my code for reference.

#include<EEPROM.h>
#define CAL_ADDR    0x10
#define SETUP_ADDR  0x70
void cal_write()
{
  EEPROMWritelong(CAL_ADDR, Calib.Offset);
  EEPROMWritelong(CAL_ADDR + 4, Calib.Ref_count);
  EEPROMWritelong(CAL_ADDR + 8, Calib.Ref_weight);
}
void EEPROMWritelong(int address, long value)
{
  byte four = (value & 0xFF);
  byte three = ((value >> 8) & 0xFF);
  byte two = ((value >> 16) & 0xFF);
  byte one = ((value >> 24) & 0xFF);
  EEPROM.write(address, four);
  EEPROM.write(address + 1, three);
  EEPROM.write(address + 2, two);
  EEPROM.write(address + 3, one);
}

[Vicky-S]

The EEPROM write problem is still not fixed. It takes 39 secs to store the 40 bytes of data. Till that time i cant process anything.

[fpistm]

EEPROM emulation is mainly to store data that do not required to be write several times.
Ex for calibration data or a setting not for data logger. Flash has a limited number of write cycle.
I will check this issue when I will have some time, currently some other issues are more "urgent".
Write is functional even if it is slow. It should not be so critical for this kind of feature.

[fpistm]

Hi @Vicky-S
I've made some test and see some drawback about EEPROM emulation with F7 and probably other.

By defaut, the FLASH_BASE_ADDRESS is compute like this (FLASH_END + 1) - FLASH_PAGE_SIZE.
In our case, FLASH_PAGE_SIZE is set to #define FLASH_PAGE_SIZE ((uint32_t)(16*1024)) /* 16kB page */
This FLASH_BASE_ADDRESS is part of the last FLASH_DATA_SECTOR which is defined like this:
#define FLASH_DATA_SECTOR ((uint32_t)(FLASH_SECTOR_TOTAL - 1))

For F746NG, there is 8 sectors. The last sector is in fact 256kB.

So when you call EEPROM.write, the entire sector is erased then write can be performed.
Is your example you call 4 times the write so you erase 4 time the 256Kb.
I've made some tests:
With current implementation 4 writes take 12 second.
With the buffered implementation (See #333 from @hasenbanck) it takes 3 seconds (write on the flash is done only 1 time).
Finally with the buffered implementation and using the sector 3 of the flash (32kb) it take less than 900ms.

Anyway, I've never get 39s like you.

The buffered implementation will be merge.
Then I will allow to redefine the FLASH_BASE_ADDRESS, FLASH_DATA_SECTOR and FLASH_PAGE_SIZE in the variant, like this this could be customize per board and usage. The default mechanism to compute those define will be kept.
One drawback is the size defined is not always aligned with the sector size but this is the entire sector which is erase.
So for example in our case, you can access 16Kb but in fact 256Kb are partially used the other 240Kb are lost/unusable as always erased.
Define the size to 256Kb will be not good as the EEPROM is mapped in RAM:
static uint8_t tmpEE[E2END] = {0};
where E2END is the FLASH_PAGE_SIZE

Ex:

Sketch uses 14060 bytes (1%) of program storage space. Maximum is 1048576 bytes.
Global variables use 263256 bytes (80%) of dynamic memory, leaving 64424 bytes for local variables. Maximum is 327680 bytes.
Low memory available, stability problems may occur.

Moreover address is uint16_t so only 65Kb are addressable.

[Vicky-S]

Hi fredric,

Thanks for the response. In my example i want to store 32bit values but the EEPROM.write is a 8 bit function. So I Split the 32bit data into four 8bit data by shifting and done the same in EEPROM.read to obtain 32bt data from four 8bit data.

Please check my post I said it takes around 39 secs for 40 bytes of data, 40 bytes of data will take 40
EEPROM.write function.

Im waiting to test and use the buffered implementation.

[fpistm]

Hi Vicky,
ok, I only test one call of your function: void EEPROMWritelong(int address, long value)
The buffered implementation has been merged.
@hasenbanck has posted an example:
stm32duino/STM32Examples#7
Anyway, there is in fact no issue on EEPROM emulation on the flash.
As mentioned by @hasenbanck in his example comment:
Writing to a flash is very expensive operation, since a whole flash page needs to be written, even if you only want to access the flash byte-wise.
This take more time on F7 due to the sector size (256kb)

[fpistm]

FYI #338 will allow to redefine the FLASH sector to use.