[SAM] "EEPROM" dealings

[Simon]

So what is the purpose of the RWEE section? is this the 4kB on my SAMC21J17 ? The fuse settings let me allocate up to 16kB to "EEPROM" which comes out of the main flash (128 kB in my case so I could have as little as 112kB)

[ataradov]

You can write RWEE section while program is running from the main flash, so execution of your program is not blocked while emulated EEPROM is written.

You can use however much you like for the EEPROM in the main flash, you can completely ignore that user row setting and just keep it disabled. It does not do much of anything.

[Simon]

OK, so if you read the datasheet, you will find that it confuses the main NVM space allocated to EEPROM emulation with the dedicated write while read space. Sorry but not good enough. It's a mess, you have to make multiple passes at this trying to remember statements that seem innocuous because suddenly later they mean a lot.

It calls the RWWEE array EEPROM emulation and it calls the allocable amount of main NWM array EEPROM emulation. I don't actually understand why there are the two sections other than this being a trade off for those that want to store a lot of stuff exceeding the "EEPROM" space so get to use up to 16kB of the main flash space but as this also "emulates EEPROM" suddenly we don't know which bit of space we are taking about.

The address register makes it more of a mess because now instead of just sticking the 32 bit address in there of where you want to do something to you have to figure out where this bit is and put it's offset in using the right command......

I've spent several days on this, and most of the issues was understanding where exactly am I trying to write to. Much is left to the imagination. No I don't have prior experience, but if all data-sheets are like this I have little chance of getting any.....

Next up the utter mess made in the ADC register description.

[ataradov]

All datasheets are confusing in one way or the other. The goal is to not complain (because there won't be a fix), but to train yourself to read and extract the necessary information from what you have. In many cases you need to recognize and mentally skip BS. I personally did not even know that it mention EEPROM that much until this thread forced me to read the datasheet closely.  I know that no modern MCU has EEPROM and no modern MCU will ever have true EEPROM, as it is fundamentally incompatible with manufacturing processes. So, anything "EEPROM" would be emulation to a certain extent, so your goal is to figure out to what extent.  And it does not take a lot of time to recognize that in case of this device it is almost none, so you can just assume you are working with the flash.

And this is the best case scenario. SAM D51 has more of a hardware-driven EEPROM emulation, and it is a total mess. Thankfully you can bypass and not use it.

As far as how address is specified - different flash controllers have different APIs, and from a lot of experience, this one is one of the better ones.

RWEE section is not present on all devices, it was added later as a way to avoid blocking while flash is written. It probably adds to confusion, but again, it is not that uncommon to have strange flash partitioning. There are some really confusing and complicated schemes out there. And there are good reasons why things are done this way, and you have to figure out a way to live with them.

[Simon]

I have no knowledge of EEPROM, I don't care what it is in this context and never needed to know, but apparently I have to build on it as an artefact of history to understand the datasheet.

As far as I am concerned as a new comer to this stuff I have a micro-controller and it can store stuff when it is powered off, that is all I care about. I don't care for historic terminology that will only help me if I know about stuff that is actually not relevant to the product at hand but gives some a warm fuzzy feeling 

So the RWE section or whatever it is called was added when? is this something that I need to be careful about when buying these chips? like was it added after first release as a revision or do all SAMC21......  have it? I wouldn't think that they would make such a significant change so it sounds like we are caught up in history again  .

[ataradov]

That's why it is actually useful to know history. A lot of design of modern stuff is directly influenced by things first appearing in the 70s. You can complain about this, but it will not change the facts, so it is much easier to understand why things the way they are. And hardware designers and datasheet authors will assume some familiarity with the industry standards. There are probably more educational books on the topic. The datasheet is a technical document never intended to be understood by people completely unfamiliar with the subject.

All C20/C21 have RWW section (size varies with memory variant). Some other similar devices do not (D20, some versions of D21).

[Siwastaja]

In this case, not knowing what EEPROM is, is actually helpful, because the device has no EEPROM .

There's nothing fundamentally wrong with that datasheet, it's just a tad more complicated than it needs to be. But it shouldn't take days or weeks to decipher. Just understand the basics of FLASH as I explained in above reply, and decipher their terminology. Find what are the smallest erasable and writable units. Work from there.

[Simon]

So I've come back to revisit my previous experiment and now armed with which section is actually which I am trying to work with the RWWEE section this time. I see that again things are not quite going to plan. The command to erase the RWWEE section is 0x1A but this is also the start of the previous reserved range of numbers that do nothing. Could it be that the start of that reserved range was meant to be 0x10? Following on from the 0x0F before it? not sure why they didn't have one section of reserved numbers but I suppose it's a case of the datasheet being "assembled" for different chips with similar documentation.

Still mystified about it. I suppose the next possibility is that the RWWEE section does not support the automatic page write on writing to the last address? As always vagueness forcing assumptions that one thing applies to another combined with small portions of highly specific wording in the datasheet leave me non the wiser when it is not all spelled out as to which 3 sections of NVM space any statement applies to.

I'll probably have to use the main NVM space for now if I can work out how to erase that. I take it the address register must really be set to 0x0 if I want to erase the first RWWEE section? I think the reason things seemed to work with the main NVM is that it starts at 0x00000000 so I will always be using the actual global address in the address register for things like erasure

[Siwastaja]

It's clearly a typo, should be 0x10 as you say.

[Simon]

Right so I am back up and running saving data to the main NMW space. But..... if I trigger the write to memory from an interrupt when power down happens it does not retain the data. I saw some vague mention of this online. It is certainly not an issue with power as I retain power for quite some seconds (10 maybe) with numbers on the screen. I turn the backlight off when the interrupt first fires to save power then write to memory, except I don't.

Is there a way around this? The only thing I can think of if it literally cannot write to memory from an interrupt is to use the interrupt to turn off anything using power as I planned, then return to the main program with a flag set. The flag variable is constantly tested in the main while loop so given the seconds I have of stored power to the ms I need to save data I should be able to save the data in time.

[ataradov]

This is just a typo. You can at least download the vendor header files that have all those things enumerated. In most cases if there is a discrepancy between the datasheet and a header file, the header file is correct.

But also, what stops you from trying a few things and checking which one works? Even based on the info with a typo, there is only one reasonable assumption here. All you need is test it.

I don't understand the question about interrupt stuff. If the write completes in time before the power dies, then the data will be retained. If the write does not have enough time to complete, then it will not be preserved. The write takes time, it is not an instant process.

[Simon]

i can't do a write from an interrupt routine. So I use the non maskable interrupt to do housekeeping when power is pulled and using capacitance it saves the data. But if I call my data saving from the interrupt routine it will not work. It does work if I set a flag instead and return to the main program where I see the flag and do a data save.

I have found that not always all values are written out in the header files. the files of the atmel start stuff I downloaded did but not the files called by including samc21.h, these tend to be a bit more minimal.

[ataradov]

There is nothing special about running from the interrupt, so something is wrong with your code. Hard to tell what without looking at the code.

[Simon]

Well same code, I can post something tomorrow, the same function to write to the NWM will run from the main program but not from the interrupt routine, so it is not the problem and everything else in the interrupt routine works so it does fire. I am writing to the main memory space not RWWEE, maybe that was partly the point of the RWWEE ?

[ataradov]

Interrupt code is the same code. Nothing in the MCU state changes significantly when an interrupt is executed.

Writing main flash array by the code running from that flash will block execution for the duration of a write. But it should not cause any issues directly, all it will do is make the loop that waits for the flash ready bit run only once - it will block immediately after the command, and execution will unblock when the flash is ready.

Run it under the debugger and step though the code. What is the memory contents before and after the flash command is executed?

[Simon]

Uh, yea, I need to learn to to the debug thing. But as the data is not retained at power on clearly the flashing of the data does not happen and the value I tested with was the first. as soon as I put the write to flash routine in the main program it retains the data.

[ataradov]

You can at least read out the device memory before and after and compare them. This is trivial, just do it.

There is no difference between running from the interrupt handler and the regular code. You will have to share your code, I have no idea what is going on.

[Simon]

Well I display the numbers store on a screen so I have effectively already done that, inside the interrupt it does not update. Outside of the interrupt it does. Once this project over I'll have time to look at using the debugger.