SAM Flash Read-While-Write

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 :wink:

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 :slight_smile:

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)

Thanks!

Cheers, Federico

Hello Federico,

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 :slight_smile:

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.

Cheers, Dylan

[1] https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/eeprom.c

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

As for now, RIOT uses blocking flashpage driver (https://github.com/RIOT-OS/RIOT/blob/master/cpu/sam0_common/periph/flashpage.c#L118)), so there will be no difference between using RWWEE and main flash at all. To utilize RWWEE advantage, driver must be interrupt-based.

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.

P.S. STM32L0 and STM32L4 with dual bank NVM have the same functionality — both banks can be read or one bank read and another bank written simultaneously. See AN4767 for details — https://www.st.com/content/ccc/resource/technical/document/application_note/group0/ab/6a/0f/b7/1a/84/40/c3/DM00230416/files/DM00230416.pdf/jcr:content/translations/en.DM00230416.pdf

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.

Hi Dylan and Oleg, Thanks for the feedback!

Sorry I meant kilobyte indeed, but always write it wrong, both the k-s (should be K I see now) and b-s :wink:

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)

Cheers, Federico

Hi, I did a mostly working (please see below for why mostly!) scratch of the implementation and put it here for now: https://github.com/fedepell/RIOT/commit/3b9de66ce0a9d722460c3b236ef67835df91cd90

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 :wink: 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!

Thanks!

Cheers, Federico

Hi,

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.

Cheers, Marian

Hi Marian, Sure, no problem. I just created a PR at https://github.com/RIOT-OS/RIOT/pull/10884

As it was still very early and uncertain how to structure I've started like this, but indeed maybe easier to keep track directly as a PR.

Thanks! Federico

Hey Federico,

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

Context before hardfault: r0: 0x20000c24 r1: 0x00400000 r2: 0x00000100 r3: 0x00000000 r12: 0xffffffff lr: 0x0000381b pc: 0x00003f78 psr: 0x21000000

Misc EXC_RET: 0xfffffffd Attempting to reconstruct state for debugging... In GDB: set $pc=0x3f78 frame 0 bt

ISR stack overflowed by at least 8 bytes.

What can that be? -- Kees

Thanks for testing first of all!

That sounds strange, I even see that you just did just the read test, which is basically:

void flashpage_rwwee_read(int page, void *data) {     assert(page < (int)FLASHPAGE_RWWEE_NUMOF);

    memcpy(data, flashpage_rwwee_addr(page), FLASHPAGE_SIZE); }

Is the RWWEE displayed info correct for the SAMD:

RWWEE Flash start addr: 0x00400000 RWWEE Number of pages: 8

I will get the datasheet now and check if there is some difference not obvious from the include files.

Cheers, Federico

Hi Kees, I gave a better look and I think the fact is that not *all* SAMD21 have the RWWEE, but just revision B and L, while not A.

I got the information from this ATMEL's application note: http://ww1.microchip.com/downloads/en/AppNotes/Atmel-32219-Differences-between-SAMD21-Variants-A-B-and-L_ApplicationNote_AT04470.pdf

Which revision are you using? As far as I see in RIOT the sodaq ones may indeed be As:

sodaq-sara-aff/Makefile.include:export CPU_MODEL = samd21j18a sodaq-explorer/Makefile.include:export CPU_MODEL = samd21j18a samd21-xpro/Makefile.include:export CPU_MODEL = samd21j18a sodaq-autonomo/Makefile.include:export CPU_MODEL = samd21j18a

In the include files we have in RIOT the defines I'm using are inside the generic samd so somehow were applying to all of them:

vendor/samd21/include/instance/nvmctrl.h:#define NVMCTRL_RWWEE_PAGES       32 // Page size vendor/samd21/include/instance/nvmctrl.h:#define NVMCTRL_RWW_EEPROM_ADDR 0x00400000 // Start address of the RWW EEPROM area

But I could add for a presence of NVMCTRL_RWW_EEPROM_SIZE which seems to be just in the chips that have it, ie:

vendor/samd21/include/samd21j16b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e15bu.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g15b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g16b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e15b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21j15b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g15l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21e16b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e16bu.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e15l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g16l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e16l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */

Cheers, Federico

Hey Federico,

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."