cpu/saml21: Make Low-Power SRAM available to programs#11486
cpu/saml21: Make Low-Power SRAM available to programs#11486dylad merged 6 commits intoRIOT-OS:masterfrom
Conversation
dylad
left a comment
There was a problem hiding this comment.
Great PR ! This is something I wanted to do for a long time. Thanks, I'll give it a try this week.
jcarrano
left a comment
There was a problem hiding this comment.
I think this is a nice feature to have. The main problem now is that variables placed in .backup will not get initialized (either with a value of zeroed out) which can be quite a surprising behaviour for users. I tried it on a saml21-xpro)
Solutions, from worst to best:
- Leave it as is, document it.
- Place code in startup to unconditionally zero out the whole section. Document it.
- Replicate the
.dataand.bssscheme in LPRAM.
(2) and (3) require modifying the startup sequence, but IMO make this feature friendlier and more usable. I'll look up if there's a simple way of implementing (3).
Also, there should be a feature test available for this.
|
@benpicco I PR'd against your branch. |
ce8caca to
6b193bb
Compare
|
@jcarrano I've merged your branch and moved most of it to common code. |
No need to do everything in one PR. In fact, it will go faster if we merge things little by little. |
|
Looks good. I'll test it as soon as I can get a saml21. On another note - and this is a topic for another PR- I think that this approach of making the liker aware of backup memory regions is useful even when that memory is not transparently usable. I'm referring to chips like the TM4C123. That part has 64 bytes of battery backed memory that can't be read like normal memory because it lives on a different clock domain. Even then it is still convenient to declare that region in the linker, as it allows different components of an application to claim a portion to themselves without worrying about overlap and without having resort to centrally defined mapping (like in a header). |
jcarrano
left a comment
There was a problem hiding this comment.
In the commit description it should say .backup.data instead of .backup.bss,
static uint32_t persistent_counter attribute((section(".backup.bss"))) = 1234;
|
I reworded the commit message. |
20251aa to
565c0bd
Compare
|
@jcarrano ping |
|
bad news, test doesn't work. And no more output, impossible to reset or flash, I can only unplug/replug and test get stuck again. I'll try to find some times to check what happen. |
dylad
left a comment
There was a problem hiding this comment.
I took a quick look into datasheet. Seems like LP SRAM is NOT retained in backup mode.
fa73241 to
ea011a7
Compare
dylad
left a comment
There was a problem hiding this comment.
I guess this PR is almost good to go !
Just some comments
tests/periph_backup_ram/main.c
Outdated
| /* Some tools have trouble flashing MCUs in deep sleep. | ||
| * Wait a bit to make re-flashing / debugging easier. | ||
| */ | ||
| xtimer_sleep(3); |
There was a problem hiding this comment.
This traditional delay is troublesome because you're suppose to see the counter increments by one every second but currently this is not the case.
There was a problem hiding this comment.
you're suppose to see the counter increments by one every second
Says who? 😉
I've added some output to clarify the delay periods.
It's really annoying when you have OpenOCD and your MCU enters deep sleep with no delay - there is no way to re-flash it. (If you're lucky you have JLink or edbg. But I'd rather save the unsuspecting Raspberry Pi GPIO users the cursing.)
There was a problem hiding this comment.
I don't mind keeping this delay but at least update the printf so users wont think this test is too slow ;)_
| } else if (counter_noinit == counter) { | ||
| puts("WARNING: non-backup memory retained - did we really enter deep sleep?"); | ||
| } | ||
|
|
There was a problem hiding this comment.
My personal taste would have place #ifndef CPU_BACKUP_RAM_NOT_RETAINED here so SAML21 platform doesn't display the counter before saying "aborting test". You may ignore this comment if you're fine this way.
There was a problem hiding this comment.
I think we should at least once access that memory to make sure it doesn't crash & burn when doing so.
c3e317e to
a972644
Compare
tests/periph_backup_ram/main.c
Outdated
| struct tm time; | ||
| rtc_get_time(&time); | ||
| time.tm_sec += SLEEP_SEC; | ||
| mktime(&time); |
|
please squash ! |
It is often useful to know whether the CPU was just powered on afresh or if it was woken from a deep sleep state, e.g. by RTC or GPIO event.
Many MCUs contain some Backup or Low Power SRAM that is retained'even
in the deepest sleep modes.
In such sleep modes the MCU is essentually turned off with only the RTC
still running.
It can be woken by a GPIO or a RTC alarm. When this happens, a reset is
triggered and the normal startup routine is invoked.
This adds bss & data section for this memory in the linker script.
This allows for structures to be placed in it e.g.:
e.g.:
static uint8_t persistent_buffer[64] __attribute__((section(".backup.bss")));
static uint32_t persistent_counter __attribute__((section(".backup.data"))) = 1234;
SAML21 provides 2/4/8 kiB of Low Power SRAM that is retained in backup mode. This adds definitions to make that memory availiable to RIOT.
The test will put a device to sleep, then wake it up to see if the backup memory was retained.
A pointer to read-only ROM data should be const.
|
squashed. |
dylad
left a comment
There was a problem hiding this comment.
Provided test works as expected on SAML21 and SAME54
|
Thank you for the review and testing! |
Contribution description
SAML21 contains up to 8 kiB low-power SRAM that can be retained during deep sleep modes.
This adds a section for this memory in the linker script, so structures can be placed in it by giving them the
__attribute__((section(".backup")))e.g.:
Compile-tested only, run-tested on same54-xpro which also has 8 kiB of Backup RAM.
Testing procedure
Issues/PRs references
I'm doing the same in #11305 as SAMD5x has a very similar feature (Backup Ram instead of Low-Power SRAM but the idea is the same).