EEPROM Emulation - Virtual Addresses

[Andrew Neil]

Both X-CUBE-EEPROM and STSW-STM32117 (AN4061 - for STM32F0) use "Virtual Addresses" in the emulated storage:

But nowhere explains how these "Virtual Address" numbers are determined/decided.

It seems to me that (apart from 0x0000 and 0xFFFF being reserved)*, the choice is completely arbitrary - is that right?

The examples use "sparse" virtual address values - is there any advantage in doing that ?

Would there be any benefit in choosing values with maximum spacing - more "entropy" ?

EDIT:

* Both 0x0000 and 0xFFFF are reserved by X-CUBE-EEPROM;

Only 0xFFFF is reserved by AN4061 (presumably also by AN2594, AN3390, AN4056, and AN3969?)

[Tesla DeLorean]

As I understand it they are arbitrary, stored as metadata in a journal, and allowing for recovery of a subset of the entire virtual address space.

Personally I'd journal a configuration structure over doing it this way.

[Andrew Neil]

---

@Tesla DeLorean wrote:

Personally I'd journal a configuration structure over doing it this way.

---

Hmmmm ... maybe you're right.

The 100% overhead, and only being able to access individual 16-bit "items" does seem cumbersome.

I have mostly 8-bit data, and a number of strings.

So maybe something more like this: https://www.silabs.com/documents/public/application-notes/AN568.pdf ?

[Grant Bt]

Andy,

Assuming you really need the wear leveling, I found AN568 and AN798 both worth looking at. In my opinion, some of these are better for structures (AN568) and some better for individual bytes (AN798).

https://www.silabs.com/documents/public/application-notes/AN798.pdf

GB

[Andrew Neil]

Yes, I saw them & got the same impression.

I also saw their UG103.7 - "Non-Volatile Data Storage Fundamentals" – for their Cortex-M parts. It seems rather more advanced (complicated!).

[Andrew Neil]

@STTwo-32 for the ST implementations, can you confirm that the values of the  "Virtual Addresses" are, indeed, purely arbitrary?

[Florian LR · Accepted solution]

Hi @Andrew Neil , 

Yes these 3 values are arbitrary chosen. You can give them the value you want (in the X-Cube example the value are 1/2/3, etc.). 
The thing is that you can give the value you want, it can be useful if you want to give a value that means something in your application, but right there, that's totally arbitrary. 

I hope this helps, 

Best Regards, 

Florian LR

[Andrew Neil]

Thanks for clarifying that.

Having now looked at it for a while, I find the term "Virtual Address" unhelpful - maybe even misleading.

I think something like "Tag" or "Key" would be more appropriate.

[Florian LR]

Yes it can indeed mislead, we'll think about an other way of presenting this for future release.

Thank you for this feedback ! 

Florian LR

[Andrew Neil]

---

@Florian LR wrote:

Yes these 3 values are arbitrary chosen. You can give them the value you want (in the X-Cube example the value are 1/2/3, etc.). 

---

This applies to the AN4061 code for STM32F0, STSW-STM32117, but It seems that X-CUBE-EEPROM is different:

"the virtual addresses MUST be 1 to NM_OF_VARIABLES and therefore contiguous) for the PagesTransfer function to work"

https://community.st.com/t5/stm32-mcus-embedded-software/x-cube-eeprom-7-0-0-bug/m-p/729814/highlight/true#M55836:~:text=the%20virtual%20addresses%20MUST%20be%201%20to%20NM_OF_VARIABLES%20and%20therefore%20contiguous)%20for%20the%20PagesTransfer%20function%20to%20work