ATMEL / Microchip NVMCTRL SmartEEPROM

[Simon]

I've got to that point on a new chip where I need to store data.

My pic32cx-sg41 datasheet lists NVMCTRL SmartEEPROM in the non volatile memory controller. Like all good datasheets the explanation for this only probably only makes if you already know all about it  .

I probably still need to do some digging around but just in case I am wasting my time, anything I should be aware of?

As always I am bare metal programming. Obviously the only help I can find from microchip involves harmony or whatever it is called now and I will not be using "that", "thing".

[JPortici]

I guess.. an emulated EEPROM controller?

"SmartEEPROM raw data space:
The SmartEEPROM algorithm emulates an EEPROM with a portion of the NVM main.
SmartEEPROM raw data is mapped at the end of the main address space. SmartEEPROM
allocated space in the main address space is not accessible from AHB0/1. "

Then a bit later in the datasheet there is this section "27.5.8. SmartEEPROM" it seems descriptive enough

[Simon]

Yes it's one of those peripherals where there are a lot of references to different sections and it's a struggle to keep all this in my head as I search the datasheet up and down. Do I need to configure anything? or do I "just" write/read the virtual address space up to 64kB and the controller takes care of everything?

I have never used an eeprom and here there is the added fact that the memory space I am dealing with is also the main flash so has a dual use.

I'll try printing some pages so that I can lay them all out.

[Simon]

So the user row hold the size of the smartEEPROM, this seems to be set to 0, so i would still need to write NVMC code to read the data, modify it and write it back before I can use it.

[ataradov]

Do not use SmartEEPROM. It has no advantages over a manual NVM implementation, and it has a ton of disadvantages.

[Simon]

Oh, what are the disadvantages? Do they relate to any use? I am storing a structure with a few bits of data that need retaining for the next run so I guess it's not much different either way.

[ataradov]

There is no way to predict when it does erase operation, which would block execution from the flash. There is also no guarantee of data integrity if power loss happened during either erase or write.
There are also weird errata associated with it, so read them carefully.

Manual implementation is easy and it can be made to have predictable behavior.

I also wrote an appnote on implementing good EEPROM emulation on flash based devices - https://ww1.microchip.com/downloads/en/DeviceDoc/EEPROM_Emulation_for_Flash-Only_Devices_DS90003222A.pdf

[Simon]

This device has two flash banks and uses the opposite one for the writing. I only intend to save data when I shut down so I can check the smarteeprom has finished before pulling power, as I am battery powered this will have no time constraints.

I'll look at the errata.

[ataradov]

I don't remember the exact details, but dual banks don't help SmartEEPROM. It still blocks things randomly.

And it also makes dual bank feature less atomic. Normally it just flips one bit and it is done. But in case of SEE it transfers the contents before flipping the bit. This may not matter in your application, but something to keep in mind.

Anyway,  you have been warned. I've seen a lot of people try to use and run into random bizarre issues. And it was extremely hard to diagnose, since details of the internal implementation are not disclosed.

[Simon]

yea, I noticed they are cagy about what it actually does. I guess I should learn to use the SD card ports.

[ataradov]

Just use the internal flash directly, it is trivial. Here is example code that erases a block and writes the data: https://github.com/ataradov/bootloaders/blob/408f5018e7838034676c076a4e0a83703fcf706f/firmware/usb_dfu_samd51/main.c#L111-L131

SG41 is the same as D51, so the same code should apply.

[Simon]

The only errata I find for this chip says:

2.5.1 NVM Read Corruption
NVM reads could be corrupted when mixing NVM reads with Page Buffer writes.
Workaround
Disable cache lines before writing to the Page Buffer when executing from NVM or reading
data from NVM while writing to the Page Buffer. Cache lines are disabled by writing a one to
CTRLA.CACHEDIS0 and CTRLA.CACHEDIS1.

This affects revision A0 but not revisions B1 and B2.

Does this sound promissing or are there still going to be issues? This one would have affected the NVMC full stop.

[ataradov]

D5x/E5x errata "SmartEEPROM Buffered Mode is not Recommended" would also apply to at least some revisions. It is mentioned in the errata revision, but not in the document itself.

D5x/E5x is the same silicon as SG41.

[Simon]

What do you mean by "It is mentioned in the errata revision, but not in the document itself."

the issue you quote sounds like the one for the SG41 as well but it applies to the NVMCtrl as a whole. According to the SG41 errata document this was on revision A0 only. Is the A0 revision the D5/E5 silicon maybe? I'm just trying to understand, because if they are the same silicon what was applicable to just the smarteeprom seems to apply to all NVMC usage, on rev A0.

[ataradov]

What do you mean by "It is mentioned in the errata revision, but not in the document itself."

At the end of the document where it lists what changed in the errata itself, there is a section for "Revision B - 04/2022" and "The following Errata were added in this revision:" and it lists "NVMCTRL: 2.10.2 SmartEEPROM Buffered Mode". But this section is not present in the document itself. And 2.10 is not even about SEE, so some renumbering happened since then.

I don't remember the exact mapping, but I think A0 rev D of D5x and B1 is Rev G.

B2 may be new and may have fixed something. This whole renaming into PIC32 made things way more confusing.

It is also pretty clear that they did not transfer all the E5x errata into SG41 errata, even for the old matching revisions.

[Simon]

Ah yes I see, maybe they have the Atmel document history in the history revision and then carried on with the microchip part information.

Yes this insistence on renaming stuff is very silly. The AVR stuff became a mess as a tiny, mega and xmega (if they still used that brand) all became mega architecture. Trying to look for non part specific information about AVR's became harder as the same series now had different architectures. And the same with SAM and PIC32C, you will always get hits for PIC.

I assume that microchip did not make ARM based parts until they acquired Atmel and all ARM based parts are an evolution of the Atmel series.