Electronics > Microcontrollers

[SAM] "EEPROM" dealings

<< < (7/9) > >>

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version