Re: [riot-devel] SAM Flash Read-While-Write
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 0x0040 // 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
Il giorno mer 30 gen 2019 alle ore 04:34 Federico Pellegrin
ha scritto:
>
> 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: 0x0040
> 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
>
>
> Il giorno mar 29 gen 2019 alle ore 22:50 Kees Bakker
> ha scritto:
> >
> > 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: 0x
> > Page size: 256
> > Number of pages:1024
> > RWWEE Flash start addr: 0x0040
> > RWWEE Number of pages: 8
> > > read_rwwee 0
> >
> > Context before hardfault:
> > r0: 0x2c24
> > r1: 0x0040
> > r2: 0x0100
> > r3: 0x
> >r12: 0x
> > lr: 0x381b
> > pc: 0x3f78
> >psr: 0x2100
> >
> > Misc
> > EXC_RET: 0xfffd
> > 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
> >
> > On 28-01-19 04:32, Federico Pellegrin wrote:
> > > 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
> > >
> > >
> > > Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke
> > > ha scritto:
> > >> 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
> > >>
> > >> Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin
> > >> :
> > >>> 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 sam
Re: [riot-devel] SAM Flash Read-While-Write
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: 0x0040
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
Il giorno mar 29 gen 2019 alle ore 22:50 Kees Bakker
ha scritto:
>
> 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: 0x
> Page size: 256
> Number of pages:1024
> RWWEE Flash start addr: 0x0040
> RWWEE Number of pages: 8
> > read_rwwee 0
>
> Context before hardfault:
> r0: 0x2c24
> r1: 0x0040
> r2: 0x0100
> r3: 0x
>r12: 0x
> lr: 0x381b
> pc: 0x3f78
>psr: 0x2100
>
> Misc
> EXC_RET: 0xfffd
> 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
>
> On 28-01-19 04:32, Federico Pellegrin wrote:
> > 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
> >
> >
> > Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke
> > ha scritto:
> >> 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
> >>
> >> Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin
> >> :
> >>> 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
> >>> ;) 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Il giorno sab 26 gen 2019 alle ore 05:46 Federico Pellegrin
> >>> ha scritto:
>
> 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 ;)
>
> 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
>
Re: [riot-devel] SAM Flash Read-While-Write
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: 0x Page size: 256 Number of pages: 1024 RWWEE Flash start addr: 0x0040 RWWEE Number of pages: 8 > read_rwwee 0 Context before hardfault: r0: 0x2c24 r1: 0x0040 r2: 0x0100 r3: 0x r12: 0x lr: 0x381b pc: 0x3f78 psr: 0x2100 Misc EXC_RET: 0xfffd 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 On 28-01-19 04:32, Federico Pellegrin wrote: 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 Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke ha scritto: 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 Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin : 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 ;) 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 Il giorno sab 26 gen 2019 alle ore 05:46 Federico Pellegrin ha scritto: 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 ;) 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 Il giorno ven 25 gen 2019 alle ore 09:21 Dylan Laduranty ha scritto: 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 :) 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
Re: [riot-devel] [riot-users] RIOT-os meet-up at FOSDEM
Hi, I'll be at FOSDEM (and day before / after to some fringe events) and would be glad in case to meet some of you RIOTers, even more if the topic rotates around boot and update as I'm very interested in using and contributing to the topic! For me the day/time is quite indifferent, as there is always something interesting going on @FOSDEM so it's impossible to find a really "free" spot :) Just announce the time and place and I'll do my best to attend! If someone coming has stickers/shirts to bring, I'm on the list ;) Cheers, F. Il giorno mar 29 gen 2019 alle ore 15:43 Emmanuel Baccelli ha scritto: > > Hi Koen, > I won't be at FOSDEM, but based on recent email exchanges, it seems Daniele > will be around. > (and maybe you could have happy discussions about bootloaders, SUIT etc. ;) > Cheers > Emmanuel > > On Tue, Jan 29, 2019 at 1:30 PM Koen wrote: >> >> Hi all, >> >> As I will be visiting FOSDEM again this year, I was wondering if there >> are more people from the RIOT-os community attending. From what I've >> read, there won't be a RIOT-os stand this year, but if there is some >> interest for a small meet-up anyway, I can try to get us a timeslot in >> one of the BoF rooms. >> >> Please let me know if you would like to meet up at FOSDEM and whether >> you have a strong preference for either saturday or sunday for the meet-up. >> >> Cheers, >> Koen >> >> >> ___ >> users mailing list >> us...@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/users > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] [riot-users] RIOT-os meet-up at FOSDEM
Hi Koen, I won't be at FOSDEM, but based on recent email exchanges, it seems Daniele will be around. (and maybe you could have happy discussions about bootloaders, SUIT etc. ;) Cheers Emmanuel On Tue, Jan 29, 2019 at 1:30 PM Koen wrote: > Hi all, > > As I will be visiting FOSDEM again this year, I was wondering if there > are more people from the RIOT-os community attending. From what I've > read, there won't be a RIOT-os stand this year, but if there is some > interest for a small meet-up anyway, I can try to get us a timeslot in > one of the BoF rooms. > > Please let me know if you would like to meet up at FOSDEM and whether > you have a strong preference for either saturday or sunday for the meet-up. > > Cheers, > Koen > > > ___ > users mailing list > us...@riot-os.org > https://lists.riot-os.org/mailman/listinfo/users > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT-os meet-up at FOSDEM
Hi all, As I will be visiting FOSDEM again this year, I was wondering if there are more people from the RIOT-os community attending. From what I've read, there won't be a RIOT-os stand this year, but if there is some interest for a small meet-up anyway, I can try to get us a timeslot in one of the BoF rooms. Please let me know if you would like to meet up at FOSDEM and whether you have a strong preference for either saturday or sunday for the meet-up. Cheers, Koen signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
