firmware swapping ported for nucleo-f411 #2
Conversation
…nt + add build target for the metadata-generator * programming manual says, that VTOR must be 512 byte aligned in Cortex M3, M4, M7 processors. Cortex M0+ (STM32L0) has 256 byte alignment, Cortex M0 (STM32F0) has a fixed vector table address.
|
Hi Jannik! Thanks for the PR. I was looking at it and there are some things that we need to change, but it looks already good! As you can see, some changes are on-going, so what I propose is maybe to split this PR into several parts, or, if you prefer, I can chery-pick the commits which are mergeable now and work on the rest later. Besides, I looked at you PR in RIOT upstream and I think it will difficult to merge it, as well as in this design I use RAM buffers to write the flash pages, which already quite large (2K per page on smt32f103re). So, in short, what I would propose is to take the parts which involve the configuration defines for stm32f4 and integrate them in a single PR which will include both defines, stm32f4 and stm32f1. What do you think? I'm investigating the thing about the 512bytes of metadata so maybe I'll make this general for all platforms. By the way, I already have a solution for OTA programming which I'll release soon, in case of you're working now on something similar. Thanks again! |
|
|
||
| MEMORY | ||
| { | ||
| rom (rx) : ORIGIN = 0x08004200, LENGTH = 0x1C000 |
There was a problem hiding this comment.
Why did you choose a different value for each slot?
There was a problem hiding this comment.
I have different sizes for each slot, because the sectored flash layout of the STM32F4 makes it impossible to have firmware slots with the same size.
The first slot will be smaller by the size of the bootloader space.
| bootloader: | ||
| @cd ../bootloader; \ | ||
| CFLAGS+=-DFW_METADATA_SPACE=$(FW_METADATA_SPACE) make clean all; \ | ||
| CFLAGS="-DFW_METADATA_SPACE=$(FW_METADATA_SPACE)" make clean all; \ |
There was a problem hiding this comment.
Why did you change this? Anyways, this Makefile will disappear.
There was a problem hiding this comment.
I changed this, because I had issues with your makefile. I used an Ubuntu 16.04 system to compile my RIOT projects.
|
|
||
| FEATURES_REQUIRED = periph_flashsector | ||
|
|
||
| USEMODULE += shell |
There was a problem hiding this comment.
This is a no-go, if you want to include modules you need to do it at the application level. Otherwise you can also do it at the dependency check level.
Edit: I didn't see it was for a test, this is valid.
|
As discussed in my pull request for the flash interface of "the other half" of the STM32 micro controllers, it would be a bit tricky to integrate these two types of flash memory.
You will have a better overview of you work and the longer experience developing for RIOT, so do what you think would be the best for the further development. By the way: I will not have quite a lot of time for further development of the compatible version, because my thesis has first priority. And the prototype I’m developing for my thesis has moved to a quite different approach, which will not be (easily) mergeable. |
…onal sys: make uart_stdio RX optional (attempt #2)
The evtimer_msg test is expanded to also delete entries. Furthermore the messages that are printed should now show numbers that are very close (if not equal). Something like this: At 740 ms received msg 0: "#2 supposed to be 740" At 1081 ms received msg 1: "#0 supposed to be 1081" At 1581 ms received msg 2: "#1 supposed to be 1581" At 4035 ms received msg 3: "#3 supposed to be 4035" The function evtimer_print is also called to show the intermediate status of evtimer entries.
The test randomly fails on `native` due to timers being not accurate but
it cannot be otherwise. So better disable it than raising fake errors.
main(): This is RIOT! (Version: buildtest)
Testing generic evtimer
This should list 2 items
ev #1 offset=1000
ev #2 offset=500
This should list 4 items
ev #1 offset=659
ev #2 offset=341
ev #3 offset=500
ev #4 offset=2454
Are the reception times of all 4 msgs close to the supposed values?
At 662 ms received msg 0: "#2 supposed to be 659"
At 1009 ms received msg 1: "#0 supposed to be 1000"
At 1511 ms received msg 2: "#1 supposed to be 1500"
Traceback (most recent call last):
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 33, in <module>
sys.exit(run(testfunc))
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/dist/pythonlibs/testrunner/__init__.py", line 29, in run
testfunc(child)
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 26, in testfunc
assert(actual in range(expected - ACCEPTED_ERROR, expected + ACCEPTED_ERROR))
AssertionError
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE
### Contribution description
The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.
### Testing procedure
Any application using MTD in conjunction with a board with an at24cxxx.
19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1
### Contribution description
Hi! 🦎
When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.
### Testing procedure
Before this patch:
Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
#0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
#1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
#2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
#3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
```
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.
Co-authored-by: Hendrik van Essen <hendrik.vanessen@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This should work the same way on all STM32F4 processors, if there is enough flash memory available.
This also adds a driver for sectored flash used in STM32F2, F4 and F7 microcontrollers. But the current implementation is only tested on STM32F411, but should work on all F4 nucleo boards.