When riotboot/slot.h is included, but riotboot is not enabled in the
build, a compiler error occures. This is because SLOT0_LEN is not
defined. This patch fixes this by surrounding the offending macrro with
a conditional compile. `riotboot_slot_size()` may still be called, in
which case it returns 0 for the size of any slot given.
The function signature in the Doxygen generated doc was incorrect.
Given that the implementation does have the correct signature, the
impact may not be that large. Still, incorrect doc is confusing, so
let's fix it.
20003: coap: create typedef for CoAP methods r=benpicco a=benpicco
20028: nanocoap: fix incorrect uses of coap_get_code() r=benpicco a=benpicco
20036: boards/nucleo-l4r5zi : add PWM configuration r=benpicco a=krzysztof-cabaj
### Contribution description
This PR adds to the Nucleo-l4r5zi PWM configuration
### Testing procedure
Flash the board using `tests/periph/pwm` program. Check if you could, for example, change LED
intensity using PWM.
### Issues/PRs references
None.
20041: pkg/littlefs2: bump to v2.8.1 r=benpicco a=bergzand
### Contribution description
Minor version number bump.
### Testing procedure
- Check if I copied the correct commit hash.
- Run the tests.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
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>
19963: sys/event/timeout: add event_timeout_is_pending() r=benpicco a=benpicco
19971: sys/shell/gnrc_netif: Fix a few blockers for sharing ifconfig shell r=benpicco a=yarrick
19974: gnrc_ipv6_ext_frag: _completed: Add comment why list head is not checked for NULL pointer dereference r=benpicco a=miri64
19975: pkg/nanocbor: Bump to latest commit r=benpicco a=bergzand
### Contribution description
Not much to see here
Important changes:
- Add stream-like interface for encoder
- Separate functions for number of items left in arrays and maps
### Testing procedure
The usual test should still work
### Issues/PRs references
None
19976: core: Express -1 as ~0 in thread_status_t cast r=benpicco a=SimonIT
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Erik Ekman <eekman@google.com>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: SimonIT <simonit.orig@gmail.com>
Router Advertisements are enabled automatically for routing nodes
as soon as they obtain a prefix (e.g. via DHCPv6, UHCP, …).
Enabling router advertisements without a prefix to advertise is
wrong and causes no router solicitations to be send on an upstream
interface.
Also from https://www.rfc-editor.org/rfc/rfc4861#section-6.2.1
Note that AdvSendAdvertisements MUST be FALSE by
default so that a node will not accidentally start
acting as a router unless it is explicitly
configured by system management to send Router
Advertisements.
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>
19876: sys/net/ipv4/addr: fix typos r=benpicco a=Enoch247
### Contribution description
This patch fixes some typos in the doxygen doc.
### Testing procedure
Nothing to test. No change to code.
### Issues/PRs references
- None known
19878: makefiles/usb_board_reset.mk: declare term-delay target with test target r=benpicco a=aabadie
19888: boards/sltb009a: complete and fix documentation r=benpicco a=gschorcht
### Contribution description
This PR completes and fixes the documentation which was still in the state as generated automatically by `efm2riot`.
The PR also includes a fix of the configuration of the second UART device that was find out while completing the documentation.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19487: nanocoap: implement extended tokens (RFC 8974) r=benpicco a=benpicco
19808: boards: add ESP32-S3-USB-OTG support r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [ESP32-S3-USB-OTG](https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32s3/esp32-s3-usb-otg/user_guide.html) board.
The SD card can only be used in SPI mode at the moment. As soon as PR #19786 is merged, the SD/MMC support can be enabled and the SD card can then be used in SD mode with 4-bit data bus width.
The display uses uses the ST7789 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` (e57c48a33ee2a869c15603788e5306ba066f91cf). 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. This change is also part of PR #19807.
~The PR includes a very small documentation fix for ESP32-S3-DevKit board that was noticed during the development of this board definition (1155b6ac1b8efa39d8a0bd7150e602095159fdc1).~
### Testing procedure
The board has been tested with all basic tests for supported hardware including `tests/driver/st3375`:
- [x] tests/drivers/st3375
- [x] tests/periph/gpio
- [x] tests/periph/pwm
- [x] tests/periph/spi
- [x] tests/periph/uart
- [x] tests/sys/usbus_cdc_ecm
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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
19686: sys/string_utils: add memchk() r=maribu a=benpicco
19687: tests/unittests: remove old workaround for SAML1X and gcc9.X bug r=maribu a=dylad
### Contribution description
This reverts #13462, this workaround is no longer needed with newer GCC version.
### Testing procedure
Try to compile tests/unittests for `saml11-xpro` or `saml10-xpro`
### Issues/PRs references
This is a revert of #13462.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.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>
- Add a deprecation note to xtimer, so that new code hopefully
starts using ztimer
- Add a hint that `ztimer_xtimer_compat` can be used even after `xtimer`
is gone
19268: shell_lock: don't set CONFIG_SHELL_SHUTDOWN_ON_EXIT r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19601: SUIT: Prepared manifests r=chrysn a=chrysn
### Contribution description
While SUIT can generally be used already with manifests that are "dropped into memory" (by any mechanism), the convenient SUIT worker thread mechanism so far could not be used with it.
This adds the suit_worker_try_prepare / suit_worker_trigger_prepared
pair for using the SUIT worker, and breaks suit_handle_manifest_buf out
of suit_handle_url (where the latter now calls the former).
#### By-catch
As part of factoring out reaping of the zombie worker thread, a locking
error that deadlocks the SUIT worker in case the race between the mutex
being unlocked and the thread being reaped hits the necessary handling
code is fixed (and mutex_unlock is called in the error path).
### Testing procedure
SUIT tests should pass.
https://github.com/RIOT-OS/RIOT/pull/19659 provides a demo of how the new API is used.
### Issues/PRs references
I think that the currently employed mechanism of having a resource to which a URL with the manifest gets posted is contrary to the design goals of SUIT -- the signed manifest should be what justifies the device to spend resources (eg. get data from a server), not a URI that is just *not* signed.
This PR makes it easier to implement a resource to which the manifest can be POSTed, rather than a CoAP URI that represents the manifest, as is proposed (but not mature) in
https://github.com/RIOT-OS/RIOT/pull/19659.
[edit: Adjusted to reflect decisions made during review]
Co-authored-by: chrysn <chrysn@fsfe.org>
This adds the suit_worker_try_prepare / suit_worker_trigger_prepared
pair for using the SUIT worker, and breaks suit_handle_manifest_buf out
of suit_handle_url (where the latter now calls the former).
As part of factoring out reaping of the zombie worker thread, a locking
error that deadlocks the SUIT worker in case the race between the mutex
being unlocked and the thread being reaped hits the necessary handling
code is fixed (and mutex_unlock is called in the error path).
This drops special handling for Mac OS (X) `native`, which is not
supported anymore anyway and causing issues when building for
non-`native` targets on Mac OS.
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>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
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];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
This extends support for the GET STATUS requests to support endpoints
and interfaces as recipient. It also adds the SET and CLEAR FEATURE
requests for the endpoints with support to set and clear the halt
condition on an endpoint.
Instead of directly stalling an endpoint, handlers should enable the
halt condition on an usbus endpoint to signal error condition.
This can then be cleared via a CLEAR FEATURE request from the host.
19392: ztimer: Fix doc on ztimer_remove r=benpicco a=bergzand
### Contribution description
See the subject
### Testing procedure
Read the modified docs
### Issues/PRs references
None
19398: gnrc_ipv6_static_addr: fix build with only static address r=benpicco a=benpicco
19399: drivers/usbdev_synopsys_dwc2: add ESP32x power management r=benpicco a=gschorcht
### Contribution description
This PR adds power management handling for ESP32x SoCs.
### Testing procedure
Use and ESP32-S2 or ESP32-S3 board and flash `tests/periph_pm` using the `stdio_cdc_acm`
```
USEMODULE=stdio_cdc_acm BOARD=esp32s3-devkit make -j8 -C tests/periph_pm flash
```
Connect the terminal to the board and execute command:
```
set_rtc 1 1
```
The console should continue to work after the 1-s light sleep.
### Issues/PRs references
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
To be able to check during compilation that the number of endpoints provided by a USB peripheral is not exceeded, each interface class has to define the number of IN and OUT endpoints it requires.
19365: bootloaders: fix bootloader button logic r=benpicco a=dylad
### Contribution description
In lastest master, the `BTN_BOOTLOADER_INVERTED` logic doesn't work as expected.
This PR fixes the underlying logic by replacing the `BTN_BOOTLOADER_INVERTED` macro definition by a runtime function.
In fact the current code:
```
#ifndef BTN_BOOTLOADER_INVERTED
#if (BTN0_MODE == GPIO_IN_PD)
#define BTN_BOOTLOADER_INVERTED false
#else
#define BTN_BOOTLOADER_INVERTED true
#endif
#endif
```
cannot work because both `BTN0_MODE` and `GPIO_IN_PD` are not known by the precompiler as they are enum values defined at cpu level.
Thus, replaces it by a runtime function in our bootloader applications.
I've also add `GPIO_OD_PU` along side `GPIO_IN_PU` and add a new define (which can be override at board level or app level) in case an external pullup is used.
### Testing procedure
Flash the riotboot_dfu bootloader:
`make BOARD=saml21-xpro -C bootloaders/riotboot_dfu flash`
Then, flash any test app:
`PROGRAMMER=dfu-util USEMODULE=usbus_dfu make BOARD=saml21-xpro -C tests/shell riotboot/flash-slot0`
With master, the application will not start.
With this PR, the application will start after flashing.
### Issues/PRs references
Fixes#19364
19366: nanocoap_sock: don't include token in empty ACK response r=benpicco a=benpicco
19367: cord: bump reference from draft to rfc r=benpicco a=bergzand
### Contribution description
The draft is an RFC, this bumps the "see also" in the docs to the rfc.
### Testing procedure
Check that the correct RFC is linked in the docs.
### Issues/PRs references
None
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.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>
19358: sys/usbus/cdc/ecm: fix High-Speed mode r=dylad a=gschorcht
### Contribution description
This PR provides some changes to fix the USBUS CDC ECM interface in High-Speed mode.
In High-Speed mode, the EP data size has to be at least 512 bytes instead of 64 Byte in Full-Speed mode. To be able to define configurations like EP data sizes depending on whether Full-Speed or High-Speed USB device peripherals are used, the feature `periph_usbdev_hs`/`HAD_PERIPH_USBDEV_HS` is introduced.
### Testing procedure
Use `tests/usbus_cdc_ecm` and any board with USB HS connector, for example:
```
USEMODULE=periph_usbdev_hs_utmi BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
```
`ping` command works with this PR but doesn't work without this PR.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19242: usbus/msc: add initial Mass Storage Class support r=benpicco a=dylad
### Contribution description
This PR adds the initial support for Mass Storage Class in USBUS. This PR relies on the RIOT MTD implementation to implement the Mass Storage Class support. With the provided test application, a MTD device will be accessible as a normal storage device on your host computer.
Read and Write operations are allowed.
Multiple LUNs are supported so several MTD devices can be exported through USB.
The MSC relies on SCSI protocol to operate.
Currently there are some limitations:
Supported host : Linux & Windows (macOS is untested)
MSC cannot be used if MTD page size > 4096
MTD device must have at least 512 bytes of memory to be exported.
Please be aware that performance are not so great.
### Testing procedure
Flash `tests/usbus_msc` application on a board with at least one MTD device.
Once the shell has started, prepare one or several MTD devices to be exported using `add_lun` command.
Once ready, start the USB connection with `usb_attach`
All MTD exported should appear as` /dev/sdX` on Linux.
### Issues/PRs references
Supersede #15941
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19331: pkg/tinydtls: Adjust defaults r=miri64 a=chrysn
### Contribution description
This adjusts two defaults in tinydtls:
* Default verbosity is set to warning. At the info level, this module produces way more output (several lines per new connection, and even per message) than is common in RIOT.
* If gcoap is used, the buffer size is adjusted to the gcoap buffer size plus overhead. Otherwise, CoAP-over-DTLS works fine until one happens to request larger resources.
### Testing procedure
* Run examples/gcoap_dtls
* Send a CoAP request from outside, eg. with `aiocoap-client 'coaps://[fe80::3c63:beff:fe85:ca96%tapbr0]/.well-known/core' --credentials testserver.json` (where testserver.json is `{"coaps://[fe80::3c63:beff:fe85:ca96%tapbr0]/*": {"dtls": {"psk": {"ascii": "secretPSK"}, "client-identity": {"ascii": "Client_identity"}}}}`).
Before, there are messages shown for every request; now there are none.
Modify `examples/gcoap/server.c` as follows:
```patch
diff --git a/examples/gcoap/server.c b/examples/gcoap/server.c
index bf2315cd01..28e1faac27 100644
--- a/examples/gcoap/server.c
+++ b/examples/gcoap/server.c
`@@` -68,7 +68,7 `@@` static const coap_resource_t _resources[] = {
};
static const char *_link_params[] = {
- ";ct=0;rt=\"count\";obs",
+ ";ct=0;rt=\"count\";obs;looooooooooooooooooooooong-attribute=\"loooooooooooooooooooooooooooooong\"",
NULL
};
```
The request passes; without this patch, it is stuck in retransmissions until "Network error: Retransmissions exceeded".
### Issues/PRs references
This contributes to making #19289 usable with a minimum level of security. (That module fills up the gcoap buffer to the brim). While the module handles the verbosity as well as it can (occasionally admitting that it lost bytes of output), the previous verbosity produces an infinite stream of stdout data. (But the default should be quiet immaterial of that particular PR).
Co-authored-by: chrysn <chrysn@fsfe.org>
