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
Il giorno mar 29 gen 2019 alle ore 22:50 Kees Bakker <k...@sodaq.com>
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: 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
>
> 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
> > <marian.buschsiew...@ovgu.de> 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
> >> <f...@evolware.org>:
> >>> 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
> >>> <f...@evolware.org> 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
> >>>> <dylanladura...@gmail.com> 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/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/eeprom.c
> >>>>>
> >>>>> Le mer. 23 janv. 2019 à 14:27, Federico Pellegrin <f...@evolware.org>
> >>>>> a écrit :
> >>>>>> 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)
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Federico
> >>>>>> ________________________________
> >>>>>> devel mailing list
> >>>>>> devel@riot-os.org
> >>>>>> https://lists.riot-os.org/mailman/listinfo/devel
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Dylan Laduranty
> >>>>> ________________________________
> >>>>> 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
> >>
> >> --
> >> Via mobile phone
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
