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
