- boot the I2C after init in low power mode
- otherwise I2C will consume more power until the first time it is
used, which is surprising
- STM32 F1 only: reconfigure SCL and SDA as GPIOs while the I2C
peripheral is powered down
- When the I2C peripheral is not clocked, it drives SCL and SDA
down. This will dissipate power across the pull up resistor.
- add support for multiple timers
- add support for selecting clock source in the board's `periph_conf.h`
- add support for the prescaler
- implement `periph_timer_query_freqs`
- add a second timer to all MSP430 boards
- the first timer is fast ticking, high-power
- the second is slow ticking, low-power
The functions `uart_poweron()`, `uart_poweroff()` and `uart_mode()`
can share code between the UART (UART without EasyDMA) and UARTE
(UART with EasyDMA) implementations, so let's do that.
- nRF51: Use `uart_conf_t` for consistency with nRF52
- nRF52832: Use UARTE (UART with EasyDMA) over UART (without DMA), as
done for all other nRF52 family members
- use `UARTE_PRESENT` to detect whether an UARTE can be used, rather
than family names
The `i2c_read_bytes()` and `i2c_write_bytes()` function return the
number of bytes written / read, instead of `0` as the API contract
says. This fixes the issue.
With only 8 possible prescalers, we can just loop over the values
and shift the clock. In addition to being much easier to read, using
shifts over divisions can be a lot faster on CPUs without hardware
division.
In addition an `assert()` is added that checks if the API contract
regarding the SPI frequency is honored. If the requested clock is too
low to be generated, we should rather have a blown assertion than
hard to trace communication errors.
Finally, the term prescaler is used instead of divider, as divider may
imply that the frequency is divided by the given value n, but
in fact is divided by 2^(n+1).
Previously, the /CS signal was performed by enabling / disabling the
SPI peripheral. This had the disadvantage that clock polarity settings
where not applied starting with `spi_acquire()`, as assumed by e.g.
the SPI SD card driver, but only just before transmitting data.
Now the SPI peripheral is enabled on `spi_acquire()` and only disabled
when calling `spi_release()`, and the `SPI_CR2_SSOE` bit in the `CR2`
register is used for hardware /CS handling (as supposed to).
This doesn't change the firmware, since for all STM32 MCUs with an
SPI driver the register setting in the mode did match the SPI mode
number by chance. But for some STM32 MCUs with no SPI driver yet
the register layout is indeed different. This will help to provide an
SPI driver for them as well.
The CR2 register was only written to if the settings differ from the
reset value. This wasn't actually a bug, since it was cleared in
`spi_release()` to the reset value again. Still, it looks like a bug,
may cause a pipeline flush due to the branch, and increased `.text`
size. So let's get rid of this.
The `SWJ_CFG` field of the `AFIO_MAPR` register is write only and values
read are undefined (random). Hence, using `AFIO->MAPR |= mask;` to
enable flags can corrupt the state of the `SWJ_CFG` (configure it to
an unintended value).
Two helper functions have been introduced:
- `afio_mapr_read()` reads the value, but sanitizes the `SWJ_CFG` field
to zero
- `afio_mapr_write()` writes the given value, but applies the `SWJ_CFG`
configured by the board before writing.
Finally, the `nucleo-f103rb` and `bluepill*`/`blackpill*` boards have
been updated to no longer specify `STM32F1_DISABLE_JTAG`, as this
is handled by the `SWJ_CFG` setting (which defaults to disabling JTAG).
`flash_<funcname>()` is implemented by `<funcname>_P()` provided by
the AVR libc on AVR targets. Previously, the preprocessor was used
to do the aliasing, but this causes issues with LLVM: The signatures of
e.g. `printf_P()` expects `const char *`, whereas flash utils expects
`FLASH_ATTR const char *`. For GCC this will just implicitly drop the
`FLASH_ATTR`, while it requires an explicit cast for LLVM.
To implement the explicit cast, `static inline` function wrappers
where used instead where possible. But for the variadic functions
(e.g. `printf(fmt, ...)`) the linker is used to provide the aliases,
as there is no way to pass the variadic functions throw in C. The
alternative would be to implement `flash_printf()` by calling
`vprintf_P()`, but that increased ROM size quite a bit.
Finally, a work around for a bug in Ubuntu's toolchain has been added:
An unused function that calls to `printf_P()`, `fprintf_P()` and
`snprintf_P()`. Since this function is garbage collected anyway, it
has no impact on the generated ELF file.
20009: cpu/native: fix bug in periph_timer r=MrKevinWeiss a=maribu
### Contribution description
While debugging https://github.com/RIOT-OS/RIOT/pull/18977#issuecomment-1764258356 it became obvious that the `periph_timer` in `native` is broken and issues early IRQs. This replaces the use of `setitimer` that cannot use a monotonic clock source with `timer_settime()`.
### Testing procedure
I have some non-publishable code that tests if the time an ISR fires in terms of `timer_read()` is no earlier than the time expected. This occasionally triggered with `master`, but I didn't see any of these issues anymore with this PR. I guess I should revive my PR to spice up the periph timer tests and add a polished version of this and let this run for an hour or two.
The tests ins `tests/periph/timer*` should still succeed on `native`. (They do for me in a container running `riot/riotbuild`).
### Issues/PRs references
Found while debugging https://github.com/RIOT-OS/RIOT/pull/18977#issuecomment-1764258356
20042: dist/tools/uf2: add target to also copy families.json file r=MrKevinWeiss a=MichelRottleuthner
### Contribution description
The updated UF2 pkg (#20035) stores the family ID in an external .json file. I overlooked that and flashing fails if this file is not present. This PR fixes it by also copying the json into the tool folder.
### Testing procedure
Check if the `feather-nrf52840-sense` can be flashed when the new UF2 pkg is cloned freshly.
### Issues/PRs references
Fixes a regression introduced with #20035
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Michel Rottleuthner <michel.rottleuthner@haw-hamburg.de>
Also use `CLOCK_MONOTONIC` for the timeouts, not just for
`timer_read()`. This fixes mismatches between when a timeout
occurs and what is expected in the context of the values returned by
`timer_read()`.
19465: drivers/mtd: use XFA for pointers to defined MTDs r=benpicco a=gschorcht
### Contribution description
This PR provides the support to hold pointers to defined MTDs within a XFA. The XFA allows
- to access MTDs of different types (`mtd_flashpage`, `mtd_sdcard`, `mtd_emulated`, ...) by an index
- to determine the number of MTDs defined in the system.
### Testing procedure
To be defined once PR #19443 is merged because emulated MTDs will allow to test this PR on arbitrary boards.
### Porting Guide
For external boards:
- remove the `MTD_NUMOF` definition from `board.h`
- add `MTD_XFA_ADD(<mtd_dev>, <idx>);` to the definition of `<mtd_dev>`.
- `MTD_0`, `MTD_1`, … defines are no longer needed.
### Issues/PRs references
Related to PR #19443
19981: Fletcher32: Add incremental API r=benpicco a=bergzand
### Contribution description
This PR extends the current fletcher32 checksum with an incremental API mode. This way the bytes to be checksummed can be supplied via multiple successive calls and do not have to be provided in a single consecutive buffer.
I've also rephrased the warning with the original function a bit as that function uses an `unaligned_get_u16` to access the data. The data thus does not require alignment, but the length does need to be supplied as number of 16 bit words.
### Testing procedure
The test has been extended
### Issues/PRs references
None
19995: sys/psa_crypto: Fix macro for public key max size and SE example r=benpicco a=Einhornhool
### Contribution description
#### 1. Wrong public key size when using secure elements, introduced by #19954
Fixed conditions for key size macros in `crypto_sizes.h`.
#### 2. EdDSA and ECDSA examples fail when using a secure element because of unsopported changes introduced by #19954
Updated `example/psa_crypto` to use only supported functions for secure elements.
### Testing procedure
Build `example/psa_crypto` for secure elements and run application
Output on master:
```
2023-10-19 14:33:24,372 # main(): This is RIOT! (Version: 2019.07-devel-22378-gb6772)
2023-10-19 14:33:24,372 # HMAC SHA256 took 56393 us
2023-10-19 14:33:24,372 # Cipher AES 128 took 68826 us
2023-10-19 14:33:24,372 # *** RIOT kernel panic:
2023-10-19 14:33:24,373 # HARD FAULT HANDLER
2023-10-19 14:33:24,373 #
2023-10-19 14:33:24,373 # *** rebooting...
```
Output with fixes:
```
2023-10-19 13:35:24,715 # main(): This is RIOT! (Version: 2019.07-devel-22384-g8ef66-dev/psa-crypto-fixes)
2023-10-19 13:35:24,715 # HMAC SHA256 took 56374 us
2023-10-19 13:35:24,715 # Cipher AES 128 took 68805 us
2023-10-19 13:35:24,715 # ECDSA took 281164 us
2023-10-19 13:35:24,715 # All Done
```
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19943: cpu/stm32: FMC used for low-level LCD parallel interface r=maribu a=gschorcht
### Contribution description
This PR provides the implementation of the LCD low-level MCU 8080 parallel interface using the FMC peripheral.
### Testing procedure
```
BOARD=stm32f723e-disco make -C tests/drivers/st77xx flash
```
and
```
BOARD=stm32l496g-disco make -C tests/drivers/st77xx flash
```
should work on top of PR #19941. Drawing operations should be much faster.
### Issues/PRs references
Depends on PR #19941
19978: treewide: fix typos to make codespell happy r=maribu a=maribu
### Contribution description
- fixes typos in comments and docs (no generated firmware changes expected)
- fixes a typo in a string in a GUI of a utility program
- add some false positives to the ignore list
### Testing procedure
- No generated binaries (except for the GUI version of the utility program to flash the MSB-A2) should change
- The diff should not look too scary
### Issues/PRs references
None
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19760: cpu/sam0_common/periph: add low-level SDMMC peripheral driver for SDHC r=benpicco a=gschorcht
### Contribution description
This PR implements the low-level SDIO/SDMMC peripheral driver for SAM0 SDHC according to the definition in #19539.
### Testing procedure
```
BOARD=same54-xpro make -C tests/drivers/sdmmc
```
```
BOARD=same54-xpro make -C tests/sys/vfs_default
```
### Issues/PRs references
~Depends on PR #19539~
Depends on PR #19899
19946: posix_sockets.c: Fix 2 byte int compilation errors r=benpicco a=mrdeep1
19956: cpu/esp32: fix heap definition for ESP32-S2 and ESP32-S3 r=benpicco a=gschorcht
### Contribution description
For ESP32-S2 and ESP32-S3 the symbol `_heap_end` must not be used as `_eheap` for the newlibc `malloc` and function `sbrk`.
`_heap_end` is used by the ESP-IDF heap implementation `esp-idf-heap` and points to the highest possible address (0x40000000) that could be used for the heap in ESP-IDF. It doesn't point to the top address of the unused SRAM area that can be used in newlibc `malloc` and function `sbrk`. Instead, the origin and the length of `dram0_0_seg` must be used to calculate the end of the heap `_eheap`.
The problem only occurs for the newlibc `malloc` when the `sbrk` function is used but not for the ESP-IDF heap implementation `esp_idf_heap`.
### Testing procedure
Use any ESP32-S2 or ESP32-S3 board and flash `tests/sys/malloc`, e.g.
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart' BOARD=esp32s3-pros3 make -j8 -C tests/sys/malloc flash
```
Without the PR the `nm` command will give the wrong address
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
40000000 A _eheap
```
The test will stuck, i.e. the allocation of memory stops when the top of unused SRAM is reached and the board restarts when the watchdog timer expires. With the PR it should work as expected
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-309-g4669e)
calloc(zu, zu) = 0x10000000
CHUNK_SIZE: 16384
NUMBER_OF_TESTS: 3
Allocated 16384 Bytes at 0x3fc8c4b0, total 16384
...
Allocated 16384 Bytes at 0x3fcec6f0, total 409792
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403763e3
```
With this PR the `nm` command should give a address in unused SRAM address space
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
3fcca000 A _eheap
```
and the test should pass.
### Issues/PRs references
19957: cpu/esp32: fix Octal SPI RAM for ESP32-S3 r=benpicco a=gschorcht
### Contribution description
This PR fixes Octal SPI RAM handling for ESP32-S3.
Functions that are used during the initialization of the Octal SPI RAM must reside in IRAM instead of Flash. Otherwise, the system stucks during boot once the Octal SPI RAM is enabled. The reason is that the Flash is not available during the initialization of the Octal SPI RAM and the functions that are called during that initialization can't be accessed in Flash. As a result the call of such a function leads to code that is messed up and the system crashes.
The PR also includes the documentation fixe for the `esp32s3-box`. It also includes a small documentation fix regarding the SPI RAM for the `esp32s3-pros3` board.
### Testing procedure
Use a board that has Octal SPI RAM and flash `tests/sys/malloc`, e.g.:
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart esp_spi_ram esp_log_startup' \
BOARD=esp32s3-box make -C tests/sys/malloc
```
Without the PR, the system stuck during boot once the information for the Octal SPI RAM is print
```
ESP-ROM:esp32s3-20210327
...
I (133) boot: Loaded app from partition at offset 0x10000
I (134) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id : 0x02 (generation 3)
density : 0x03 (64 Mbit)
good-die : 0x01 (Pass)
Latency : 0x01 (Fixed)
VCC : 0x01 (3V)
SRF : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen : 0x01 (32 Byte)
Readlatency : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
```
and the board restarts when the watchdog timer expires.
With this PR, the system starts as expected.
```
ESP-ROM:esp32s3-20210327
...
I (132) boot: Loaded app from partition at offset 0x10000
I (133) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id : 0x02 (generation 3)
density : 0x03 (64 Mbit)
good-die : 0x01 (Pass)
Latency : 0x01 (Fixed)
VCC : 0x01 (3V)
SRF : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen : 0x01 (32 Byte)
Readlatency : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
Found 64MBit SPI RAM device
SPI RAM mode: sram 40m
PSRAM initialized, cache is in normal (1-core) mode.
Pro cpu up.
Single core mode
SPI SRAM memory test OK
Initializing. RAM available for dynamic allocation:
At 3FC8C150 len 00053EB0 (335 KiB): D/IRAM
At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
At 3FCF0000 len 00008000 (32 KiB): DRAM
Starting ESP32x with ID: f412fafd0f8c
ESP-IDF SDK Version v4.4.1
Current clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 SLOW=150000
PRO cpu is up (single core mode, only PRO cpu is used)
PRO cpu starts user code
Adding pool of 8192K of external SPI memory to heap allocator
Used clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 FAST=8000000 SLOW=150000
XTAL calibration value: 3643448
Heap free: 8754851 bytes
Board configuration:
UART_DEV(0) txd=43 rxd=44
LED pins=[ ]
BUTTONS pins=[ 0 ]
Starting RIOT kernel on PRO cpu
Help: Press s to start test, r to print it is ready
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Jon Shallow <supjps-libcoap@jpshallow.com>
For ESP32-S2 and ESP32-S3 the symbol `_heap_end` must not be used as `_eheap` for dynamic memory allocation, because it points to the highest possible address that could be used for the heap, but not to the top address of the unused SRAM area. Instead, the origin and length of `dram0_0_seg` must be used to calculate the end of the heap.
19952: cpu/stm32/periph/eth: Disable hardware checksums r=maribu a=yarrick
lwIP will fill them in already.
Having this enabled causes empty checksums to be sent: #19853
Co-authored-by: Erik Ekman <eekman@google.com>
The API of timer_init() expects callers to know what frequencies are
supported and only use valid frequencies. So let's add an `assert()`
to aid debugging if the app uses an invalid.
19794: drivers/periph: Add documentation on thread safety and initialization r=aabadie a=maribu
19912: drivers/at86rf215: switch example config to use EXT3 on same54-xpro r=aabadie a=benpicco
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
18547: sys: PSA Crypto API implementation r=MrKevinWeiss a=Einhornhool
### Contribution description
This adds an implementation of the ARM [PSA Crypto API](https://armmbed.github.io/mbed-crypto/html/index.html) specification to RIOT.
It is a cryptographic API that supports software and hardware backends as well as the use of multiple secure elements, which can be configured with Kconfig.
It integrates indirect, identifier based key management to support persistent storage of key material in local memory and devices with protected key storage.
A description of the implementation design and an evaluation of the processing time and memory overhead in RIOT has been published here: [Usable Security for an IoT OS: Integrating the Zoo of Embedded Crypto Components Below a Common API](https://arxiv.org/abs/2208.09281)
#### Implementation status
So far this implementation supports the following operations:
- Volatile key storage
- AES in CBC mode
- Hashes (MD5, SHA1, SHA224, SHA256)
- HMAC SHA256
- ECDSA with NIST P192 and P256 curves
The following backends are supported so far:
- RIOT Cipher Module
- RIOT Hash Module
- Micro ECC library package
- Cryptocell 310 hardware accelerator on the Nordic NRF52840dk
- Microchip ATECC608A secure element
Other operations and backends as well as persistent key storage can and will be implemented by me and anyone who wants to contribute in the future.
### Testing procedure
So far there is a show case application in `examples/psa_crypto` to demonstrate the usage and configuration of different backends of the API (refer to the application README for more information).
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19887: cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) r=aabadie a=gschorcht
### Contribution description
This PR provides a small change for `periph_dac` to support the VDACs of EFM32 Series 1 MCUs. It was tested with `sltb009a` board for which this PR includes the DAC configuration.
### Testing procedure
`tests/periph/dac` should work for the `sltb009a` board. I've tested it already.
```
BOARD=sltb009a make -j8 -C tests/periph/dac flash
```
### Issues/PRs references
Depends on PR #19886
19898: tests/net/gcoap_fileserver: disable test on CI r=aabadie a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19539: drivers/periph_sdmmc: define a High-level SDIO/SD/MMC API and low-level SDMMC periperal driver interface r=benpicco a=gschorcht
### Contribution description
This PR provides a SDIO/SD/MMC Device API (SDMMC). It implements a SD host controller driver that provides a high-level functions using a low-level SDIO/SD/MMC peripheral driver for accessing
- MultiMediaCards (MMC) and Embedded MultiMediaCards (eMMC)
- SD Memory Cards (SD Cards) with Standard Capacity (SDSC), High Capacity (SDHC) or Extended Capacity (SDXC).
It supports:
- 1-bit, 4-bit and 8-bit data bus width
- Default Speed and High Speed
- Auto-CLK
The SDIO/SD/MMC device API (SDMMC) is divided into two parts:
1. The high-level API that implements the SD Host Controller driver and allows
- to inititialize and identify different types of cards,
- to access them either blockwise or bytewise,
- to get information about the used card, and
- to send single commands or application specific commands to the card.
2. The low-level SDIO/SD/MMC peripheral driver implements the low-level functions required by the high-level device API. It has to be implemented for each MCU.
### Limitations:
- Only one card per SDIO/SD/MMC device is supported.
- eMMCs specific features are not supported.
- UHS-I, UHS-II and UHS-III are not supported.
### Testing procedure
PR #19540, PR #19760 or PR #19786 is needed to test this PR.
### Issues/PRs references
Prerequisite for PR #19540
Prerequisite for PR #19760
Prerequisite for PR #19786
19815: cpu/sam0_common/periph/sdhc: busy waiting and clock fixes r=benpicco a=benpicco
19860: drivers/ft5x06: fix vendor ID for FT6xx6 and FTxxxx register addresses r=benpicco a=gschorcht
### Contribution description
This PR provides a fix of the vendor ID for FT6xx6 touch panel driver ICs and a fix of register addresses for FTxxxx.
According to the [Application Note for FT6x06 CTPM](https://cdn-shop.adafruit.com/datasheets/FT6x06_AN_public_ver0.1.3.pdf), the vendor ID of FT6x06 touch panel driver ICs is `0x11` instead of `0xcd`. Although there are no information found in the Web about the FT6x36, the FT6336U touch panel of a ESP32-S3 WT32 SC01 Plus is also working with `0x11` as vendor ID so that it seems that FT6x36 is also using `0x11` as vendor ID.
Figured out with a `stm32f723e-disco` board (revision D03). Without this PR, `tests/drivers/ft5x06` gives:
```
+------------Initializing------------+
[ft5x06] init: invalid vendor ID: '0x11' (expected: 0xcd)
[Error] Initialization failed
```
With this PR it works as expected.
```
+------------Initializing------------+
Initialization successful
main(): This is RIOT! (Version: 2023.10-devel-96-gbb9011-drivers/ft5x06_fix_vendor_id)
FT5x06 test application
+------------Initializing------------+
[ft5x06] init: configuring touchscreen interrupt
Initialization successful
1 touch detected
[ft5x06] read gesture_id '0x00'
Touch 1 - X: 151, Y:138
[ft5x06] read gesture_id '0x00'
```
Some background information found in the Web:
- According to the [STM32CubeF7](c20e6dd15b/Drivers/BSP/STM32F723E-Discovery/stm32f723e_discovery_ts.c (L24-L27)) the FRIDA LCD panel mounted on the `stm32f723e-disco` board either uses FT6x36 (prior revision D) or FT3x67 (revision D). However, the FT5x06 driver type for the card is defined as FT6x06, which does not seem correct: bb9011c3fb/boards/stm32f723e-disco/include/board.h (L59)
- According to the [STM32CubeF7](c20e6dd15b/Drivers/BSP/Components/ft6x06/ft6x06.h (L269-L270)), the vendor ID for FT6x36 should be `0xcd`. However, the FT6336U on ESP32-S3 WT32 SC01 Plus works with vendor ID `0x11`.
- The [Adafruit FT6206 library](95118cd983/Adafruit_FT6206.h (L28)) uses `0x11` as vendor id.
- The `stm32l496g-disco` board uses a FT6236 which has vendor ID `0xcd`.
So the information available on the web is confusing. Maybe, a better solution would be to accept `0x11` as well as `0xcd` as vendor ID for FT6xxx touch panels. Unfortunately, there are no documents available on the registers directly from FocalTech 😟 so it seems to be more speculation than knowledge.
### Testing procedure
### Issues/PRs references
19886: cpu/efm32: fix DAC configuration r=benpicco a=gschorcht
### Contribution description
The EFM32 MCU allows the reference voltage to be configured per DAC device, not per DAC channel. Also, the DAC reference voltage was defined in the configuration but not used anywhere.
At the moment we have only defined one board (`stwstk6220a`) that uses the DAC, so changing the configuration interface shouldn't be critical.
### Testing procedure
`tests/periph/dac` should still work for the `stwstk6220a`
```
BOARD=slwstk6220a make -j8 -C tests/periph/dac flash
```
I don't have a `stwstk6220a` board (EFM32 Series 0) so that I can't test it. I could only test it for the `sltb009a` board (EFM32 Series 1) with the change for VDAC in PR #19887.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
The EFM32 MCU allows the reference voltage to be configured per DAC device, not per DAC channel. Also, the DAC reference voltage was defined in the configuration but not used anywhere.
19452: dist/tools/esptools: upgrade ESP32x toolchains to GCC version 12.2 r=MrKevinWeiss a=gschorcht
### Contribution description
This PR upgrades ESP32x toolchains to GCC version 12.2 which is a prerequisite for upgrading the ESP-IDF to version 5.1.
This PR depends on PR #19450
### Testing procedure
`dist/tools/install.sh all` should install all ESP32x toolchains.
`. dist/tools/export.sh all` should make them visible.
### Issues/PRs references
Depends on PR #19450
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
