Fixes to LPRAM linker script and prototype initialization code. #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Variables initialized to zero should go to .backup.bss (which is marked as NOLOAD). Variables initialized with other values to .backup.data. .backup.noinit is similar to .backup.bss except it is not initialized at boot. It can be used for data that should not be cleaned at reboot. Sections are now 32-bit aligned and 32-bit padded to allow fast 4-byte operations in initialization. WARNING: the code for initializing these regions is missing!!!.
Initialize .backup.data and zero-out .backup.bss. FIXME: this code should be conditional on backup ram being present!!! right now this causes compilation to fail on cpu that do not have it!!!
benpicco
reviewed
May 7, 2019
|
|
||
| /* FIXME: ifdef this!!!! */ | ||
| /* load low-power data section. */ | ||
| for (dst = _sbackup_data, src = _sbackup_data_load; |
There was a problem hiding this comment.
If we do this unconditionally it defeats the purpose of the backup RAM.
Luckily there is usually an arch-specific register that tells us whether we just woke from Standby/Deep Sleep.
I'd suggest we have something like bool cpu_woke_from_hibernate(bool clear_flag);
On stm32f4:
bool cpu_woke_from_hibernate(bool clear_flag) {
bool ret = PWR->CSR & PWR_FLAG_SB;
if (clear_flag)
PWR->CR |= PWR_FLAG_SB << 2;
return ret;
}
On saml21 & same54:
bool cpu_woke_from_hibernate(bool clear_flag) {
return RSTC->RCAUSE.bit.BACKUP; // TODO: no way to clear this?
}
There was a problem hiding this comment.
mmm, I see. I didn't have the complete picture. So, what you are saying is that when the MCU wakes up from Standby/Deep Sleep.the reset vector is invoked again, right? Then yes we need a check, and it also makes me wonder if .backup.noinit make any sense (I guess no).
This totally needs a test!
bool cpu_woke_from_hibernate(bool clear_flag);
mind doing a PR for that function only?
There was a problem hiding this comment.
Yes, in the deepest sleep mode no state is kept¹ - the system is essentially off and usually can be woken by a GPIO (if previously configured) or RTC.
[1] unless configured otherwise
|
Since we are touching common code now anyway (and that linker script gets more involved), I think it'd be better if we just add those sections to |
benpicco
pushed a commit
that referenced
this pull request
May 9, 2019
…onal sys: make uart_stdio RX optional (attempt #2)
benpicco
pushed a commit
that referenced
this pull request
Jul 26, 2019
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.
benpicco
pushed a commit
that referenced
this pull request
Sep 4, 2019
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
benpicco
pushed a commit
that referenced
this pull request
Feb 15, 2023
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>
benpicco
pushed a commit
that referenced
this pull request
Feb 23, 2023
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey ben, I attach some fixups I made to your PR.
Except the first PR, the rest are super rough, more like a proof of concept.
Let me know if you need some pointers with the FEATURE tests.