sam0 flashpage_write: correct translation from RIOT pages to CPU pages writing#10069
Conversation
8824e06 to
d77c280
Compare
|
@jcarrano : formatting should be fixed, sorry for that. Codacy should also be better now, an earlier casting is needed since no arithmetic can be done with void*. As for test: it is not immediate but I did if using the OTA firmware update at: https://github.com/kYc0o/RIOT/tree/wip/rebase/ota_work_branch The number 4 actually is hardcoded also in the header file mentioned, but yes maybe it could be made a define and used where needed: |
Destructive in the sense that it wears flash? In that case flashing the test binary is just as destructive. |
|
@jcarrano |
I don't want to write stuff in a terminal. I want to push for PRs that test themselves and contribute to enhance the RIOT test suite. That means automated tests. I do not object if somebody wants to test it manually, though. |
I understand your PoV but this is out of the scope of this PR. |
I see this as a good candidate for its own PR => just add an |
|
Hi, -) Without patch: You see the write fails explicitly and just the last part of flash is written while the rest is 0xff which means just erased. -) With patch applied: So seems to work (of course I just tested on my saml21-xpro). Regarding automated test: I totally agree there should be some. I will try to study a bit myself the test part of RIOT (I'm rather new, need some time :) ) and see if I can contribute something in that direction! Thanks for comments and insights! |
|
@aabadie :
I've looked around the source tree and didn't see any other similar example already in place. If there is one could you point me at it? |
|
@fedepell, have a look at the The python script is run using the So the idea would to call the |
|
There is an automated test now: #10106 is merged. Please rebase and adapt the testing procedure of this PR. |
c000a45 to
4824caf
Compare
|
@aabadie : I rebased to master and corrected the testing procedure, hope it is fine. Regarding @jcarrano request about removing that "4": I would give that a look in depth asap, but should we tackle it as a separate PR since it's something that was there already before (to make that change more traceable and not mixed into this one)? |
bd042b1 to
6778004
Compare
0c7f036 to
4e5e811
Compare
|
I tried to clean up a bit the PR this morning, hope it's getting better. @jcarrano : I have removed the magic 4 and put a define instead and improved the comments (the old comment was actually stating the opposite). I also corrected a bit the code formatting. About the fact that this "4" could be in principle any number: at the moment the code makes quite an assumption that this number is 4. To make this number easily changeable we should take into account that at least: I did a manual test on 8/512 (with two erases) and then it works but this is not a generic solution and I'm not sure it makes sense to implement one. 4 is quite hardware optimized (given that 4 pages on SAM0 are a row) and I don't see any performance improvement in going on higher multiples (given the size of flash we have, could make sense if we had very big flash memories). Thanks! |
|
@dylad : sorry for the delay, didn't have the board with me in daytime today :) So all clear now! The test_last_raw does the write with flashpage_write_raw but does not erase the page first, therefore the write de facto fails (but there is no reporting back about this, since you can only know it failed if you re-read and compare). If you first erase the page then everything works fine. This explains why test_last works: in that case flashpage_write is called which first erases the page, then writes with flashpage_write_raw (in the new loop that was modified by this PR). So the code of this PR should be fine I believe, what should be fixed is the test (put an erase before the call to flash_write_raw). Question: should I do this in this PR (with a separate commit) or a separate one or what do you suggest is the best? Here is the output showing what I wrote above: Thanks! |
|
@fedepell I'm fine with another commit here since this is not a 'real' bug. Thanks for re-testing. I'll retry tomorrow on hardware. |
|
@dylad : added commit with the modification to the test_last_raw command. Hope everything will be fine now! :) |
|
@fedepell your fix works like a charm ! However I still get a kernel panic if I try to use the |
|
RIOT/cpu/sam0_common/periph/flashpage.c Lines 70 to 72 in 7196120 I think the < condition should be <= otherwise we cannot write the very last byte of flash.
|
|
@dylad : thanks for testing! You are absolutely correct, the assert needs to be >= to be able to write until exactly the last byte! I corrected, tested it succesfully and added a commit. Let me know if we should squash or not (would in principle say to keep the 3 commits separated as they deal with different issues, so it is easier to track in the future, but let me know!) |
|
@fedepell Keep it that way, it's perfect. I'll re-test again. |
6e645b1 to
9082675
Compare
|
(sorry, force pushed since I made the comment shorter for Murdock ;) ) |
|
Could you squash the last commit so we keep 3 commits please ? |
803dced to
b8b8ffd
Compare
Done! |
dylad
left a comment
There was a problem hiding this comment.
All comments have been addressed. Successfully tested on SAML21-XPRO.
Murdock is happy -> Here we go !
|
@fedepell Thanks for your good work ! |
|
Great! Thanks to you @dylad and everyone that partecipated! :) |
Contribution description
Solve erroneous writing on flash with sam0 boards because of wrong assumption of page sizing. Discovered on a saml21-xpro board.
A "RIOT page" is 256 bytes but a physical page on sam0 is 64, therefore the write has to be translated into four 64 writes.
Testing procedure
The automated test
tests/periph_flashpagecan be used to verify the correctness of the PR.Issues/PRs references
Fixes: #10068