Hi,
Working on SAML21 based project it came to my attention also the
presence of an 8Kb additional flash that is called "Read-While-Write"
(or RWWEE in the datasheet) that, as far as I understood, can be
programmed and read in a very similar way to the normal flash. This is
currently not supported anyhow in RIOT as far as I see. This is also
present in other SAM chips (a grep on the RIOT sam0 common includes
tells me saml21, samd21 and samr30).
Well it's just 8Kb (in saml21 case) but a customer is asking about it
Before starting to fiddle with code I was wondering if any of you
already saw this or had intention to work on or had problems with this
or.... any information would be great
On the other side I would also be interested in an opinion if the
access to this facility should eventually be kept totally separate
from the current (with some possible code redundancy, but with the
possibility no to include it into a project) or could be integrated
into the current flashpage driver (bringing some complication of the
logic of the current code)
IIRC, this flash can be use as a virtual EEPROM. Maybe It would be better to write a eeprom driver (like STM32 [1]) rather than add it to the flashpage driver ?
I also think this memory is 8KB for SAML21J18 (not 8Kb), which is a lot
As a side note: SAML21 also have 8KB of Low Power SRAM in addition to its 32 KB of SRAM
I’ve never played with these additional memories but I’ll be happy to help.
The only difference between RWWEE and regular flash is that they implemented separate NVM controller for the RWWEE, so you can access it without blocking the main flash (and without blocking program execution if it is executed from flash).
In all other aspects, there’s no difference between RWWEE and main flash. If you need EEPROM emulation, same wear-leveling and read-modify-write algorithms should be implemented.
so there will be no difference between using RWWEE and main flash at all
Fix: except interrupt handlers.
If you have strict interrupt timings requirements and a lot of flash accesses, you should use RWWEE on SAML or second NVM bank on STM32L even with blocking flashpage driver.
Sorry I meant kilobyte indeed, but always write it wrong, both the k-s
(should be K I see now) and b-s
Regarding implementation:
To make it interrupt driven I guess it would be quite more a radical
change, so I would look at least for now for a blocking one, which
basically makes it just an additional flash area no different than the
main one.
About doing it similar to eeprom what I see, API wise, is that the
eeprom one you link (and eeprom in general) is not page based, while
the flash one (and also the RWWEE since the interface is the same) is
page based. So you need always to work with pages (erase especially).
So I would see it more indeed like the flashpage itself indeed. That's
why my doubts on having it separate or not, since mostly what changes
in the code would be the start offset, various limits now #defines
(such as FLASHPAGE_NUMOF) and some flags when accessing the CPU (ie
using NVMCTRL_CTRLA_CMD_RWWEEER instead of NVMCTRL_CTRLA_CMD_ER)
I tested it and it is working on my saml21-xpro board. I can write on
the 8KBs of RWWEE memory and read it and see that it is still there
after rebooting and stuff. I took care to make it compile also on
saml11 (define names are different) although I cannot test this. As
you will see the code is mostly a copy & paste of the standard
flashpage, with a bunch of different defines used (for base adresses
and registers).
As I presumed in previous emails, it looks kinda ugly to me, but I'm
not sure we could reuse totally the code without a major refactoring
or by making many if-s in the common code (even asserts would depend
on if we are using RWWEE or not) to keep them united (and therefore
less performant). Please give it a look and let me know what do you
think!
As for "mostly working" what is still puzzling me is that the code
seems to have some kind of alignment issue or so (although I take care
of using aligned memory structures are required) since if I add/remove
some statement it may then just hang or generate a hardfault. It is
quite puzzling me since I tried to rule out all possibilities but
cannot get it working. But maybe it's just that I'm stubbornly doing
this from some time and I need to detach from it mentally for a while
But since I have to go out in a while I wanted to commit it so if
someone wants to give it a look in the meantime, mostly refering to
the structural question of how to implement it, it is there on github.
And maybe someone has a general suggestion about this maybe-alignment
issue from previous experience!
do you mind to create a pull request for it? This imho would make discussion of the code easier. You can add [WIP] in the title to highlight it’s work in progress.
Thanks for doing the flashpage stuff.
I have some SODAQ boards, basically all SAMD21, that I use
to run the flashpage test.
Unfortunately, the test program crashes for read_rwwee
main(): This is RIOT! (Version: 2019.04-devel-16-gc2c6f-sam_rwee_support)
ROM flash read write test
Please refer to the README.md for further information
Flash start addr: 0x00000000
Page size: 256
Number of pages: 1024
RWWEE Flash start addr: 0x00400000
RWWEE Number of pages: 8
> read_rwwee 0
Yes, checking for NVMCTRL_RWW_EEPROM_SIZE seems to be a good
approach.
BTW. Be careful with using the term "revision". Where you mentioned A,
B and L, that is what Atmel calls "device variant" to denote functional
differences. There is also a die revision, which can be read from
DSU.DID.REVISION
To quote the datasheet:
"Bits 11:8 – REVISION[3:0]: Revision Number
Identifies the die revision number. 0x0=rev.A, 0x1=rev.B etc.
Note: The device variant (last letter of the ordering number) is independent of the die revision
(DSU.DID.REVISION): The device variant denotes functional differences, whereas the die revision marks
evolution of the die."
