cancel
Showing results for 
Search instead for 
Did you mean: 

EEPROM Emulation - Virtual Addresses

Andrew Neil
Evangelist III

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

AndrewNeil_0-1715945255193.png

 

AndrewNeil_1-1715945273599.png

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?)

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

9 REPLIES 9

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

@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
Senior

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

 

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
Evangelist III

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

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

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.

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


@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