19618: cpu/stm32: fix riotboot settings for L4 and WB r=benpicco a=gschorcht
### Contribution description
This PR fixes the `riotboot` configuration for L4 and WB.
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work at all. Furthermore, a minimum `RIOTBOOT_LEN` of `0x2000` is required for L4.
Found when investigating the compilation errors for `bootloaders/riotboot_serial` in PR #19576.
### Testing procedure
1. Green CI.
2. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
```
In master these commands give
```
0x400
```
With this PR these commands give
```
0x200
```
as expected.
3. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
```
In master these commands give
```
0x1000
```
With this PR these commands give
```
0x2000
```
as expected.
### Issues/PRs references
19639: tests/net/gnrc_mac_timeout: add automated test r=aabadie a=aabadie
19644: gnrc_ipv6_nib: include RIO with all subnets in downstream RA r=benpicco a=benpicco
19649: gnrc_sixlowpan_iphc: prefix bits outside context must be zero r=benpicco a=benpicco
19656: gnrc/ipv6_auto_subnets: allow to configure minimal prefix length r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19368: debug: add DEBUG_BREAKPOINT() macro, set breakpoint on failed assertion r=benpicco a=benpicco
19529: cpu/stm32/periph/dac: optimize setting DAC r=benpicco a=Enoch247
### Contribution description
The current implmentation right shifted the 16 bit value passed into `dac_set()` down to the 12 bits that the DAC is actually capable of. This patch drops the shift and instead writes the 16 bit value to the DAC's left aligned 12 bit wide data holding register.
### Testing procedure
do something like:
``` c
#include "perip/dac.h"
int main(void)
{
dac_set(DAC_LINE(0), 0xffff/2);
return 0;
}
```
- observe DAC's output is half of vref
### Issues/PRs references
- none known
19531: tests/unittests: allow passing `UNIT_TESTS` via env r=benpicco a=kaspar030
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
Make sure both the stack and TLS blocks are correctly aligned by
adjusting the TLS base address to the most strict alignment of the TLS
block and the stack.
Signed-off-by: Keith Packard <keithp@keithp.com>
18472: drivers/mrf24j40: add support for IEEE 802.15.4 Radio HAL r=benpicco a=jia200x
19175: drivers/periph_common/flashpage: fix silent error r=benpicco a=Enoch247
### Contribution description
This patch removes a test that silently hides failed writes to NULL. Instead, assert is used to ensure that the address is not NULL.
### Testing procedure
I am not certain how to update the tests to catch asserts. If this is possible, I will add a test, if someone will point me to a good example to learn from.
### Issues/PRs references
- none
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
19156: core/compiler_hints: add likely() / unlikely() hints r=kfessel a=benpicco
19174: tests/periph_spi clearly say when init succeeds r=benpicco a=jdavid
When the `tests/periph_spi` program succeeds the output can be interpreted as an error happened.
This PR makes it clearer when it does succeed.
### Contribution description
In `tests/periph_spi`:
- Explicitely say that the init operation was successful
- Rephrase the note to avoid misinterpretations
### Testing procedure
Run the `tests/periph_spi` program.
There is not much to test, just to verify the output, should be like this:
```
2023-01-19 10:42:33,768 # Trying to initialize SPI_DEV(1): mode: 0, clk: 0, cs_port: 0, cs_pin: 0
2023-01-19 10:42:33,777 # (if below the program crashes with a failed assertion, then it means the configuration is not supported)
2023-01-19 10:42:33,779 # Success.
```
### Issues/PRs references
Issue https://github.com/RIOT-OS/RIOT/issues/19025
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: J. David Ibáñez <jdavid.ibp@gmail.com>
The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
The mbox code contains a race condition in `mbox_put()`: When it
waits for a slot in the queue to become available, it is woken up with
IRQs enabled. It disables IRQs again as first thing, but by then
another thread may already have preempted the running thread and filled
the queue back up. In this case, a message in the queue would be
silently overwritten.
This restores a pre-existing design decision to implement both
blocking and non-blocking mutex locking with the same code. Those
implementations have been split prior to the introduction of
the `core_mutex_priority_inheritance` module when `mutex_trylock()`
indeed was trivial. This decision didn't age well, so undo it.
Presently, RIOT just emits a warning when a stack overflow is
encountered but still resumes execution. In my view, execution should be
aborted as the detection of a stack overflows via the heuristic provided
by the scheduler is an unrecoverable error.
I ran into this while performing automated tests of a RIOT application
where a stack overflow occurred but I only noticed this after inspecting
the application output more closely.
Similar to SSP failures, I added crash_code for stack overflows.
This fixes https://github.com/RIOT-OS/RIOT/issues/18545 as the code
previously relied on `sched_change_priority()` not directly scheduling
a new thread while IRQs are disabled, but rather later when IRQs are
restored. This is true for Cortex-M MCUs (where the PendSV IRQ is used
to trigger the scheduler), but not e.g. for AVR.
