timer_set has no documented restriction on this being not null, other
implementations explicitly tolerate it (rpx0xx checks inside the ISR,
but doing it at init time keeps the ISR slim).
This is useful when using a timer just to read, without any action when
it triggers (the action is taken depending on read values, eg. in a
thread context).
- 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>
If the board defines `FMC_RAM_ADDR` and `FMC_RAM_LEN`, the FMC RAM is used a additional heap if module `periph_fmc` is enabled.
For that purpose
- the linker symbols `_fmc_ram_addr` and `_fmc_ram_len` are set,
- a memory region `fcmram` is added in linker script for the FMC RAM based on these `_fcm_ram_*` linker symbols
- a section for the FMC RAM is defined in this memory region that defines the heap by setting `_sheap3` and `_eheap3` and
- the number of heaps is set to 4 since to use `_sheap3` and `_eheap3` even though `_sheap1` and `_eheap1` (the backup RAM) and `_sheap2` and `_eheap2` (SRAM4) are not present.
19634: tree-wide: mixed box of compilation fixes with clang r=benpicco a=maribu
### Contribution description
As the title says: This should increase the number of apps being able to build with clang quite a bit.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Drop type qualifiers in front of anonymous bit fields (padding for
reserved bits) for compatibility with `clang++`. A four line bash
script was added to ease fixing new vendor header files.
19798: cpu/nrf53: add I2C and SPI support r=benpicco a=dylad
### Contribution description
This PR provides support for nRF53 SPI and I2C.
It also moves common structs from each nRF CPU folder to `cpu/nrf5x_common` to avoid duplication.
Moreover, since nRF9160 and nRF5340 have shared IRQ for UART/SPI/I2C. Both this families now use a common file to register and manage these interrupts. Note that nRF9160 have different name for its interrupts than nRF5340 but they have the same purpose.
### Testing procedure
Since some structs were moved around, I think this PR should be carefully tested against nRF52, nRF53 and nRF9160 to avoid any issues.
On nRF5340DK-APP, SPI can be tested with its onboard SPI flash.
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
For now, nRF53 and nRF9160 will shared UART/I2C/SPI IRQs, nRF52 will reuse the same callback but will keep its own file to avoid breakage. This can be continue in a followup PR
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
- periph/eeprom.c
- periph/wdt.c
- periph/gpio_ll_irq.c
removed unsupported cpuid and dpgpin feature for atmega8 cpu familly
pkg/qdsa: bump the commit hash bump the commit hash after RIOT-OS/qDSA#4
was merged
19777: cpu/avr8_common: Prepare for rework ISR r=benpicco a=nandojve
### Contribution description
This prepares for rework how ISR is handled for AVR-8 platform. It is not expected changes on the behavior but tests on other boards were welcome to avoid regressions.
#### Improvements
* Split UART state from ISR states. Now it is necessary two variables and GPIORx registers are automatically selected when available.
* UART states now supports up to 8 UARTs.
* Added AVR8_ISR macro do clean-up and hide internals related to ISR processing. This allows changes on ISR without any other changes on drivers.
### Testing procedure
Tests were conducted using atmega328p-xplained-mini and atxmega-a1u-xpro and the zigduino board was only built. The example thread_duel was used to test regressions.
Co-authored-by: Gerson Fernando Budke <nandojve@gmail.com>
19811: boards: add ESP32-S3-Box support r=gschorcht a=gschorcht
### Contribution description
This PR provides the support for the [ESP32-S3-Box](https://github.com/espressif/esp-box).
### Testing procedure
The board has been tested with all basic tests for supported hardware including `tests/drivers/ili9341`:
- [x] tests/drivers/ili9341
- [x] tests/periph/gpio
- [x] tests/periph/i2c
- [x] tests/periph/spi
- [x] tests/periph/uart
- [x] tests/sys/usbus_cdc_ecm
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19804: cpu/nrf{53,9160}: add periph_rtt support r=benpicco a=dylad
### Contribution description
This PR enables support for `periph_rtt` on both nRF9160 and nRF53.
This PR is based on #19803
I was only able to test on nrf5340dk-app as I don't have access to any nrf9160-based board.
Here is `test/periph/rtt` output for reference on `nrf5340dk-app`:
### Testing procedure
flash `tests/periph/rtt` on `nrf9160dk` or `nrf5340dk-app` and check the results.
```
s
2023-07-06 16:11:16,471 # START
2023-07-06 16:11:16,479 # main(): This is RIOT! (Version: 2023.07-devel-765-g02c65-cpu/nrf53/add_rtt_support)
2023-07-06 16:11:16,480 #
2023-07-06 16:11:16,482 # RIOT RTT low-level driver test
2023-07-06 16:11:16,483 # RTT configuration:
2023-07-06 16:11:16,485 # RTT_MAX_VALUE: 0x00ffffff
2023-07-06 16:11:16,487 # RTT_FREQUENCY: 1024
2023-07-06 16:11:16,487 #
2023-07-06 16:11:16,494 # Testing the tick conversion (with rounding if RTT_FREQUENCY is not power of 2)
2023-07-06 16:11:16,498 # Trying to convert 1 to seconds and back
2023-07-06 16:11:16,501 # Trying to convert 256 to seconds and back
2023-07-06 16:11:16,505 # Trying to convert 65536 to seconds and back
2023-07-06 16:11:16,509 # Trying to convert 16777216 to seconds and back
2023-07-06 16:11:16,514 # Trying to convert 2147483648 to seconds and back
2023-07-06 16:11:16,514 # All ok
2023-07-06 16:11:16,514 #
2023-07-06 16:11:16,517 # Initializing the RTT driver
2023-07-06 16:11:16,835 # This test will now display 'Hello' every 5 seconds
2023-07-06 16:11:16,835 #
2023-07-06 16:11:16,836 # RTT now: 4
2023-07-06 16:11:16,840 # Setting initial alarm to now + 5 s (5124)
2023-07-06 16:11:16,841 # rtt_get_alarm() PASSED
2023-07-06 16:11:16,846 # Done setting up the RTT, wait for many Hellos
2023-07-06 16:11:16,852 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 404 }]}
2023-07-06 16:11:21,833 # Hello
2023-07-06 16:11:26,831 # Hello
2023-07-06 16:11:31,830 # Hello
2023-07-06 16:11:36,828 # Hello
2023-07-06 16:11:41,826 # Hello
2023-07-06 16:11:46,825 # Hello
2023-07-06 16:11:51,823 # Hello
2023-07-06 16:11:56,821 # Hello
2023-07-06 16:12:01,821 # Hello
2023-07-06 16:12:06,819 # Hello
2023-07-06 16:12:11,817 # Hello
2023-07-06 16:12:16,815 # Hello
2023-07-06 16:12:21,813 # Hello
2023-07-06 16:12:26,811 # Hello
```
### Issues/PRs references
based on #19803
19807: boards/esp32s2-lilygo-ttgo-t8: fix display configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the display configuration for the ESP32-S2 LilyGO TTGO T8 (also known as LilyGo T-Display S2) which uses a ST7789 as display driver IC that is compatible with the ST7735.
For that purpose the ST7735 driver is extended by a pseudomodule definition `st7789` for the ST7789 which is enabled by the board and enables automatically the `st7789` (f57b6b70b8). Vise versa, board's `Makefile.dep` enables automatically the `st7789` pseudomodule if the `st7735` is used. The pseudomodule `st7789` is just used to increase the upper limit for supported lines.
### Testing procedure
```
BOARD=esp32s2-lilygo-ttgo-t8 make -C tests/drivers/st7735/ flash
```
should work:
### Issues/PRs references
19809: cpu/nrf53: add usbdev support r=benpicco a=dylad
### Contribution description
This PR enables `periph_usbdev` support on nRF5340DK-app board. Since the IP is the same as nRF52, the driver and its related data and structs were moved from `cpu/nrf52` to `cpu/nrf5x_common`
### Testing procedure
Test any USBUS related test application on `nrf5340dk-app`
`CFLAGS='-DSECTOR_COUNT=64' USEMODULE='mtd_emulated' make BOARD=nrf5340dk-app -C tests/sys/usbus_msc flash`
dmesg output:
```
[ 7466.262760] usb 1-2.1: new full-speed USB device number 16 using xhci_hcd
[ 7466.483916] usb 1-2.1: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[ 7466.483925] usb 1-2.1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 7466.483928] usb 1-2.1: Product: nrf5340dk-app
[ 7466.483931] usb 1-2.1: Manufacturer: RIOT-os.org
[ 7466.483933] usb 1-2.1: SerialNumber: AD0FD4AE806080C2
[ 7466.487010] usb-storage 1-2.1:1.0: USB Mass Storage device detected
[ 7466.487348] scsi host2: usb-storage 1-2.1:1.0
[ 7467.516789] scsi 2:0:0:0: Direct-Access RIOT-OS RIOT_MSC_DISK 1.0 PQ: 0 ANSI: 1
[ 7467.517152] sd 2:0:0:0: Attached scsi generic sg3 type 0
[ 7467.517501] sd 2:0:0:0: [sdd] 64 512-byte logical blocks: (32.8 kB/32.0 KiB)
[ 7467.517732] sd 2:0:0:0: [sdd] Write Protect is off
[ 7467.517733] sd 2:0:0:0: [sdd] Mode Sense: 03 00 00 00
[ 7467.517906] sd 2:0:0:0: [sdd] No Caching mode page found
[ 7467.517910] sd 2:0:0:0: [sdd] Assuming drive cache: write through
[ 7467.532159] sd 2:0:0:0: [sdd] Attached SCSI removable disk
```
I also tested `tests/sys/usbus_cdc_ecm` and `tests/sys/usbus/usbus_hid` succesfully.
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19789: cpu/nrf5x/periph/wdt: enable support for nRF53/nRF9160 r=benpicco a=dylad
### Contribution description
This PR enables support for the watchdog driver on nRF53.
This MCU has two watchdog peripherals, for now, it only uses the first one.
The use of the second watchdog can be add in a followup PR later.
### Testing procedure
Flash and play with `tests/periph/wdt` application.
### Issues/PRs references
None.
19796: boards/b_u585i_ iot02a/periph usbdev r=benpicco a=gschorcht
### Contribution description
This PR adds the USB OTG support for STM32U5 and the `b_u585i_iot02a` board.
This PR includes PR #19795 since it uses directly the changes made in PR #19795.
### Testing procedure
Compile and flash
```
BOARD=b-u585i-iot02a make -C tests/sys/usbus_cdc_ecm/ flash term
```
Use the `sudo dmesg` command to get the kernel messages.
```pyhon
[766948.556645] usb 1-2.2: new full-speed USB device number 108 using xhci_hcd
[766948.658688] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[766948.658696] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[766948.658699] usb 1-2.2: Product: b-u585i-iot02a
[766948.658702] usb 1-2.2: Manufacturer: RIOT-os.org
[766948.658704] usb 1-2.2: SerialNumber: AA140057DA41D467
[766948.668681] cdc_ether 1-2.2:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, ea:dc:44:71:d9:24
[766948.743250] cdc_ether 1-2.2:1.0 enxeadc4471d924: renamed from usb0
```
Use the `ifconfig` command on the node to determine the IPv6 LLUA and ping the node.
```
ping6 -c 3 fe80::e8dc:44ff:fe71:c524%enxeadc4471d924
PING fe80::e8dc:44ff:fe71:c524%enxeadc4471d924(fe80::e8dc:44ff:fe71:c524%enxeadc4471d924) 56 data bytes
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=1 ttl=64 time=0.523 ms
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=2 ttl=64 time=0.546 ms
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=3 ttl=64 time=0.599 ms
```
### Issues/PRs references
Includes PR #19795
19802: cpu/nrf53: enable flashpage support r=benpicco a=dylad
### Contribution description
This PR enables flashpage support on nRF53 family.
The peripheral is identical to nRF52, just add the flashpage configuration and enable the module in both Makefiles.features and Kconfig.
### Testing procedure
run `/tests/periph/flashpage` on `nrf5340dk-app`
output of `make BOARD=nrf5340dk-app flash test`
```
/home/dylan/work/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
Twisted not available, please install it if you want to use pyterm's JSON capabilities
Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
>
>
test_last_raw
> test_last_raw
wrote raw short buffer to last flash page
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_last_pagewise
test_reserved_pagewise Write and verify short write on reserved page
test_last_raw Write and verify raw short write on last page available
> test_last_pagewise
wrote local page buffer to last flash page
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_reserved_pagewise Write and verify short write on reserved page
test_reserved_pagewise
test_last_raw Write and verify raw short write on last page available
> test_reserved_pagewise
Reserved page num: 5
Since the last firmware update this test has been run 0 times
wrote local page buffer to reserved flash page
When running on a bootloader, as an extra check, try restarting the board and check whether this application still comes up.
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_reserved_pagewise Write and verify short write on reserved page
test_last_raw Write and verify raw short write on last page available
>
make : on quitte le répertoire « /home/dylan/work/RIOT/tests/periph/flashpage »
```
### Issues/PRs references
None.
19803: cpu/nrf5x_common: rework LFCLK source selection r=benpicco a=dylad
### Contribution description
This PR changes the source selection of LFCLK for all nRF families.
This idea is to use the values provided by Nordic vendor files to properly populate the source of the LFCLK. Then setup a per CPU check to ensure the value provided at board level is fine. In the end, the LFCLK source selection is a mere assignment.
The selection of the LFCLK source is still done at board level. I also add a bit of documentation to help users to select another value if needed.
I'll provide in a followup PR, `periph_rtt` support for both nRF9160 and nRF53.
### Testing procedure
CI should be enough I think. Otherwise, one can ran tests/periph/rtt on any nRF51-based board and any nRF52-based board.
You can also change the LFCLK source at board level to ensure the guards are doing their jobs.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The current ISR implementation for AVR8 requires use of
avr8_[enter/exit]_isr pair which add some boilerplate on code.
This add AVR8_ISR which clean-up the code and make it simpler
and hides any schedule detail from the user perspective.
This is a preparation for future scheduling and irq optimizations.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
The thread_yield_higher is a normal functions. However it has a non
regular return instruction which is useless. This remove the useless
return on thread_yield_higher to save flash bytes.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
The avr8_state variable uses bit operation to set/clear the state. This
rework avr8_state to use increment/decrement instead. It introduce the
use of General Purpose IO Register 1 (GPIOR1) when available.
This is a preparation for future scheduling and irq optimizations.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
The avr8_state store state information used to determine scheduling
and uart irq. This move all uart irq states to avr8_state_uart
variable. It introduce the use of General Purpose IO Register 0
(GPIOR0) when available and now all uarts from xmega can be used.
This is a preparation for future scheduling and irq optimizations.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Several STM32 families such as C0, G0, H7, L5 and U5 use `SYSTEM_STM32..XX_H` define instead of `__SYSTEM_STM32..XX_H` define to prevent multiple inclusion of `system_stm32xxxx.h`.
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
The MSP430 vendor files already provide macros containing register
constants and symbols (provided via linker scripts) containing addresses
of peripheral registers. So lets make use of that rather than
maintaining a long list of constants.
The RNG can use HSI48, HSI48/2 or HSI16. Using MSI as 48 MHz clock source for RNG is not possible. The clock configuration in `stmclk_u5.c` activates anyway only the MSIS but not the MSIK which could be used for certain peripherals.
Therefore, this commit
- removes the configuration of MSI as 48 MHz clock for RNG and its selection in `RCC->CCIPR1.ICLKSEL`
- enables HSI48 and selects it for RNG.
The HSI48 will also be used in future for certain peripherals such as USB OTG FS and SDMMC.
19770: cpu/nrf5x_common: reset all available CC channels r=maribu a=dylad
### Contribution description
Properly reset all CC channels of a given timer at initialization (except the last one which seems to be used for capture only in the driver).
The issue with the previous code was that some CCs were not clear on some nRF52 MCUs.
For instance, nRF52840 has 4 CCs for its two first timers, then 6 CCs for all others.
nRF9160 and nRF5340 also have 6 CCs for all its timer peripherals.
Thus, loop through the reported number of channels and clear the associated register instead of hardcoding the first 3 CC channels.
### Testing procedure
CI should be enough I think.
### Issues/PRs references
None.
19773: cpu/nrf{52,9160}: remove duplicate sevonpend bit r=maribu a=dylad
### Contribution description
This PR removes duplicate calls of `SCB_SCR_SEVONPEND` bit in nRF52 and nRF9160.
This call is already done [here](7c320055a1/cpu/cortexm_common/cortexm_init.c (L60))
### Testing procedure
Flash a nRF52 or nRF9160-based board and check that the board is still alive.
### Issues/PRs references
None. I notice this duplicate call when porting nRF53.
19774: boards/frdm-k22f: fixes long lines in periph_conf.h r=maribu a=hugueslarrive
19775: boards/frdm-k64f: fixes long lines and comma separated by whitespaces… r=maribu a=hugueslarrive
… warnings
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
Vera++ doesn't like `#error` preprocessor directives without a quoted
string afterwards (and also my syntax highlighter doesn't like this as
well). So let's add the quotes to have the tools not spooked out.
19712: cpu/riscv: Add PMP driver r=MrKevinWeiss a=Teufelchen1
### Contribution description
Hi! 🐘
this adds a basic RISC-V physical memory protection (PMP) driver to RIOT. Well, 'driver' might be a stretched, feels more like a little utility :)
EDIT: Also added a no-execute RAM option for the hifive & a corresponding test
Since I only have an Hifive rev b, it's only enabled on this board / cpu. I also tested the code on an ESP32-C but the feature can't be enabled there, as `cpu/riscv_common/` is not used by the ESP32...
### Testing procedure
* Grab a hifive rev b
* go to `examples/hello-world`
* Add `USEMODULES += periph_pmp` to the `Makefile`
* Include `pmp.h` in `main.c`
* Add code e.g. `print_pmpcfg(0);`
* compile & flash & term
You should see something like this:
```
# Hello World!
# You are running RIOT on a(n) hifive1b board.
# This board features a(n) fe310 MCU.
# pmp00cfg: - R-X OFF 0x00000000 - 0x00000000
```
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
The only peripheral that currently uses the FDPLL1 is SDHC. However, the SDHC IP can only be clocked at up to 150 MHz. Therefore, 100 MHz is currently used as the frequency of the FDPLL1. If another peripheral device requires 200 MHz in the future, this must be realized via different clock generators.
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19703: cpu/sam0_eth: interrupt based link detection/auto-negotiation r=benpicco a=benpicco
19724: dist/tools/openocd: add OPENOCD_SERVER_ADDRESS variable r=benpicco a=fabian18
19735: nrf5x_common: Clear I2C periph shorts r=benpicco a=bergzand
### Contribution description
The I2C peripheral's shortcuts are used with the read and write register to automatically stop the I2C transaction or to continue with the next stage.
With simple I2C read and write bytes these shorts are not used, but are also not cleared by the function in all cases, causing it to use the shortcut configuration set by a previous function call. This patch ensures that the shorts are always set by the read and write functions
### Testing procedure
Should be possible to spot with a logic analyzer and the I2C periph test. Maybe the HIL test can also detect it :)
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
The I2C peripheral's shortcuts are used with the read and write register
to automatically stop the I2C transaction or to continue with the next
stage.
With simple I2C read and write bytes these shorts are not used, but are
also not cleared by the function in all cases, causing it to use the
shortcut configuration set by a previous function call. This patch
ensures that the shorts are always set by the read and write functions
Always enable the internal pull-up on the SCL line to always have a
functional I2C bus. This may increase power consumption where an
external pull up is present as well. But let's wait for a real world
use case where this would help to extend battery life before making
this configurable.
This fixes https://github.com/RIOT-OS/RIOT/issues/19021
19689: cpu/sam0_eth: disable PHY when MAC is sleeping r=maribu a=benpicco
19700: pkg/openthread: Fix Kconfig and broken example r=maribu a=MrKevinWeiss
### Contribution description
There were some improvements that could be make to the kconfig modeling of the `pkg/openthread` after looking a bit closer.
The bigger problem is the hash check on nightlies require reproducible builds, however, even with make, the builds are not reproducible. So, for now, I just rename the `app.config.test` to `skip.app.config.test` to prevent murdock from trying to do a hash check but still letting it be useable.
### Testing procedure
Green murdock, all modules match `examples/openthread`
- Rename `skip.app.config.test` to `app.config.test`
- Run the following
```
./dist/tools/compile_test/compile_like_murdock.py -j 8 -a examples/openthread/ -b all -m
```
<details>
```
examples/openthread/ cc2538dk PASS
examples/openthread/ frdm-kw41z PASS
examples/openthread/ iotlab-a8-m3 PASS
examples/openthread/ iotlab-m3 PASS
examples/openthread/ nrf52840-mdk PASS
examples/openthread/ nrf52840dk PASS
examples/openthread/ omote PASS
examples/openthread/ openlabs-kw41z-mini PASS
examples/openthread/ openlabs-kw41z-mini-256kib PASS
examples/openthread/ openmote-cc2538 PASS
examples/openthread/ phynode-kw41z PASS
examples/openthread/ reel PASS
examples/openthread/ remote-reva PASS
examples/openthread/ remote-revb PASS
examples/openthread/ samr21-xpro PASS
examples/openthread/ usb-kw41z PASS
```
</details>
### Issues/PRs references
Fixes an aspect of broken master
19701: sys/usb/Kconfig: Fix default PID r=maribu a=MrKevinWeiss
### Contribution description
Seems like I just didn't have the correct `USB_PID` defined in the `usb-codes.inc.mk`.
It should be 0x7D01 not 0x7001.
It only shows up in nightlies since the hash would mismatch.
### Testing procedure
Simulated nightly testing with:
```
./dist/tools/compile_test/compile_like_murdock.py -j 8 -a tests/pkg/tinyusb_cdc_acm_stdio/ tests/pkg/tinyusb_cdc_msc/ tests/pkg/tinyusb_cdc_msc/ tests/sys/fido2_ctap/ tests/sys/usbus_board_reset/ tests/sys/usbus_msc/ -b arduino-zero samd21-xpro nucleo-f767zi -v
```
<details>
```
tests/pkg/tinyusb_cdc_acm_stdio/ arduino-zero PASS
ctests/pkg/tinyusb_cdc_acm_stdio/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_acm_stdio/ samd21-xpro PASS
tests/pkg/tinyusb_cdc_msc/ arduino-zero PASS
tests/pkg/tinyusb_cdc_msc/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_msc/ samd21-xpro PASS
tests/pkg/tinyusb_cdc_msc/ arduino-zero PASS
tests/pkg/tinyusb_cdc_msc/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_msc/ samd21-xpro PASS
tests/sys/fido2_ctap/ arduino-zero PASS
tests/sys/fido2_ctap/ samd21-xpro PASS
tests/sys/usbus_board_reset/ arduino-zero PASS
tests/sys/usbus_board_reset/ nucleo-f767zi PASS
tests/sys/usbus_board_reset/ samd21-xpro PASS
tests/sys/usbus_msc/ arduino-zero PASS
tests/sys/usbus_msc/ nucleo-f767zi PASS
tests/sys/usbus_msc/ samd21-xpro PASS
```
### Issues/PRs references
Broken master in nightlies.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19677: boards/nucleo-l432k: provide three periph_timer instances r=maribu a=maribu
### Contribution description
- `cpu/stm32/periph_timer`: Generalize to also work with timers that do not have 4 channels
- `boards/common/stm32`: Add timer config for three timers based on TIM2, TIM15, and TIM16 (the three general-purpose timers of the STM32L4)
- `boards/nucleo-l432kc`: Make use of the new timer config
19683: cpu/sam0_eth: clean up init() r=maribu a=benpicco
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19610: drivers/periph/rtc: improve doc on rtc_set_alarm r=maribu a=maribu
### Contribution description
- point out behavior on denormalized time stamps
- use errno codes to indicate errors (and adapt the few instances of actual error handling to use them)
19670: cpu/stm32: stm32f4 BRR from BSRR r=maribu a=kfessel
### Contribution description
sometimes one wants to save one instruction :)
just write the bits we need to write.
### Testing procedure
tests/periph/gpio_ll tests this
### Issues/PRs references
`@maribu` might know some reference
maybe #19407
19678: gnrc_sixlowpan_iphc: fix NULL pointer dereference r=maribu a=miri64
19679: gnrc_sixlowpan_frag_sfr: fix ARQ scheduler race-condition r=maribu a=miri64
19680: gnrc_sixlowpan_frag_rb: fix OOB write in _rbuf_add r=maribu a=miri64
19681: sys/xtimer: improve documentation r=maribu a=maribu
### Contribution description
- Add a warning that xtimer is deprecated, so that new code hopefully starts using ztimer
- Add a hint that `ztimer_xtimer_compat` can be used even after `xtimer` is gone
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
- point out behavior on denormalized time stamps
- use errno codes to indicate errors (and adapt the few instances of
actual error handling to use them)
The assumption that all STM32 timers have exactly four channels no
longer holds. E.g. the STM32L4 has the following general purpose timers:
- TIM2: 32 bit, 4 channels
- TIM15: 16 bit, 2 channels
- TIM16: 16 bit, 1 channel
Hence, a new field is added to the timer configuration to also contain
the number of timer channels. Due to alignment the `struct` previously
was padded by 16 bit, so adding another 8 bit field doesn't increase
its size.
For backward compatibility, a value of `0` is considered as alias for
`TIMER_CHANNEL_NUMOF` (or 4), so that the number of timer channels
only needs to be set when the timer is different from the typical 4
channel timer. This helps backward compatibility.
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>
19335: ipv6/nib: 6LBR should not send RS on their downstream interface r=fabian18 a=fabian18
19581: cpu/samd5x: enable FDPLL1 at 200MHz r=benpicco a=dylad
### Contribution description
This PR allows to use the second FDPLL (the first one is used to generated the 120MHz frequency used by the core and some peripherals). The second FDPLL is setup to run at 200MHz which is the maximum allowed by this MCU.
In fact, I reused the existing function which setup FDPLL0 so it can be used in a generic way for both PLL (since they are the same IP).
I change the way the computation offset (left shift by 5) is done because 200MHz << 5 wouldn't fit inside an `uint32_t` and I wanted to avoid using an `uint64_t` here
Two additional commits are present for a small cleanup and a fix.
This is currently unused in our codebase, so it shouldn't impact this platform too much as the `ONDEMAND` bit is set. the FDPLL will not be running out of the box. But `@gschorcht` might need it pretty soon.
### Testing procedure
This PR can be tested on a `same54-xpro` and an oscilloscope using the following the patch:
```
From 76490845ec72387b24116bdd364a61365c186aa1 Mon Sep 17 00:00:00 2001
From: Dylan Laduranty <dylan.laduranty@mesotic.com>
Date: Thu, 11 May 2023 17:42:16 +0200
Subject: [PATCH] removeme! for debug purpose
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
---
cpu/samd5x/cpu.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/cpu/samd5x/cpu.c b/cpu/samd5x/cpu.c
index f778991a5b..2866c8c9e5 100644
--- a/cpu/samd5x/cpu.c
+++ b/cpu/samd5x/cpu.c
`@@` -220,7 +220,7 `@@` static void fdpll_init(uint8_t idx, uint32_t f_cpu)
}
static void gclk_connect(uint8_t id, uint8_t src, uint32_t flags) {
- GCLK->GENCTRL[id].reg = GCLK_GENCTRL_SRC(src) | GCLK_GENCTRL_GENEN | flags | GCLK_GENCTRL_IDC;
+ GCLK->GENCTRL[id].reg = GCLK_GENCTRL_SRC(src) | GCLK_GENCTRL_GENEN | flags | GCLK_GENCTRL_OE | GCLK_GENCTRL_IDC;
while (GCLK->SYNCBUSY.reg & GCLK_SYNCBUSY_GENCTRL(id)) {}
}
`@@` -384,6 +384,12 `@@` void cpu_init(void)
dma_init();
#endif
+ sam0_gclk_enable(SAM0_GCLK_200MHZ);
+ /* output both FDPLL (GCLK0 and GCLK4) to gpios */
+ gpio_init_mux(GPIO_PIN(PB, 14), GPIO_MUX_M);
+ gpio_init_mux(GPIO_PIN(PB, 10), GPIO_MUX_M);
+ /* PB14 -> EXT2 PB10 -> QSPI SCK */
+
/* initialize stdio prior to periph_init() to allow use of DEBUG() there */
early_init();
--
2.35.3
```
It will output both FDPLLs to PB14 and PB10. Their frequency can then be measured using an oscilloscope.
### Issues/PRs references
None.
19612: pkg/ndn-riot: drop unmaintained pkg r=benpicco a=maribu
### Contribution description
Upstream [1] has seen no activity since 2018, so it safe to assume this is dead. It is reasonable to assume that any users - if there ever were any - have moved on.
Fixes https://github.com/RIOT-OS/RIOT/issues/15638
[1]: https://github.com/named-data-iot/ndn-riot
19643: examples/suit_update: some test fixes r=aabadie a=kaspar030
19655: net/ipv6: make use of clz in ipv6_addr_match_prefix() r=benpicco a=benpicco
Co-authored-by: Fabian Hüßler <fabian.huessler@st.ovgu.de>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work. A minimum `RIOTBOOT_LEN` of `0x2000` is required for WB.
19611: sys/net/rpl: fix possible NULL dereference r=benpicco a=maribu
### Contribution description
As the title says
19640: core/thread: drop unused thread_arch_t r=benpicco a=maribu
### Contribution description
No architecture makes use of thread_arch_t anymore, so let's drop it.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19628: Fix periph clk r=aabadie a=Enoch247
### Contribution description
This fixes some minor doc and argument type errors. See commit messages for details.
### Testing procedure
It compiles without errors for me.
### Issues/PRs references
None known
19637: sys/usb/usbus_msc: fix typo in C expression r=aabadie a=maribu
### Contribution description
Rather than setting the correct blk_len, the code only wrote 1 and 0 into the three bytes due to the use of a logic and where a bitwise and should be used.
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19433: cpu/esp32: deduplication in Kconfig for ESP32x SoCs r=aabadie a=gschorcht
### Contribution description
This PR reduces the code duplication in Kconfig for ESP32x SoCs.
It defines a new common CPU symbol `CPU_COMMON_ESP32X` in Kconfig that is used by all `CPU_FAM_ESP32x` symbols. It selects all features, modules and packages that are common for all ESP32x SoC variants. This avoids the selection of features, modules and packages again and again for each ESP32x SoC variant.
The same is done in PR #19432 for common ESP32x board definitions.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19619: cpu/arm7: Fix undefined behavior based on invalid assembly r=aabadie a=Teufelchen1
### Contribution description
Hellooo! 🦤
In this PR a single `NOP` is added after an `ldm` in ARM7 common code in the scheduling management.
The change is necessary because this particular `ldm` affects certain banked registers, including `R14 / lr`. The next instruction then immediately accesses `lr`. This is invalid and the exact effect depends on the underlying hardware implementation. An intermediate `NOP` ensures correct behaviour in such cases.
The ARM docs can be found [here](https://documentation-service.arm.com/static/5f8dacc8f86e16515cdb865a), in section `A4.1.21 LDM (2)`. It states:
> In ARM architecture versions earlier than ARMv6, this form of LDM must not be
followed by an instruction that accesses banked registers. A following NOP is a good
way to ensure this.
### Testing procedure
Without this change, on the Game Boy Advance, RIOT behaves irregularly. With the `NOP`, it works fine!
If possible, this change should be tested on other ARM7 hardware as well but I do not have access to any.
----
Special thanks `@pyropeter` for spotting the extremely tiny note on this issue within the ARM docs. You saved me hours of tears! 👾
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
19572: cpu/stm32/periph_pwm: support of complementary timer outputs r=maribu a=gschorcht
### Contribution description
This PR provides the support of complementary timer outputs as PWM channels for advanced timers (TIM1/TIM8).
To use a complementary output of an advanced timer as PWM channel, the output is defined with an offset of 4, i.e. normal outputs are in the range of 0 to 3 (CH1...CH4) and complementary outputs are in the range of 4 to 6 (CH1N...CH3N). If the defined output is less than 4, the normal output is enabled, otherwise the complementary output is enabled.
This change is required to support PWM on boards that have connected the complementary outputs of advanced timers to the PWM connector pins, for example the STM32L496-DISCO board.
### Testing procedure
- Green CI
- Use any STM32 board which supports the `periph_pwm` feature. `tests/periph_pwm` should still work.
- Change the configuration for this board so that either timer TIM1 or TIM8 and a complementary channel is used for any exposed GPIO. `tests/periph_pwm` should also work with such a configuration.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The current implementation uses the core clock frequency to calculate
the needed prescalar to achieve a given ADC clock frequency. This is
incorrect. This patch fixes the calculation to use the correct source
clock (PCKLK2 ie APB2). It also changes the defined max clock rate to
use the frequency macro to improve readability.
To use a complementary output of an advanced timer as PWM channel, the output is defined with an offset of 4, i.e. normal outputs are in the range of 0 to 3 (CH1...CH4) and complementary outputs are in the range of 4 to 6 (CH1N...CH3N). If the defined output is less than 4, the normal output is enabled, otherwise the complementary output is enabled.
- Replace all users of `$(RIOTBASE)/build` with the already present
`$(BUILD_DIR)` variable
- Replace all users of `$(BUILD_DIR)/pkg` with the already present
`$(PKGDIRBASE)` variable
- Create a `CACHEDIR.TAG` file in the `$(BUILD_DIR)`
These functions can be used to set both FDPLL0 and FDPLL1 by using an extra argument 'idx' (index) and allow to set the ONDEMAND bit using the 'flags' argument
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Provide a common clock initialization driver rather than leaving
clock initialization to the boards code. A declarative description of
the board's clock configuration using a struct does still allow to
fine-tune settings. In addition, a board is still allowed to just
provide a custom `void clock_init(void)` if there really is the need
to do crazy things.
18056: pkg/cmsis: use unique package for CMSIS headers, DSP and NN modules r=benpicco a=aabadie
19571: cpu/stm32/periph_adc: fixes and improvements for L4 support r=benpicco a=gschorcht
### Contribution description
This PR provides the following fixes and improvements for the `periph_adc` implementation for STM32L4.
- Support STM32L496AG added.
- Instead of defining the number of ADC devices for each MCU model, the number of ADC devices is determined from ADCx definitions in CMSIS header.
- MCU specific register/value defines are valid for all L4 MCUs, model based conditional compilation is removed.
- The ADC clock disable function is fixed using a counter. The counter is incremented in `prep` and decremented in `done`. The ADC clock is disabled if the counter becomes 0.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- The ASCR register is available and has to be set for all STM32L471xx, STM32L475xx, STM32L476xx, STM32L485xx and STM32L486xx MCUs. Instead of using the CPU model for conditional compilation, the CPU line is used to support all MCU of that lines.
- Setting of SQR1 is fixed. Setting the SQR1 did only work before because the `ADC_SRQ_L` is set to 0 for a sequence length of 1.
- Setting the `ADC_CCR_CKMODE` did only work for the reset state. It is now cleared before it is set. Instead of using the `ADC_CCR_CKMODE_x` bits to set the mode, the mode defines are used.
- Support for V_REFINT as ADC channel added.
### Testing procedure
19589: gnrc/gnrc_netif_hdr_print: printout timestamp if enabled r=aabadie a=chudov
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chudov <chudov@gmail.com>
Setting the `ADC_CCR_CKMODE` did only work for the reset state. It is now cleared before it is set. Instead of using the `ADC_CCR_CKMODE_x` bits to set the mode, the mode defines are used.
19573: cpu/stm32/periph_dac: small improvements r=maribu a=gschorcht
### Contribution description
This PR provides the following improvements for `periph_dac` on STM32
- Support for `RCC_APB1ENR1_DAC1EN` symbol added.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- If the DAC peripheral has a mode register (`DAC_MCR`), it is set to normal mode with buffer enabled and connected to external pin and on-chip peripherals. This allows to measure the current value of a DAC channel with an ADC channel or to use the DAC channel also for other on-chip peripherals.
### Testing procedure
- Green CI
- `tests/periph_dac` should still work for any board supporting the `periph_dac` feature.
### Issues/PRs references
19579: doc/doxygen/src/flashing.md: work around Doxygen bug r=maribu a=maribu
### Contribution description
Doxygen fails to render inline code in headers correctly in the version the CI uses. So, work around the issue by not typestetting `stm32flash` as inline code but as regular text.
19583: tests: move cpu related applications to tests/cpu r=maribu a=aabadie
19584: tests/build_system/external_board_dirs: fix broken symlinks r=maribu a=aabadie
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19565: tests: move core related applications to their own tests/core/ folder r=maribu a=aabadie
19568: tests: move remaining driver related applications to tests/drivers r=maribu a=aabadie
19574: cpu/stm32/periph_gpio: reset PU/PD for ADC channels r=maribu a=gschorcht
### Contribution description
This PR provides a small fix that is relevant when a GPIO has been used as input/output with a pull resistor before it is initialized as an ADC channel.
The PU/PD configuration has to be `0b00` for analog outputs which is corresponds to the reset state. However, if the GPIO is not in the reset state but was used digital input/output with any pull resistor, the PU/PD configuration has also to be reset to use it as ADC channel.
### Testing procedure
- Green CI
- The `periph_adc` test application should still work for any board that supports the `periph_adc` feature.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19484: makefiles/arch/msp430.inc.mk: Fix compilation issues with GCC 12 r=maribu a=maribu
### Contribution description
This fixes the following compilation issues:
/home/maribu/Repos/software/RIOT/cpu/msp430fxyz/periph/gpio.c: In function 'gpio_periph_mode':
/home/maribu/Repos/software/RIOT/cpu/msp430fxyz/periph/gpio.c:95:15: error: array subscript 0 is outside array bounds of 'msp_port_isr_t[0]' [-Werror=array-bounds]
95 | sel = &(isrport->SEL);
| ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
by adding `CFLAGS += --param-min-pagesize=0` for GCC 12 (same issue as already fixed for AVR).
and:
/usr/lib/gcc/msp430-elf/12.2.0/../../../../msp430-elf/bin/ld: warning: /home/maribu/Repos/software/RIOT/cpu/msp430_common/ldscripts/xfa.ld contains output sections; did you forget -T?
by adding the missing `-T`.
### Testing procedure
The following should still work:
- `make BOARD=msb-430 -C examples/hello-world`
- `make BOARD=msb-430 -C tests/xfa flash test`
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The ASCR register is available and has to be set for all STM32L471xx, STM32L475xx, STM32L476xx, STM32L485xx and STM32L486xx MCUs. Instead of using the CPU model for conditional compilation, the CPU line is used to support all MCU of that lines.
For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ if supported by setting `VREFBUF_ENABLE=1`.
The ADC clock disable is fixed using a counter. The counter is incremented in `prep` and decremented in `done`. The ADC clock is disabled if the counter becomes 0.
If the DAC peripheral has a mode register (DAC_MCR), it is set to normal mode with buffer enabled and connected to external pin and on-chip peripherals. This allows to measure the current value of a DAC channel or to use the DAC channel also for other on-chip peripherals.
For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ if supported by setting `VREFBUF_ENABLE=1`.
PU/PD configuration has to be `0b00` for analog outputs which is corresponds to the reset state. However, if the GPIO is not in reset state but was used digital input/output with any pull resistor, the PU/PD configuration has also to be reset to work as ADC channel.
An `INSERT AFTER` directive no longer can refer to a different linker
script included with `-T path/to/script.ld`. Instead, this adds wrapper
linker scripts that just `INCLUDE` the three individual linker scripts.
This way, the xfa.ld can safely refer back to sections defined in
the vendor linker script.
For some reason, this approach cause the exact issue it fixes for
binutils 2.40 with the binutils in the CI. We stick with the old
linker flags with binutils prior 2.40 to be compatible with both
conflicting behaviors.
The best approach would be to come up with something that works across
different versions of binutils; but no such solution materialized.
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>
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.
19516: cpu/rpx0xx: add initial ADC support r=dylad a=dylad
### Contribution description
This PR adds initial support for RP2040 ADC peripheral.
It is rather minimalist, and only use oneshot trigger to perform a single acquisition.
I've tested this PR using a potentiometer connected between GND and 3V3.
GP26, GP27, GP28 has been tested.
### Testing procedure
Select `ADC_RES_12BIT` and flash `tests/periph_adc`
`make BOARD=rpi-pico -C tests/periph_adc`
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19346: pkg/tinydtls: allow build for AVR r=benpicco a=benpicco
19512: SUBSYSTEMS.md: add jia200x to subsystems r=benpicco a=jia200x
19513: boards/nrf52840dongle/doc: Update nrfutil pointers r=benpicco a=chrysn
### Contribution description
Nordic changed its nrfutil; this change adjust to it.
I'm not fully happy with recommending that tool at all due to its bad quality (see rambling in https://github.com/RIOT-OS/RIOT/issues/19511), but short of soldering on a debug header or touch-probing it with wires it's the only way in to the device. I may later add follow-up recommendations to switch to riotboot, but this now at least fixes the immediate issue.
### Testing procedure
* Look at the updated documentation.
### Issues/PRs references
Closes: https://github.com/RIOT-OS/RIOT/issues/19511
19514: dist/testbed-support: remove obsolete boards from iotlab archi r=benpicco a=aabadie
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19507: cpu/cc26x0_cc13x0: Drop feature cortexm_mpu r=maribu a=maribu
### Contribution description
At least the CC2650 doesn't have an MPU, I assume this is also true for the rest of the family.
The CC2652 does have an MPU according to the datasheet. So I keep the feature there in place.
### Testing procedure
E.g.
```
make BOARD=cc2650-launchpad -C tests/mpu_noexec_ram flash test
```
fails. (Note: A successful test run would also crash but with a mem manage handler rather than a hardfault due to an invalid instruction on the stack being executed.)
It would be nice to also test the same for a `cc2652-launchpad`, for which the MPU should work.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
At least the CC2650 doesn't have an MPU, I assume this is also true
for the rest of the family.
The CC2652 does have an MPU according to the datasheet. So I keep the
feature there in place.
GCC 12 create a bogus array out of bounds warning as it assumes that
because there is special handling for `uart == 0` and `uart == 1`,
`uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above
that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for
when `UART_NUMOF == 1` likely improves the generated code and fixes
the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
To be able to reconfigure the PLL multiplier in clock configuration, the existing value has to be reset first. This becomes necessary when changing the core clock, e.g. when booting with riotboot an application that uses USB.
To allow CPU specific definitions in `cpu.h`, `riscv_common/cpu.h` is renamed to ``riscv_common/cpu_common.h` and included in new `cpu.h` files for FE310 and GD32V.
19450: cpu/esp32: fix compilation issues with GCC 12.2 r=benpicco a=gschorcht
### Contribution description
This PR provides the changes in `cpu/esp32` and `cpu/esp_common` to fix the compilation issues with GCC v12.2. It is required as the first step in the preparation of the upgrade to ESP-IDF version 5.1.
**Please note**: Insead of fixing the ESP-IDF 4.4 code itself by a big bunch of patches to fix the compilation problems with GCC v12.2, it temporarily disables some warnings. The reason is that the ESP-IDF 5.1 requires GCC v12.2 and should be fixed for this compiler version by the vendor.
### Testing procedure
Green CI
The change were already tested with all ESP-specific modules like `esp_now`, `esp_wifi`, `esp_spi` and `esp_ble` for all supported ESP platforms.
### Issues/PRs references
Prerequisite for https://github.com/RIOT-OS/riotdocker/pull/227
Fixes issue #19421
19476: native/syscalls: rename real_clock_gettime to clock_gettime r=benpicco a=Teufelchen1
### Contribution description
When compiling RIOT for native using a recent LLVM and enabling ASAN, one might encounter "Duplicated symbol".
This is due to a name clash with `real_clock_gettime()` in compiler-rt from [LLVM](f50246da65), I renamed RIOTs `real_clock_gettime` and just default to the posix function `clock_gettime`. The wrapper existed, most likely, for consistency only.
(The best solution would probably to convince the LLVM folks to declare their symbol as `static` and refactor a bit)
### Testing procedure
Passing CI should be enough.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
19460: cpu/stm32/usbdev_fs: fix ep registration and EP_REG assignments r=gschorcht a=dylad
### Contribution description
This PR provides two fixes for the `usbdev_fs` driver:
- Fix endpoints registration
- Fix assignment of toggleable bits in EP_REG(x) registers
These bugs were encountered with the USBUS MSC implementation.
Regarding the endpoints registration:
For the `usbdev_fs` peripheral, IN and OUT endpoints of the same index must have the same type.
For instance, if EP1 OUT is a bulk endpoint, EP1 IN must either be unused or used as bulk too but it cannot be used as interrupt or isochronous.
With the previous check, the following registration pattern (EP OUT Bulk -> EP IN Interrupt -> EP IN Bulk) would assign both EP OUT Bulk and EP IN Interrupt to same endpoint index. So the configuration would be broken.
Applying the same registration pattern with this patch would now produce EP OUT Bulk -> 1 / EP IN Interrupt -> 2 / EP IN Bulk 1. Which is a working configuration for this IP.
and for the second fix:
EP_REG(x) registers have a total of 6 toggleable bits. Those bits can only be toggled if we write a one to it, otherwise writing a zero has no effect
This commit fixes all the access to these registers to prevent from modifying these bits when not needed.
Without this patch, the endpoint status (VALID / NACK / STALL) can be erroneously modify because bits are not cleared when assigning the new content to the register and thus make the bits toggle and change values.
### Testing procedure
This can be tested with tests/usbus_msc on any board using this `usbdev_fs` driver.
It is easier to test this PR with #19443 alongside. Then the following would be enough:
`CFLAGS='-DSECTOR_COUNT=64' USEMODULE='mtd_emulated' make -j8 BOARD=p-nucleo-wb55 -C tests/usbus_msc flash`
Otherwise this can also be tested by attaching a SPI<->SDCARD adapter.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
EP_REG(x) registers have a total of 6 toggleable bits. Those bits can only be toggled if we write a one to it, otherwise writing a zero has no effect
This commit fixes all the access to these registers to prevent from modifying these bits when not needed
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
For the usbdev_fs peripheral, IN and OUT endpoints of the same index must have the same type.
For instance, if EP1 OUT is a bulk endpoint, EP1 IN must either be unused or used as bulk too but it cannot be used as interrupt or isochronous.
With the previous check, the following registration pattern (EP OUT Bulk -> EP IN Interrupt -> EP IN Bulk) would assign both EP OUT Bulk and EP IN Interrupt to same endpoint index. So the configuration would be broken.
Applying the same registration pattern with this patch would now produce EP OUT Bulk -> 1 / EP IN Interrupt -> 2 / EP IN Bulk 1. Which is a working configuration for this IP
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
The comments still claim STM32F1 support is missing, but this was
recently added.
Also, drop an empty line to fix `too many consecutive empty lines`
nitpick of the CI.
The driver previously failed to reliably clear the RXNE bit, resulting
in the next transfer to incorrectly read a stale register value. This
was noticed with the SD card SPI driver on an STM32F4, in which the
0xff byte of the previous byte transfer was returned instead of the
actual status byte, throwing the SD card driver off the rails.
The commit defines a new common CPU symbol `CPU_COMMON_ESP32X` in Kconfig that is used by all `CPU_FAM_ESP32x` symbols which selects features, modules and packages that are common for all ESP32x SoC variants. This avoids the selection of features, modules and packages again and again for each ESP32x SoC variant.
A number of ESP-IDF header files that are needed to compile RIOT include the header file `driver/gpio.h` only because of the definition of the type `gpio_num_t`. However, this header file contains the entire GPIO API definition of the ESP-IDF, which conflicts with that of RIOT.
The solution was to use a wrapper library that does not need to include the `driver/gpio.h` file of the ESP-IDF during compilation of RIOT code.
This commit provides another approach which does not require such a wrapper library. It just provides its own `driver/gpio.h` in RIOT that is included by ESP-IDF header files instead of the original `driver/gpio.h` in ESP-IDF. It defines only the required `gpio_num_t` if RIOT code is compiled but includes the original `driver/gpio.h` of ESP-IDF if ESP-IDF code is compiled. This avoids to create a wrapper library for each module.
19420: cpu/esp32: use ets_printf instead of puts in startup r=maribu a=gschorcht
### Contribution description
This PR provides a workaround that fixes the problem that restarting an application automatically after flashing it in download mode via USB Serial/JTAG doesn't work and requires a hard reset by pressing the RESET button before it starts.
The reason that the application doesn't restart automatically after flashing it is that an exception occurs if `puts` or `printf` is called during startup before the first interrupt driven context switch in `thread_yield_higher`. The console seems to hange after bootloader:
```
EESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380786
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x6c
load:0x403ce000,len:0x7ec
load:0x403d0000,len:0x2170
entry 0x403ce000
Pro cpu up.
```
However, the system stucks in a exception/printf loop. ESP32-C3 and ESP32-S3 are affected.
### Testing procedure
Flash a ESP32-C3 or ESP32-S3 board that don't have a USB-to-UART chip with reset logic on board, for example
```
BOARD=hip-badge make -j8 -C tests/shell flash
```
or
```
BOARD=esp32s3-pros3 make -j8 -C tests/shell flash
```
Connect a terminal to the the board. Without the PR, the console doesn't seem to work and the RESET button has to pressed explicitly to get it working. With the PR, the console should work.
The problem can also be caused when using
```
dist/tools/esptools/espreset.py -p /dev/ttyACM0
```
while connected with a terminal to the board. Without the PR, the console output stops after
```
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380786
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x6c
load:0x403ce000,len:0x7ec
load:0x403d0000,len:0x2170
entry 0x403ce000
Pro cpu up.
```
while it continues with the PR as following:
```
main(): This is RIOT! (Version: 2023.04-devel-713-gcb721-boards/
test_shell.
>
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19397: drivers/usbdev_synopsys_dwc2: fix and reenable DMA mode r=benpicco a=gschorcht
### Contribution description
This PR fixes the DMA mode for all STM32 USB OTG HS cores (including that for STM32F4xx CID 1.xxx) and reenables it. It fixes remaining problems in issue #19359.
This PR includes also includes some changes that are needed to use the DMA mode:
- EP number is used as defined in CMSIS (if defined) for STM32
- `periph_usbdev_hs` feature is added in Kconfig
- `periph_usbdev_hs` feature is added in board definition of `stm32f429i-disc1`
- largest number of available EPs is used for STM32 instead of the smallest number (to be able to use all EPs of HS peripheral)
- `stm32f429i-disco` is removed from blacklist in `tests/usbus_cdc_ecm` since it uses the HS peripheral
### Testing procedure
The following tests should work
```python
USEMODULE=stdio_cdc_acm BOARD=stm32f429i-disc1 make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[526755.875691] usb 1-2.2: new full-speed USB device number 106 using xhci_hcd
[526755.977853] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x84 has invalid maxpacket 512, setting to 64
[526755.977856] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x2 has invalid maxpacket 512, setting to 64
[526755.978762] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[526755.978764] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[526755.978766] usb 1-2.2: Product: stm32f429i-disc1
[526755.978768] usb 1-2.2: Manufacturer: RIOT-os.org
[526755.978769] usb 1-2.2: SerialNumber: 7C156425A950A8EB
[526755.991190] cdc_acm 1-2.2:1.0: ttyACM1: USB ACM device
[526755.998131] cdc_ether 1-2.2:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, a6:f6:4a:85:1d:c9
[526756.044150] cdc_ether 1-2.2:1.2 enp0s20f0u2u2i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[528733.480207] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[528733.707800] usb 1-4.4: new high-speed USB device number 111 using xhci_hcd
[528733.808257] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[528733.808260] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[528733.808263] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[528733.808642] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[528733.808645] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[528733.808647] usb 1-4.4: Product: stm32f723e-disco
[528733.808649] usb 1-4.4: Manufacturer: RIOT-os.org
[528733.808651] usb 1-4.4: SerialNumber: A6BAC4E1B1E0806B
[528733.811988] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[528733.814456] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, e6:75:97:3a:74:ba
[528733.854371] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[529000.944482] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[529003.728260] usb 1-4.4: new high-speed USB device number 114 using xhci_hcd
[529003.833107] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[529003.833111] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[529003.833113] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[529003.833743] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[529003.833747] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[529003.833749] usb 1-4.4: Product: stm32f746g-disco
[529003.833751] usb 1-4.4: Manufacturer: RIOT-os.org
[529003.833753] usb 1-4.4: SerialNumber: 66FE8934D1A363E0
[529003.837143] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[529003.839755] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, 6a:88:1f:1f:b1:f0
[529003.879025] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0```
```
</details>
### Issues/PRs references
Fixes#19359
19416: cpu/rpx0xx/cmsis: Update vendor header files r=benpicco a=maribu
### Contribution description
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no longer containing bit-fields to represent different fields within registers. While this would generally ease writing code, the RP2040 has the unpleasant feature of corrupting the remaining bits of the register when a write access that is not word-sized occurs in the memory mapped I/O area. This could happen e.g. when a bit field is byte-sized and byte-aligned.
### Testing procedure
No binary changes (hopefully).
### Issues/PRs references
This adds a few additional vendor defines, notably for USB. If anyone were to implement USB, this would be a requirement.
19418: cpu/gd32v: fix gpio_read in periph_gpio r=benpicco a=gschorcht
### Contribution description
This PR fixes a bug in `gpio_read` which made `gpio_read` completely unusable!
A small bug with big consequences. In `gpio_read` the combined port | pin_num parameter `pin` was used instead of the pin number `pin_num` for the call of `_pin_is_input`. This caused the problem that for example instead of accessing GPIOA->CTL0 with address 0x40010800, address 0x60018c00 was accessed. As a result, a pin was randomly detected as input or output and thus a result was arbitrarily returned. Approx. 50% of all inputs always returned LOW.
I found this error by coincidence when I tried to find out why the BOOT0 button on a Sipeed Longan Nano is not usable as a button in RIOT.
### Testing procedure
Flash `tests/periph_gpio`
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio flash
```
and use commands
```
init_in 0 8
read 0 8
```
Without this PR, the pin is always LOW. With the PR, the pin should be HIGH when the BOOT button is pressed.
### Issues/PRs references
19419: boards/sipeed-longan-nano: add BOOT as user button r=benpicco a=gschorcht
### Contribution description
This PR makes the BOOT button usable as a user button.
### Testing procedure
The test requires PR #19418 to work.
Flash and test:
```
BOARD=sipeed-longan-nano make -j8 -C tests/saul flash term
```
The output
```
Dev: BOOT Type: SENSE_BTN
Data: 0
```
should change to
```
Dev: BOOT Type: SENSE_BTN
Data: 1
```
when the BOOT button is pressed.
### Issues/PRs references
Depends on PR #19418
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no
longer containing bit-fields to represent different fields
within registers. While this would generally ease writing code,
the RP2040 has the unpleasant feature of corrupting the
remaining bits of the register when a write access that is not
word-sized occurs in the memory mapped I/O area. This could
happen e.g. when a bit field is byte-sized and byte-aligned.
19407: cpu/stm32/periph: Implement GPIO LL for STM32F1 without IRQ support (yet) r=gschorcht a=maribu
### Contribution description
This implements GPIO LL support for the STM32F1 in the first commit. IRQ support is added with https://github.com/RIOT-OS/RIOT/pull/19412.
This sneaks in a second commit replacing the `expect()` calls in `tests/periph_gpio_ll` with a trivial five-liner that doesn't `panic()`, so that stdio output will still be delivered on high level stdio implementations. The tests provides a lot of useful output to aid debugging, so its a great usability improvement if the test makes sure to actually deliver that output.
### Testing procedure
<details><summary><code>make -C tests/periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:09,188 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:10,299 # START
2023-03-17 18:55:10,307 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:10,309 # Test / Hardware Details:
2023-03-17 18:55:10,310 # ========================
2023-03-17 18:55:10,311 # Cabling:
2023-03-17 18:55:10,313 # (INPUT -- OUTPUT)
2023-03-17 18:55:10,315 # P2.10 (PC10) -- P2.2 (PC2)
2023-03-17 18:55:10,318 # P2.12 (PC12) -- P2.3 (PC3)
2023-03-17 18:55:10,322 # Number of pull resistor values supported: 1
2023-03-17 18:55:10,325 # Number of drive strengths supported: 1
2023-03-17 18:55:10,328 # Number of slew rates supported: 3
2023-03-17 18:55:10,330 # Valid GPIO ports:
2023-03-17 18:55:10,332 # - PORT 0 (PORT A)
2023-03-17 18:55:10,333 # - PORT 1 (PORT B)
2023-03-17 18:55:10,335 # - PORT 2 (PORT C)
2023-03-17 18:55:10,336 # - PORT 3 (PORT D)
2023-03-17 18:55:10,338 # - PORT 4 (PORT E)
2023-03-17 18:55:10,338 #
2023-03-17 18:55:10,341 # Testing gpio_port_pack_addr()
2023-03-17 18:55:10,343 # =============================
2023-03-17 18:55:10,343 #
2023-03-17 18:55:10,344 # All OK
2023-03-17 18:55:10,344 #
2023-03-17 18:55:10,346 # Testing gpip_ng_init()
2023-03-17 18:55:10,348 # ======================
2023-03-17 18:55:10,348 #
2023-03-17 18:55:10,354 # Testing is_gpio_port_num_valid() is true for PORT_OUT and PORT_IN:
2023-03-17 18:55:10,354 #
2023-03-17 18:55:10,358 # Testing input configurations for PIN_IN_0:
2023-03-17 18:55:10,361 # Support for input with pull up: yes
2023-03-17 18:55:10,366 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,369 # Support for input with pull down: yes
2023-03-17 18:55:10,374 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,378 # Support for input with pull to bus level: no
2023-03-17 18:55:10,383 # Support for floating input (no pull resistors): yes
2023-03-17 18:55:10,388 # state: in, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,388 #
2023-03-17 18:55:10,392 # Testing output configurations for PIN_OUT_0:
2023-03-17 18:55:10,397 # Support for output (push-pull) with initial value of LOW: yes
2023-03-17 18:55:10,401 # state: out-pp, slew: slowest, value: off
2023-03-17 18:55:10,404 # Output is indeed LOW: yes
2023-03-17 18:55:10,408 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,411 # Output can be pushed HIGH: yes
2023-03-17 18:55:10,417 # Support for output (push-pull) with initial value of HIGH: yes
2023-03-17 18:55:10,420 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,424 # Output is indeed HIGH: yes
2023-03-17 18:55:10,430 # Support for output (open drain with pull up) with initial value of LOW: no
2023-03-17 18:55:10,437 # Support for output (open drain with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,443 # Support for output (open drain) with initial value of LOW: yes
2023-03-17 18:55:10,449 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,452 # Output is indeed LOW: yes
2023-03-17 18:55:10,458 # Support for output (open drain) with initial value of HIGH: yes
2023-03-17 18:55:10,465 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: on
2023-03-17 18:55:10,470 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,474 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,478 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,483 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,488 # Support for output (open source) with initial value of LOW: no
2023-03-17 18:55:10,494 # Support for output (open source) with initial value of HIGH: no
2023-03-17 18:55:10,501 # Support for output (open source with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,508 # Support for output (open source with pull up) with initial value of LOW: no
2023-03-17 18:55:10,511 # Support for disconnecting GPIO: yes
2023-03-17 18:55:10,515 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,519 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,519 #
2023-03-17 18:55:10,523 # Testing Reading/Writing GPIO Ports
2023-03-17 18:55:10,526 # ==================================
2023-03-17 18:55:10,526 #
2023-03-17 18:55:10,529 # testing initial value of 0 after init
2023-03-17 18:55:10,531 # ...OK
2023-03-17 18:55:10,535 # testing setting both outputs_optional simultaneously
2023-03-17 18:55:10,537 # ...OK
2023-03-17 18:55:10,541 # testing clearing both outputs_optional simultaneously
2023-03-17 18:55:10,543 # ...OK
2023-03-17 18:55:10,547 # testing toggling first output (0 --> 1)
2023-03-17 18:55:10,548 # ...OK
2023-03-17 18:55:10,552 # testing toggling first output (1 --> 0)
2023-03-17 18:55:10,553 # ...OK
2023-03-17 18:55:10,557 # testing toggling second output (0 --> 1)
2023-03-17 18:55:10,558 # ...OK
2023-03-17 18:55:10,562 # testing toggling second output (1 --> 0)
2023-03-17 18:55:10,563 # ...OK
2023-03-17 18:55:10,569 # testing setting first output and clearing second with write
2023-03-17 18:55:10,570 # ...OK
2023-03-17 18:55:10,575 # testing setting second output and clearing first with write
2023-03-17 18:55:10,576 # ...OK
2023-03-17 18:55:10,580 # All input/output operations worked as expected
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,582 # TEST SUCCEEDED
2023-03-17 18:55:10,588 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 456 }]}
```
</details>
<details><summary><code>make -C tests/bench_periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:42,192 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:44,616 # START
2023-03-17 18:55:44,624 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:44,624 #
2023-03-17 18:55:44,626 # Benchmarking GPIO APIs
2023-03-17 18:55:44,628 # ======================
2023-03-17 18:55:44,628 #
2023-03-17 18:55:44,632 # estimating loop overhead for compensation
2023-03-17 18:55:44,635 # -----------------------------------------
2023-03-17 18:55:44,642 # 4168 us for 50000 iterations
2023-03-17 18:55:44,642 #
2023-03-17 18:55:44,647 # periph/gpio: Using 2x gpio_set() and 2x gpio_clear()
2023-03-17 18:55:44,651 # ---------------------------------------------------
2023-03-17 18:55:44,706 # 50000 iterations took 45840 us (50008 us uncompensated)
2023-03-17 18:55:44,713 # Two square waves pins at 1090750 Hz ( 999840 Hz uncompensated)
2023-03-17 18:55:44,719 # ~66 CPU cycles per square wave period (~72 cycles uncompensated)
2023-03-17 18:55:44,719 # :'-(
2023-03-17 18:55:44,719 #
2023-03-17 18:55:44,724 # periph/gpio_ll: Using gpio_ll_set() and gpio_ll_clear()
2023-03-17 18:55:44,729 # -------------------------------------------------------
2023-03-17 18:55:44,738 # 50000 iterations took 695 us (4863 us uncompensated)
2023-03-17 18:55:44,745 # Two square waves pins at 71942446 Hz ( 10281719 Hz uncompensated)
2023-03-17 18:55:44,750 # ~1 CPU cycles per square wave period (~7 cycles uncompensated)
2023-03-17 18:55:44,751 # :-D
2023-03-17 18:55:44,751 #
2023-03-17 18:55:44,755 # periph/gpio: Using 4x gpio_toggle()
2023-03-17 18:55:44,757 # -----------------------------------
2023-03-17 18:55:44,965 # 50000 iterations took 198646 us (202814 us uncompensated)
2023-03-17 18:55:44,972 # Two square waves pins at 251704 Hz ( 246531 Hz uncompensated)
2023-03-17 18:55:44,977 # ~286 CPU cycles per square wave period (~292 cycles uncompensated)
2023-03-17 18:55:44,978 # :'-(
2023-03-17 18:55:44,978 #
2023-03-17 18:55:44,982 # periph/gpio_ll: Using 2x gpio_ll_toggle()
2023-03-17 18:55:44,985 # -----------------------------------------
2023-03-17 18:55:45,010 # 50000 iterations took 15972 us (20140 us uncompensated)
2023-03-17 18:55:45,017 # Two square waves pins at 3130478 Hz ( 2482621 Hz uncompensated)
2023-03-17 18:55:45,023 # ~23 CPU cycles per square wave period (~29 cycles uncompensated)
2023-03-17 18:55:45,023 # :'-(
2023-03-17 18:55:45,023 #
2023-03-17 18:55:45,026 # periph/gpio: Using 4x gpio_write()
2023-03-17 18:55:45,029 # ----------------------------------
2023-03-17 18:55:45,097 # 50000 iterations took 58345 us (62513 us uncompensated)
2023-03-17 18:55:45,103 # Two square waves pins at 856971 Hz ( 799833 Hz uncompensated)
2023-03-17 18:55:45,109 # ~84 CPU cycles per square wave period (~90 cycles uncompensated)
2023-03-17 18:55:45,109 # :'-(
2023-03-17 18:55:45,110 #
2023-03-17 18:55:45,113 # periph/gpio_ll: Using 2x gpio_ll_write()
2023-03-17 18:55:45,117 # ----------------------------------------
2023-03-17 18:55:45,128 # 50000 iterations took 2777 us (6945 us uncompensated)
2023-03-17 18:55:45,135 # Two square waves pins at 18005041 Hz ( 7199424 Hz uncompensated)
2023-03-17 18:55:45,141 # ~4 CPU cycles per square wave period (~10 cycles uncompensated)
2023-03-17 18:55:45,141 # :-)
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,142 # TEST SUCCEEDED
2023-03-17 18:55:45,149 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 448 }]}
```
</details>
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Use the largest instead of the smallest number of available EPs for this definition. This became necessary to be able to use all EPs of a USB OTG HS peripheral if enabled.
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad a=gschorcht
### Contribution description
This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device.
#### Background
In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work.
#### Solution
Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert.
### Testing procedure
1. Green CI
2. Compilation of
```python
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm
```
should lead to compilation error
```python
sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded"
_Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS,
^~~~~~~~~~~~~~
Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed
```
while compilation of
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm
```
should work.
### Issues/PRs references
Fixes issue #19359 partially.
19382: tests/pkg_nanors: use static allocation r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
The STM32 periph_timer driver reads the timer's status flags, then
clears them all. It is possible that a timer interrupt could occur
between reading the flag and clearing it. This would lead to a lost
interrupt.
The timer's status flags can be cleared by software, but can only be set
by the hardware. This patch takes advantage of this by only clearing the
flags it knows are set. The rest of the flags are set, which doesn't
actually change their state.
17086: usbdev: Add dedicated stall functions r=benpicco a=bergzand
### Contribution description
This PR adds dedicated stall functions for usbdev peripherals. Two
functions are added. The first function (usbdev_ep_stall) to enable and
disable the stall condition on generic endpoints. The second function is
a dedicated function to set the stall condition on endpoint zero in both
directions. This status can only be set and should automatically be
cleared by the usbdev implementation (or hardware) after a new setup
request is received from the host.
### Testing procedure
- examples/usbus_minimal should still enumerate correctly on the host side.
- #17085 can be used to demonstrate the ep0_stall function with the `tests/usbus_cdc_acm_stdio/` test
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19343: ztimer: add ztimer_stopwatch convenience functions r=benpicco a=benpicco
19349: cpu/native: Switch to ztimer for gettimeofday r=benpicco a=MrKevinWeiss
### Contribution description
A xtimer is somewhat taken over by ztimer this explicitly uses ztimer instead of relying on the compatibility layer.
### Testing procedure
`make all test -C tests/cpp11_mutex/`
and green murdock I guess.
### Issues/PRs references
19353: doc: add quicklink to boards in navbar r=benpicco a=OlegHahm
### Contribution description
Finding a list of supported boards and how to use them is an essential information. Currently this list is somewhat hidden under "Modules" which is not very intuitive. Hence, I propose to (at least) put a link in the side menu to this overview page.
### Testing procedure
1. Call `make doc`
2. Check the sidebar `${RIOT_BASE}/doc/doxygen/html/index.html` for an entry "Supported Boards"
19361: nanocoap_sock: ensure response address is the same as request address r=benpicco a=benpicco
19363: Fix stm32 timer periodic r=benpicco a=Enoch247
### Contribution description
From the commit msg:
> cpu/stm32/periph/timer: remove unneeded header
>
> I see no reason this header should be included. It does not exist in
> RIOT's source tree. This patch removes the include.
and
> cpu/stm32/periph/timer: fix execution flow
>
> The implmentation of `timer_set_absolute()` has The following problems.
> First, it attempts to restore the auto reload register (ARR) to it's
> default if the ARR was previosly set by `timer_set_periodic()` by
> comparing it to the channel's capture compare (CC) register _after_ it
> has already set the CC register. Secondly, it clears spurious IRQs
> _after_ the CC register has been set. If the value being set is equal to
> the timer's current count (or the two become equal before the supurios
> IRQ clearing happens), this could cause a legitimate IRQ to be cleared.
>
> The implmentation of `timer_set()` has the same error in handling the
> ARR as described above.
>
> This patch reorders the operations of both functions to do:
>
> 1. handle ARR
> 2. clear spurious IRQs
> 3. set channel's CC
> 4. enable IRQ
>
> Additionally, the calulation of `value` in `timer_set()` is moved
> earlier in the function's exec path as a pedantic measure.
### Testing procedure
I tested by doing the following:
1. `make -C tests/periph_timer BOARD=nucleo-f767zi all flash term`
2. press s
3. press [ENTER]
4. observe test passes
5. `make -C tests/periph_timer_periodic BOARD=nucleo-f767zi all flash term`
6. press s
7. press [ENTER]
8. observe test passes
9. `make -C tests/periph_timer_short_relative_set BOARD=nucleo-f767zi all flash term`
10. press s
11. press [ENTER]
12. observe test passes
### Issues/PRs references
- none known
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
The implmentation of `timer_set_absolute()` has The following problems.
First, it attempts to restore the auto reload register (ARR) to it's
default if the ARR was previosly set by `timer_set_periodic()` by
comparing it to the channel's capture compare (CC) register _after_ it
has already set the CC register. Secondly, it clears spurious IRQs
_after_ the CC register has been set. If the value being set is equal to
the timer's current count (or the two become equal before the supurios
IRQ clearing happens), this could cause a legitimate IRQ to be cleared.
The implmentation of `timer_set()` has the same error in handling the
ARR as described above.
This patch reorders the operations of both functions to do:
1. handle ARR
2. clear spurious IRQs
3. set channel's CC
4. enable IRQ
Additionally, the calulation of `value` in `timer_set()` is moved
earlier in the function's exec path as a pedantic measure.
19341: Picolibc updates r=benpicco a=keith-packard
### Contribution description
Minor updates to picolibc support for newer versions of picolibc, including 1.8.
### Testing procedure
Here's the current build result for a board I happen to have on my bench right now:
```
$ make -C examples/blinky BOARD=nucleo-f103rb FEATURES_REQUIRED=picolibc
...
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:319:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
319 | _READ_WRITE_RETURN_TYPE read(int fd, void *dest, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:351:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
351 | _READ_WRITE_RETURN_TYPE write(int fd, const void *src, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
...
```
### Description of changes
1. Fix the read/write return values (Picolibc 1.8 uses POSIX standard types now)
2. Add new symbols to linker scripts (Picolibc needs help dealing with TLS alignment)
3. Align stack and thread local storage block during thread setup.
19345: cpu/riscv_common: convert to uword_t usage r=benpicco a=dylad
### Contribution description
This PR makes use of `uword_t` type in a few places in `cpu/riscv_common`.
This should not have any effect on produced binaries.
### Testing procedure
CI should be enough.
### Issues/PRs references
Quickly adapt from #16994. It will help for 64 bits support one day ;)
Co-authored-by: Keith Packard <keithp@keithp.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Newer picolibc versions require some additional symbols defined in the
linker script to correctly manage alignment constraints on thread
local storage.
Signed-off-by: Keith Packard <keithp@keithp.com>
19329: MAINTAINING.md: add some notes on Bors r=benpicco a=benpicco
19330: native/stdio: Explicitly provide getchar r=chrysn a=chrysn
### Contribution description
This ensures that even when libc does not implement getchar through getc, any custom stdio is still in the loop when getchar is used.
Frankly, I don't know when this broke -- I'm pretty sure custom stdio worked just a few days ago -- but either way, without this patch RIOT on native currently bypasses a configured stdio for me.
### Testing procedure
* `make -C examples/saul all debug`
* `break stdio_read`
* `run`
Without this patch, observe how the shell runs w/o ever breaking. After, lots of breakpoint hits.
This is the way it behaves for me (Debian sid, libc6:i386 2.36-8). If it works for you before this patch, we might start bisecting the differences between the systems, but we may also accept that libcs may imlpement getchar in different ways, and not all of them pass by the getc which we're patching.
### Issues/PRs references
This is needed for testing #19289.
The implementation stems from the `fgetc(3)` man page, which states that "getchar() is equivalent to getc(stdin)".
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: chrysn <chrysn@fsfe.org>
This allows automatically moving format strings to flash, provided that
code previously compiled fine with `-Wformat-nonliteral` (which in RIOT
is the case due to `-Wformat=2`).
This adds a layer of convenience abstraction over classical Harvard
architectures (like most AVRs) that do not map the flash memory into
the data address space and modern Harvard architectures or von-Neumann
architectures that do so. The motivation is to safe a lot of RAM for
AVR by storing constant strings into flash.
