19415: cpu/esp32: fix stdio_usb_serial_jtag for ESP32-C3 r=benpicco a=gschorcht
### Contribution description
This PR fixes problem with `stdio_usb_serial_jtag` for ESP32-C3.
### Testing procedure
Flash any ESP32-C3 board with the USB interface connected USB D+/D- (GPIO19, GPIO18) using the `stdio_usb_serial_jtag` module:
```
USEMODULE=stdio_usb_serial_jtag BOARD=hip-badge make -j8 -C tests/shell flash term
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19414: drivers/at: fixed faulty event prio name r=benpicco a=viktorbatista
Fixed a small oversight if using the at_urc_isr_highest pseudomodule.
### Contribution description
Basically just fixes an oversight in the at driver where it was checking if the at_urc_isr_high module was defined, which doesn't exist - it should have been at_urc_isr_highest.
Just below that line it then defines AT_EVENT_PRIO as EVENT_PRIO_HIGH which also should have been EVENT_PRIO_HIGHEST.
### Testing procedure
Just include the at_urc_isr_highest module anywhere in a build and notice how it no longer outputs an error ;)
### Issues/PRs references
-
Co-authored-by: Vitor Batista <vitor.batista@ml-pa.com>
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 a custom expect() that just spins in an endless loop instead of
panicking. The test isn't run automatically anyway, as it requires
connecting two GPIOs with jumper wires; but when run manually it is
helpful to not kill RIOT to also get the stdio output of the exact
point where the test fails (e.g. USB CDC ACM doesn't like panic()).
19410: boards/common/gd32v: improve openocd config r=benpicco a=gschorcht
### Contribution description
This PR improves the OpenOCD config for GD32V.
To restart GD32V after flashing, a special magic procedure has to be used. For short:
```python
halt
gd32vf103.cpu mww 0xe004200c 0x4b5a6978 # unlock 0xe0042008, the next write triggers a reset
riscv set_mem_access abstract # set abstract memory access
gd32vf103.cpu mww 0xe0042008 0x1 # write to 0xe0042008 to triggers a reset
riscv set_mem_access progbuf # set memory access mode back
resume
```
The final `resume` was missing so that a timeout with an error message happened after flashing, for example:
```python
wrote 14692 bytes from file tests/shell/bin/sipeed-longan-nano/tests_shell.elf in 1.845550s (7.774 KiB/s)
verified 14692 bytes in 0.071006s (202.063 KiB/s)
Info : JTAG tap: gd32vf103.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing) Inc), part: 0x9000, ver: 0x7)
Error: Timed out after 2s waiting for busy to go low (abstractcs=0x2001004). Increase the timeout with riscv set_command_timeout_sec.
Warn : Failed to write memory via abstract access.
Error: Target gd32vf103.cpu: Failed to write memory (addr=0xe0042008)
Error: progbuf=disabled, sysbus=disabled, abstract=failed
Error executing event reset-assert on target gd32vf103.cpu:
embedded:startup.tcl:1187: Error:
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 1187
shutdown command invoked
Done flashing
```
With the final `resume`, still an error message happens that hart 0 is unavialable, but the timeout with all these errors do not occur and OpenOCD exits immediatly:
```python
wrote 14732 bytes from file /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/tests/shell/bin/sipeed-longan-nano/tests_shell.elf in 1.516376s (9.488 KiB/s)
verified 14732 bytes in 0.045381s (317.021 KiB/s)
Info : JTAG tap: gd32vf103.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing) Inc), part: 0x9000, ver: 0x7)
Error: Hart 0 is unavailable.
Info : Hart 0 unexpectedly reset!
shutdown command invoked
Done flashing
```
### Testing procedure
Flash any GD32V board with and without this PR and observe the output.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19408: boards/esp32: enable RGB LED support r=benpicco a=gschorcht
### Contribution description
A couple of ESP32x boards have a SK68XXMINI-HS RGB LED on board.
- `esp32c3-devkit`
- `esp32s2-devkit`
- `esp32s3-devkit`
This RGB LED can be used with the driver module `ws2812x`. This PR adds the `WS2812X_PARAMS*` parameter definitions to the board definition and updates the documentation.
### Testing procedure
Use any of these boards to flash `tests/driver_ws2812x`, for example:
```
BOARD=esp32c3-devkit make -j8 -C tests/driver_ws281x/ flash
```
The RGB LED should work as expected.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19409: dist/tools/openocd: fix problems with riotboot caused by _flash_addr function for OpenOCD v0.12 r=maribu a=gschorcht
### Contribution description
This PR fixes the problem that OpenOCD v0.12 can't be used to flash application images for `riotboot`. Found when using OpenOCD v0.12 for GD32V and `riotboot`.
If `riotboot` is used, application images including their riotboot headers are flashed as binaries where the flash address has to be sepcified in `openocd` command. To determine the flash address, OpenOCD command `flash list` is used which returns a list of flash banks. With OpenOCD version v0.12, the format of the command output has been changed.
Until version OpenOCD version v0.11, command `flash list` returned something like (**without newlines**):
```
{name nrf51 base 0 size 0 bus_width 1 chip_width 1}
{name nrf51 base 268439552 size 0 bus_width 1 chip_width 1}
```
It was hard-coded in function `_flash_addr` to extract the 4th column of the according line instead of using the keyword `base`.
With OpenOCD version v0.12, the output format of the `flash list` command has been changed to:
```
{name nrf51.flash driver nrf51 base 0 size 0 bus_width 1 chip_width 1 target nrf51.cpu}
{name nrf51.uicr driver nrf51 base 268439552 size 0 bus_width 1 chip_width 1 target nrf51.cpu}
```
That is, with the hard-coded 4th column, function `_flash_addr` always returns `0x00000000` which doesn't matter for platforms that define `0x0` as base address but using `riotboot` on platforms that define a base address other than `0x0` no longer works.
For example, using `riotboot` on a `nucleo-f303ze` with OpenOCD v0.11 works as expected
```python
FEATURES_REQUIRED=riotboot BOARD=nucleo-f303ze make -j8 -C tests/shell flash
...
openocd.sh flashtests/shell/bin/nucleo-f303ze/riotboot_files/slot0-extended.bin
### Flashing Target ###
Binfile detected, adding ROM base address: 0x08000000
Flashing with IMAGE_OFFSET: 0x08000000
...
Info : flash size = 512kbytes
auto erase enabled
wrote 266240 bytes from file /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/tests/shell/bin/nucleo-f303ze/riotboot_files/slot0-extended.bin in 11.100125s (23.423 KiB/s)
verified 265216 bytes in 3.802232s (68.118 KiB/s)
```
but fails when using OpenOCD v0.12 due to wrong image offset:
```python
openocd.sh flash tests/shell/bin/nucleo-f303ze/riotboot_files/slot0-extended.bin
### Flashing Target ###
Binfile detected, adding ROM base address: 0x00000000
Flashing with IMAGE_OFFSET: 0x00000000
...
Info : flash size = 512kbytes
Warn : no flash bank found for address 0x00000000
auto erase enabled
wrote 0 bytes from file tests/shell/bin/nucleo-f303ze/riotboot_files/slot0-extended.bin in 0.001248s (0.000 KiB/s)
Error: checksum mismatch - attempting binary compare
diff 0 address 0x00001004. Was 0xb9 instead of 0x49
diff 1 address 0x00001005. Was 0xf8 instead of 0xf9
```
This PR modifies the `_flash_address` function to use the base keyword to extract the flash address to use.
### Testing procedure
Use a board which provides the `riotboot` feature but for which `riotboot` doesn't work any longer, for example `nucleo-f303ze`:
```
FEATURES_PROVIDED=riotboot FEATURES_REQUIRED=riotboot BOARD=nucleo-f303ze make -j8 -C tests/shell flash
```
Principally, also boards that don't yet provide the `riotboot` feature but work for testing, for example:
```
FEATURES_PROVIDED=riotboot FEATURES_REQUIRED=riotboot BOARD=nucleo-f103rb make -j8 -C tests/shell flash
FEATURES_PROVIDED=riotboot FEATURES_REQUIRED=riotboot BOARD=nucleo-f411re make -j8 -C tests/shell flash
```
Without the PR, flashing `tests/shell/bin/nucleo-f103rb/riotboot_files/slot0-extended.bin` fails, with the PR it should work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19406: boards/nucleo64: Add pinout diagrams from UM1724 r=maribu a=maribu
### Contribution description
ST's UM1724 user manual provides pinout diagrams for many Nucleo-64 boards. This adds them to the doc for easy of use.
### Testing procedure
The generated doc should contain pinout diagrams for most of the Nucleo-64 boards now.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19402: sys/net/gnrc/netif: fixing no global address wait r=benpicco a=jan-mo
### Contribution description
The function `gnrc_netif_ipv6_wait_global_address()` will always return true, even if no global address is attached to the interface.
Currently the function only waits for any message and does not check if it was from the bus or not. So in `msg.content.ptr` is no valid address and therefore it returns true.
I added just the check, if the message is from the bus of any interface and then checking the address. We could also first check if the address in `msg.content.ptr` is valid, but this will just hide the bug. Also the timeout was never checked. It was just assuming that no other message will be received during the wait.
### Testing procedure
Use two devices, one works as a border router and supports the global address, the other will wait for the global address. You can call the function `gnrc_netif_ipv6_wait_global_address()` on the waiting node and see whether it returns true and finds the global address in the given time-range.
19404: sys/trickle: cleanup deps r=benpicco a=MrKevinWeiss
### Contribution description
Cleans the dependencies of the `trickle` module. This removes the deprecated xtimer and models kconfig.
### Testing procedure
Green murdock
### Issues/PRs references
19405: cpu/efm32: pwm_init errors are zeros r=benpicco a=chrysn
### Contribution description
pwm_init is documented to return 0 on errors, and has an unsigned return value.
EFM32's initialization function returned negative values, which through implicit casting become 0xffffffff or 0xfffffffe, which are successful by the documentation.
This makes all the EFM32 error paths return 0 as they should.
Also, it fixes a variable name and the corresponding error message that used to talk of "initiation" (which would be the start of a process) rather than "initialization" (which is a process that is completed before something else can happen).
### Testing procedure
* on stk3700, tests/periph_pwm, run `init 0 0 10 1000` / `set 0 0 500`
* The init used to respond with "The pwm frequency is set to 4294967294", and the set does nothing.
* The init now responds with "Error: device is not <del>initiated</del><ins>initialized</ins>". The set still does nothing, but then one doesn't expect it to any more.
(But really, looking at the patch and the docs should suffice).
### Issues/PRs references
By-catch from testing the Rust wrappers provided by `@remmirad` at https://github.com/RIOT-OS/rust-riot-wrappers/pull/38
Co-authored-by: Jan Mohr <jan.mohr@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: chrysn <chrysn@fsfe.org>
19357: boards/adafruit-itsybitsy-m4: turn off APA102 LED on startup r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
19381: cpu/esp_common: Add missing disconnect reasons r=gschorcht a=Flole998
### Contribution description
There have been new disconnect reasons added in recent SDK revisions. Currently they cause a crash due to invalid memory access. This PR fixes those and also accounts for future extensions of the list by providing an easy way of adding new codes/gaps aswell as returning "UNKNOWN" for not yet known reasons to prevent crashes.
### Testing procedure
The new function has been tested by iterating over all possible 255 return codes. Also it has been verified that an ESP that previously crashed after being disconnected from a WPA2 Enterprise secured network no longer crashes.
Co-authored-by: Florian Lentz <flolen@uni-bremen.de>
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>
Since the stm32f429i-disco uses the USB OTG HS instead of USB OTG FS peripheral, the number of available EPs is sufficient for this application. With the change of defining the largest number of available EPs for USBUS instead of the smallest number, the board can use all EPs of the USB OTG HS peripheral.
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.
19394: tests/rmutex: Drop output dump from README.md r=maribu a=maribu
### Contribution description
We use test scripts to automatically classify the output of a test application as passing / failing. Users are not expected to manually compare the output with a dump of the output in a readme.
### Testing procedure
Doesn't apply
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/19140
Fixes https://github.com/RIOT-OS/RIOT/issues/19298
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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>
19388: drivers/usbdev_synopsys_dwc2: disable DMA mode r=gschorcht a=gschorcht
### Contribution description
This PR disables the DMA mode for HS cores due to several problems found:
- The STALL bit of the OUT control endpoint does not seem to be cleared automatically on the next SETUP received. At least the USB OTG HS core does not generate an interrupt on the next SETUP received. This happens, for example, when CDC ACM is used and the host sends the `SET_LINE_CODING` request which is answered with setting the STALL bit of the OUT endpoint. In this case the enumeration of further interfaces, for example CDC ECM, is stopped. This problem was described in https://github.com/RIOT-OS/RIOT/pull/17085#issuecomment-1464928744
- The Enumeration fails for CDC ECM interface which uses URB support (PR #17091)
### Testing procedure
Use a STM32 board with USH OTG HS interface:
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash
```
Without this PR, either the enumeration completely fails (mostly for `stm32f723e-disco`)
```python
[377629.753895] usb 1-2.3: new high-speed USB device number 76 using xhci_hcd
[377629.854349] usb 1-2.3: device descriptor read/all, error -71
[377629.937990] usb 1-2.3: new high-speed USB device number 77 using xhci_hcd
[377630.038261] usb 1-2.3: device descriptor read/all, error -71
[377630.038711] usb 1-2-port3: attempt power cycle
[377630.641970] usb 1-2.3: new high-speed USB device number 78 using xhci_hcd
[377630.666066] usb 1-2.3: device descriptor read/8, error -71
[377630.794076] usb 1-2.3: device descriptor read/8, error -71
[377630.981806] usb 1-2.3: new high-speed USB device number 79 using xhci_hcd
[377631.002092] usb 1-2.3: device descriptor read/8, error -71
[377631.130091] usb 1-2.3: device descriptor read/8, error -71
[377631.238344] usb 1-2-port3: unable to enumerate USB device
```
or the enumeration of the CDC ECM interface stops with error.
```python
[377972.828168] usb 1-2.3: new high-speed USB device number 100 using xhci_hcd
[377972.928762] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[377972.928765] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[377972.928767] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[377972.929225] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[377972.929228] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[377972.929230] usb 1-2.3: Product: stm32f723e-disco
[377972.929232] usb 1-2.3: Manufacturer: RIOT-os.org
[377972.929233] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B
[377972.932399] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device
[377972.933905] cdc_ether: probe of 1-2.3:1.2 failed with error -32
[377973.184377] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
```
With this PR the enumeration should work as it should:
```python
[378480.097974] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[378484.289762] usb 1-2.3: new high-speed USB device number 16 using xhci_hcd
[378484.394638] usb 1-2.3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[378484.394642] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[378484.394644] usb 1-2.3: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[378484.395296] usb 1-2.3: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[378484.395299] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[378484.395301] usb 1-2.3: Product: stm32f723e-disco
[378484.395303] usb 1-2.3: Manufacturer: RIOT-os.org
[378484.395304] usb 1-2.3: SerialNumber: A6BAC4E1B1E0806B
[378484.398547] cdc_acm 1-2.3:1.0: ttyACM1: USB ACM device
[378484.401007] cdc_ether 1-2.3:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.3, CDC Ethernet Device, e6:75:97:3a:74:ba
[378484.449870] cdc_ether 1-2.3:1.2 enp0s20f0u2u3i2: renamed from usb0
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
