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;
- The __NOP() that was added in #8518 is now remooved.
- When DBG_STANDBY, DBG_STOP or DBG_SLEEP are set in DBG_CR a hardfault
occurs on wakeup from sleep. This was first diagnosed in #8518. When
enabled, a hardfault occured when returning from a branch to irq_restore()
we avoid the call by inlining the function call. See #11830 for more
details.
- Since the Vector table must be naturally aligned to the next power
of two of the amount of supported ISR, and the table will be
placed after riotboot_hdr, we must ensure RIOTBOOT_HRD_LEN has the
same alignment.
If the .noinit section starts at the beginning of the RAM,
a bootloader that is unaware of it will clear it.
Instead, move it behind the .bss section, hoping that a bootloader
will always use less .bss memory than RIOT proper.
Make it possible to specify a section of RAM that is not touched by
the init routing so data can be kept across resets.
This should behave the same as on atmega & lpc2387.
gcc9 started realizing that _sram is basically an uint8_t[1] and thus
HARDFAULT_HANDLER_REQUIRED_STACK_SPACE cannot be added to it without
exceeding the one-sized array.
This commit casts _sram to (uintptr_t) where that happens.
A second slot is defined with a calculated size, from the
remaining flash after the bootloader and the first slot.
Both slots are defined as equal size, but it can be overriden.
RIOTBOOT_SLOT_LEN is calculated as an hexadecimal value and
handles ROM_LEN defined as kilobytes like '512K'
This enables support for all the cortex-m0+/3/4/7 arch,
so most boards embedding these are potentially supported.
One needs just to ensure that the CPU can be initialised
at least twice.
Co-authored-by: Gaëtan Harter <gaetan.harter@fu-berlin.de>
This new function allows to jump to another execution
environment (VTOR) located at a certain (aligned) address.
It's used to boot firmwares at another location than
`CPU_FLASH_BASE`.
The user needs to ensure that the CPU using this feature
is able to be initialised at least twice while jumping
to the RIOT `reset_handler_default` function, since it
initialises the CPU again (calls cpu_init()).
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Refactor cortexm_init to allow bits and pieces of
it to be called separately, while retaining the
current API, too. Needed for non-standard
Cortex-M initialisation, such as with nRF52
SoftDevice.
Allow defining a specific rom length to use for linking the firmware,
_fw_rom_length, instead of the default configuration to use the whole rom from
_rom_offset to the end.
* Add cortexm_common/Makefile.include FW_ROM_SIZE configuration
* Add an assertion that _fw_rom_length still respects _rom_length
Define _rom_offset with a conditional evaluated at execution time to allow
setting it in compilation rules and generate in the same make instance different
elf files with different configurations.
Before this change, if one tried to build a Cortex-M0+ target that had
an MPU, compilation would fail due to missing
'SCB_SHCSR_MEMFAULTENA_Msk' in SCB structure. Cortex-M0+ is a ARMv6-M
arch (unlike most other targets that have MPU support). ARMv6-M has more
limited support for fault conditions, see ARMv6-M Architecture Reference
Manual, D3.6.2.
