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>
19390: doxygen: Point to contributing.md document r=kaspar030 a=bergzand
### Contribution description
Shortcuts a referral on the wiki
### Testing procedure
Check the url in the doxygen main page
### Issues/PRs references
None
19391: cord: convert to ztimer r=kaspar030 a=bergzand
### Contribution description
As the subject describes
### Testing procedure
The `examples/cord_ep` example should work as before.
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
DMA mode is disabled for now due to several problems:
- 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. In this case the enumeration of further interfaces, for example CDC ECM is stopped.
- The Enumeration fails for CDC ECM interface which uses URB support.
19386: usbus/dfu: do not create alt interface if NUM_SLOTS=1 r=benpicco a=dylad
### Contribution description
In some cases, it is really useful to build `riotboot` with `NUM_SLOTS=1`.
When use in combination with `riotboot_dfu`, there is no need to export the second slot if `riotboot` is built with `NUM_SLOTS=1`.
Thus, prevent the alt interface declaration in dfu if `NUM_SLOTS=1` so that only slot0 can be used to flash.
### Testing procedure
Add `NUM_SLOTS=1` to `bootloaders/riotboot_dfu/Makefile`
Flash the riotboot DFU bootloader to any board supported by USBUS:
`make BOARD=xxx -C bootloaders/riotboot_dfu flash`
and run
`dfu-util -l`
With NUM_SLOTS=2 you will get:
```
dfu-util -l
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [1209:7d02] ver=0100, devnum=11, cfg=1, intf=0, path="1-4", alt=1, name="RIOT-OS Slot 1", serial="AB88DCAE80893484"
Found DFU: [1209:7d02] ver=0100, devnum=11, cfg=1, intf=0, path="1-4", alt=0, name="RIOT-OS Slot 0", serial="AB88DCAE80893484"
```
with NUM_SLOTS=1 you will get:
```
dfu-util -l
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-4", alt=0, name="RIOT-OS Slot 0", serial="AB88DCAE80893484"
```
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
If riotboot is built with NUM_SLOTS=1, there is no reason to advertise a second slot in the bootloader
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19383: cord: include gcoap_req_send returning 0 in error r=benpicco a=bergzand
### Contribution description
gcoap_req_send returns 0 if it was unable to send the CoAP request. CoRD did not include that case in the return code checks. This changes CoRD to include it and drop the registration if CoAP could not send the request. The old behaviour made the CoRD thread lock up.
### Testing procedure
- Check with the gcoap API docs.
- I can reliable trigger the issue with a RIOT application including both the `cord_ep_standalone` module and some measurement reported both sending requests to the same application. If at some point the application is shut down, gcoap has all its memo's occupied with the measurement reporting and can't add the CoRD update request. Thus the CoRD update request fails with a zero code and the thread (previously) would lock up.
### Issues/PRs references
None
19385: cpu/stm32/periph/timer: fix clobered IRQ flag r=benpicco a=Enoch247
### Contribution description
From the git commit:
> 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.
I had trouble finding anything in ST's datasheet saying that software could not set the timer's status flags, but testing showed that this is how it works in practice. Further, [ST's own HAL ](https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_tim.h#L1258)confirms this. If the hardware didn't work this way, it would be impossible to atomically read-modify-write the flags.
### 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: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
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.
19384: sam0/usbdev: partial revert of #17086 r=gschorcht a=dylad
### Contribution description
Reverting theses changes from #17086 because it breaks SAM0 `usbdev` in master.
The idea was to following the USB spec but for not obvious reason yet, it doesn't work as intended.
So revert these changes so `usbdev` works again on master.
We will try to figured out what's wrong later.
### Testing procedure
Test any `usbus` related test application w/ a SAM0-based board.
### Issues/PRs references
See discussion in #17086
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
