EEPROM Emulation library for STM32F1 -- Notice for a possible bug source.

[HamzaHajeir]

Hello STMicroelectronics, Great libraries and support all over the Internet.

I'm looking for EEPROM Emulation for my STM32 BluePill, And found the official documentation for that (AM2594) Which is a great document and well documented library.

Anyway I'm planning to use more than 2 pages to store my rapid changing variable. So started to reverse engineer the existing library to write a more general library (independent of # of pages).

While reverse Engineering : I found this little line that I can't understand as 'sensible' line :

It's in a routine for checking whether the page is fully erased or not.

While it compares the address passed with a Fixed defined Address PAGE0_END_ADDRESS.

So when the address passed is PAGE1_BASE_ADDRESS it would definitely fail! As PAGE1_BASE_ADDRESS is greater than PAGE0_END_ADDRESS.

Proposed solution to solve this issue is (whole function) :

uint16_t EE_VerifyPageFullyErased(uint32_t Address)
{
  uint32_t readstatus = 1;
  uint16_t addressvalue = 0x5555;
  uint32_t endAddress = Address + (PAGE_SIZE - 1); 

  /* Check each active page address starting from end */
  while (Address <= endAddress)
  {
    /* Get the current location content to be compared with virtual address */
    addressvalue = (*(__IO uint16_t*)Address);

    /* Compare the read address with the virtual address */
    if (addressvalue != ERASED)
    {
      
      /* In case variable value is read, reset readstatus flag */
      readstatus = 0;

      break;
    }
    /* Next address location */
    Address = Address + 4;
  }
  
  /* Return readstatus value: (0: Page not erased, 1: Page erased) */
  return readstatus;
}

Thank you!

[ALABSTM]

Hi Hamza,

Thank you for your feedback. We are very pleased to hear such positive comments from our customers and users.

Thank you also for this issue you pointed out and the detailed solution you suggested. We are also very pleased to have such constructive comments to help us enhance the quality of our software.

Your request will be forwarded to our development teams for analysis. We will be back to you as soon as they provide us with feedback.

Thank you for your patience and thank you again for your contribution.

With regards,

[ALABSTM]

Hi Hamza,

I hope you are doing well. Our development teams confirmed the issue you pointed out. They also agreed on the fix you have suggested with some minor enhancements (mainly the addition of a IS_EEPROM_PAGE_START_ADDRESS(__ADDRESS__) macro to check the address passed as argument actually corresponds to PAGE0_BASE_ADDRESS or PAGE1_BASE_ADDRESS).

Thank you once again for your contribution. Take care and stay safe.

With regards,

[ALABSTM]

ST Internal Reference: 85353

[HamzaHajeir]

Hi @ALABSTM ,

It's my pleasure to contribute in such a great project.

Noted with thanks :)

[HamzaHajeir]

Hi @ALABSTM, Is it released to the main streamline ?

[ALABSTM]

Hi @HamzaHajeir,

I hope you are fine. My apology, could you clarify your question please?

Thanks,

[HamzaHajeir]

Hi @ALABSTM, I meant it was around 9 months ago since the development team proposed the solution.

Wasn't it approved yet ?

[ALABSTM]

Hi @HamzaHajeir,

I hope you are doing well. Your request has been approved and already logged in our internal database. Actually, there were other issues we had to handle in priority. We hope to fix the EEPROM emulation application and make it available soon.

We do apologize for the delay and the inconvenience and we thank you for your patience.

With regards,

[ALABSTM]

Hi @HamzaHajeir,

I hope you are fine. We finally got the fix you proposed implemented and published via pull-request #40. Thank you again for your patience.

Please note, however, that the plan is to have EEPROM-related applications moved from the STM32CubeF1 firmware repo and from all others to the X-CUBE-EEPRMA1 repo. As you can see, 3 series are already supported (F4, G4, and L0). More are to be supported in the future, among which the F1 series.

With regards,