19437: boards: fix USB configuration for stm32f429i-disco r=bergzand a=gschorcht
### Contribution description
This PR fixes the problem that CDC ECM is not working for `stm32f429i-disco`.
With PR #19358, the EP data size for CDC ECM bulk endpoints was increased to 512 byte to fix the problem that CDC ECM was not working for boards with USB High-Speed peripherals. Module `periph_usbdev_hs` was introduced to indicate whether a high-speed peripheral is used.
However, the `stm32f429i-disco` board uses a mixture of USB OTG HS peripheral together with the on-hip FS PHY. Using the USB OTG HS peripheral together with a FS-PHY and increasing the EP data size for the CDC ECM bulk endpoint to 512 bytes doesn't work. Therefore, module `periph_usbdev_hs` is not used for now to workaround the problem. Thus, the maximum number of EPs used is that of the USB OTG FS peripheral, which is only 4. This is not sufficient for this test application since the board uses `stdio_cdc_acm`. The board is therefore blacklisted.
### Testing procedure
Use a `stm32f429i-disc1` or a `stm32f429i-disco` board and flash the test app:
```
USEMODULE=stdio_uart BOARD=stm32f429i-disco make -j8 -C tests/usbus_cdc_ecm flash
```
With this PR it should be possible to ping the board.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The board no longer uses the `periph_usbdev_hs` module. Therefore, the maximum number of EPs used is that of the USB OTG FS peripheral, which is only 4. This is not sufficient for this test application since the board uses `stdio_cdc_acm`.
The board uses the USB OTG HS peripheral together with the on-hip FS PHY. Using the `periph_usbdev_hs` module increases the EP data size for the CDC ECM bulk endpoint to 512 bytes, which does not work for the FS interface. Module `periph_usbdev_hs` is therefore not used.
19417: boards/esp32c3-wemos-mini: add support for Wemos ESP32-C3 mini r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [Wemos ESP32-C3 mini](https://www.wemos.cc/en/latest/c3/c3_mini.html) board.
### Testing procedure
The board should work for provided features.
The board was already tested with:
- [x] `tests/driver_sht3x` using I2C
- [x] `tests/driver_l3gxxxx` using SPI
- [x] `tests/periph_adc`
- [x] `tests/periph_pwm`
- [ ] `tests/driver_ws281x`
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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 moves the header files from `boards/common/esp32s3/include` that can be used for all types of ESP32x SoCs to a new common ESP32x board module.
19424: drivers/ws281x: add RMT hardware support for ESP32x SoCs r=maribu a=gschorcht
### Contribution description
This PR provides support for ESP32x RMT that is used to generate WS2812B signals.
All ESP32x SoCs have a [Remote Control Peripheral (RMT)](https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32/api-reference/peripherals/rmt.html) that can be used to generate digital waveforms, such as NEC remote control signals or WS2812B RGB LED signals. Each RMT peripheral has either 4 or 8 channels. Some ESP32x SoCs support configuring the clock sources used for each channel separately, while other ESP32x SoCs can only use a single clock source for all channels.
The advantages using the RMT are that the CPU is not busy when generating the WS218x signal and the phase times are accurate to nanoseconds. The disadvantage is that the configuration of the RMT is so complex due to its flexibility that the [ESP-IDF high-level driver for RMT](https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32c3/api-reference/peripherals/rmt.html) is used.This requires about 6 kBytes more ROM, about 3 kBytes more IRAM, and 88 bytes more RAM.
Therefore, either the RMT hardware implementation (module `ws2812x_esp32_hw`) as well as the bit-banging software implementation (module `ws2812x_esp32_hw`) can be used. RMT hardware implementation (module `ws2812x_esp32_hw`) is used by default.
Timing with hardware implementation:
### Testing procedure
`tests/driver_ws281x` should still work, for example:
```
CFLAGS='-DWS281X_PARAM_PIN=GPIO45 -DWS281X_PARAM_NUMOF=47' BOARD=esp32s3-devkit make -j8 -C tests/driver_ws281x flash
```
Test Output:
https://user-images.githubusercontent.com/31932013/227791753-e6d2924e-3364-4387-870f-a56d3a9a8a80.mp4
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19425: drivers/servo: Fix typo in comment r=benpicco a=maribu
### Contribution description
As the title says
### Testing procedure
Not needed; code review will confirm that this is a comment only change.
### Issues/PRs references
None
19426: cpu/esp32: cleanup of ESP-IDF interface API (module `esp_idf_api`) r=benpicco a=gschorcht
### Contribution description
This PR cleans up the wrapper library (module `esp_idf_api`) that is used to interface to ESP-IDF driver modules.
A number of ESP-IDF header files needed to compile RIOT include the ESP-IDF header file `driver/gpio.h` only because of the definition of the type `gpio_num_t`. However, `driver/gpio.h` does not only define `gpio_num_t` but the complete ESP-IDF GPIO API which conflicts with that in RIOT. The solution was to use a wrapper library when compiling the RIOT code that does not need to include the ESP-IDF header file `driver/gpio.h`. The disadvantage of this approach was that for each ESP-IDF function to be used in RIOT, a corresponding function in the wrapper library had to be defined which does nothing else than calling the corresponding ESP-IDF function.
This PR provides another approach which does not require such a wrapper library in most cases and allows to clean up the wrapper library (module `esp_idf_api`). It just provides its own `driver/gpio.h` that is included by ESP-IDF header files instead of the original ESP-IDF header file `driver/gpio.h`. It defines only the required `gpio_num_t` when RIOT code is compiled but includes the original ESP-IDF header file `driver/gpio.h` when ESP-IDF code is compiled. As a result. most of the functions in the wrapper library could be eliminated. A further advantage is that further ESP-IDF API functions can be used without defining corresponding wrapper functions.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19369: sys/cpp11-compat: Remove xtimer deps r=MrKevinWeiss a=MrKevinWeiss
### Contribution description
This replaces the `xtimer` calls with explicit `ztimer64` calls, since `xtimer` is somewhat deprecated.
### Testing procedure
- Green murdock
- I suppose the following `tests/`
```
c11_atomics_cpp_compat
cpp11_condition_variable
cpp11_mutex
cpp11_thread
cpp_ctors
cpp_exclude
cpp_ext
irq_cpp
rmutex_cp
```
- run `compile_and_test_for_board.py` and `compile_like_murdock.py` for the subset of tests.
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19370: Fix `compile_like_murdock.py` when board is empty r=MrKevinWeiss a=MrKevinWeiss
### Contribution description
Turns out we didn't test the simplest case, board being empty.
I added some automatic testing to check that and we can build when needed...
### Testing procedure
Green `tools-test` action
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
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.
19422: drivers/ws281x: improve timing for ESP32x r=maribu a=gschorcht
### Contribution description
This PR provides a small change which improves the timing for ESP32x SoCs.
If overhead like the loop control or the calculation of the waiting times for the next bit are performed while waiting for the end of the LOW phase, the time required for such operations is included in the LOW phase. This makes both the LOW phase and the period more precise.
According to the definitions
```c
#define WS281X_T_DATA_NS (1250U)
#define WS281X_T_DATA_ONE_NS (650U)
#define WS281X_T_DATA_ZERO_NS (325U)
```
the following timing is used:
| Parameter | Value | Master | this PR |
|:-------------|------:|-------:|--------:|
| 1-Bit Period | 1250 | 1820 | 1400 |
| 1-Bit HIGH | 650 | 690 | 710 |
| 1-Bit LOW | 600 | 1130 | 690 |
| | | | |
| 0-Bit Period | 1250 | 1880 | 1400 |
| 0-Bit HIGH | 350 | 380 | 400 |
| 0-Bit LOW | 900 | 1500 | 1000 |
Timing with current master:
Timing with this PR:
### Testing procedure
`tests/driver_ws281x` should still work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
If overhead like the loop control or the calculation of the waiting times for the next bit are performed while waiting for the end of the LOW phase, the time required for such operations is included in the LOW phase. This makes both the LOW phase and the period more precise.
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.
19412: cpu/stm32/periph: Add GPIO LL IRQ support for STM32F1 r=gschorcht a=maribu
### Contribution description
As the title says
### Testing procedure
<details><summary><code>make BOARD=nucleo-f103rb flash test-with-config -C tests/periph_gpio_ll</code></summary>
```
make: Entering directory '/home/maribu/Repos/software/RIOT/tests/periph_gpio_ll'
Building application "tests_periph_gpio_ll" for "nucleo-f103rb" with MCU "stm32".
"make" -C /home/maribu/Repos/software/RIOT/boards/common/init
"make" -C /home/maribu/Repos/software/RIOT/boards/nucleo-f103rb
"make" -C /home/maribu/Repos/software/RIOT/boards/common/nucleo
"make" -C /home/maribu/Repos/software/RIOT/core
"make" -C /home/maribu/Repos/software/RIOT/core/lib
"make" -C /home/maribu/Repos/software/RIOT/cpu/stm32
"make" -C /home/maribu/Repos/software/RIOT/cpu/cortexm_common
"make" -C /home/maribu/Repos/software/RIOT/cpu/cortexm_common/periph
"make" -C /home/maribu/Repos/software/RIOT/cpu/stm32/periph
"make" -C /home/maribu/Repos/software/RIOT/cpu/stm32/stmclk
"make" -C /home/maribu/Repos/software/RIOT/cpu/stm32/vectors
"make" -C /home/maribu/Repos/software/RIOT/drivers
"make" -C /home/maribu/Repos/software/RIOT/drivers/periph_common
"make" -C /home/maribu/Repos/software/RIOT/sys
"make" -C /home/maribu/Repos/software/RIOT/sys/auto_init
"make" -C /home/maribu/Repos/software/RIOT/sys/div
"make" -C /home/maribu/Repos/software/RIOT/sys/frac
"make" -C /home/maribu/Repos/software/RIOT/sys/isrpipe
"make" -C /home/maribu/Repos/software/RIOT/sys/libc
"make" -C /home/maribu/Repos/software/RIOT/sys/malloc_thread_safe
"make" -C /home/maribu/Repos/software/RIOT/sys/newlib_syscalls_default
"make" -C /home/maribu/Repos/software/RIOT/sys/pm_layered
"make" -C /home/maribu/Repos/software/RIOT/sys/preprocessor
"make" -C /home/maribu/Repos/software/RIOT/sys/stdio_uart
"make" -C /home/maribu/Repos/software/RIOT/sys/test_utils/interactive_sync
"make" -C /home/maribu/Repos/software/RIOT/sys/test_utils/print_stack_usage
"make" -C /home/maribu/Repos/software/RIOT/sys/tsrb
"make" -C /home/maribu/Repos/software/RIOT/sys/ztimer
text data bss dec hex filename
20760 176 2728 23664 5c70 /home/maribu/Repos/software/RIOT/tests/periph_gpio_ll/bin/nucleo-f103rb/tests_periph_gpio_ll.elf
/home/maribu/Repos/software/RIOT/dist/tools/openocd/openocd.sh flash /home/maribu/Repos/software/RIOT/tests/periph_gpio_ll/bin/nucleo-f103rb/tests_periph_gpio_ll.elf
### Flashing Target ###
Open On-Chip Debugger 0.12.0+dev-snapshot (2023-03-13-08:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter serial' not 'hla_serial'
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : clock speed 1000 kHz
Info : STLINK V2J29M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.252984
Info : [stm32f1x.cpu] Cortex-M3 r1p1 processor detected
Info : [stm32f1x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 0
Info : Listening on port 32843 for gdb connections
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f1x.cpu hla_target little stm32f1x.cpu unknown
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001ae4 msp: 0x20000200
Info : device id = 0x20036410
Info : flash size = 128 KiB
Warn : Adding extra erase range, 0x080051c8 .. 0x080053ff
auto erase enabled
wrote 20936 bytes from file /home/maribu/Repos/software/RIOT/tests/periph_gpio_ll/bin/nucleo-f103rb/tests_periph_gpio_ll.elf in 1.192543s (17.144 KiB/s)
verified 20936 bytes in 0.333379s (61.328 KiB/s)
shutdown command invoked
Done flashing
r
/home/maribu/Repos/software/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM1" -b "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
Connect to serial port /dev/ttyACM1
Welcome to pyterm!
Type '/exit' to exit.
READY
s
START
main(): This is RIOT! (Version: 2023.04-devel-685-gd0d5d-cpu/stm32/periph/gpio_ll_irq)
Test / Hardware Details:
========================
Cabling:
(INPUT -- OUTPUT)
P2.10 (PC10) -- P1.8 (PB8)
P2.12 (PC12) -- P1.9 (PB9)
Number of pull resistor values supported: 1
Number of drive strengths supported: 1
Number of slew rates supported: 4
Valid GPIO ports:
- PORT 0 (PORT A)
- PORT 1 (PORT B)
- PORT 2 (PORT C)
- PORT 3 (PORT D)
- PORT 4 (PORT E)
Testing gpio_port_pack_addr()
=============================
All OK
Testing gpip_ng_init()
======================
Testing is_gpio_port_num_valid() is true for PORT_OUT and PORT_IN:
Testing input configurations for PIN_IN_0:
Support for input with pull up: yes
state: in, pull: up, schmitt trigger: off, value: on
Support for input with pull down: yes
state: in, pull: down, schmitt trigger: off, value: off
Support for input with pull to bus level: no
Support for floating input (no pull resistors): yes
state: in, pull: none, schmitt trigger: off, value: off
Testing output configurations for PIN_OUT_0:
Support for output (push-pull) with initial value of LOW: yes
state: out-pp, slew: slowest, value: off
Output is indeed LOW: yes
state: out-pp, slew: slowest, value: on
Output can be pushed HIGH: yes
Support for output (push-pull) with initial value of HIGH: yes
state: out-pp, slew: slowest, value: on
Output is indeed HIGH: yes
Support for output (open drain with pull up) with initial value of LOW: no
Support for output (open drain with pull up) with initial value of HIGH: no
Support for output (open drain) with initial value of LOW: yes
state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: off
Output is indeed LOW: yes
Support for output (open drain) with initial value of HIGH: yes
state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: on
state: in, pull: down, schmitt trigger: off, value: off
Output can indeed be pulled LOW: yes
state: in, pull: up, schmitt trigger: off, value: on
Output can indeed be pulled HIGH: yes
Support for output (open source) with initial value of LOW: no
Support for output (open source) with initial value of HIGH: no
Support for output (open source with pull up) with initial value of HIGH: no
Support for output (open source with pull up) with initial value of LOW: no
Support for disconnecting GPIO: yes
Output can indeed be pulled LOW: yes
Output can indeed be pulled HIGH: yes
Testing Reading/Writing GPIO Ports
==================================
testing initial value of 0 after init
...OK
testing setting both outputs_optional simultaneously
...OK
testing clearing both outputs_optional simultaneously
...OK
testing toggling first output (0 --> 1)
...OK
testing toggling first output (1 --> 0)
...OK
testing toggling second output (0 --> 1)
...OK
testing toggling second output (1 --> 0)
...OK
testing setting first output and clearing second with write
...OK
testing setting second output and clearing first with write
...OK
All input/output operations worked as expected
Testing External IRQs
=====================
Testing rising edge on PIN_IN_0
... OK
Testing falling edge on PIN_IN_0
... OK
Testing both edges on PIN_IN_0
... OK
Testing masking of IRQs (still both edges on PIN_IN_0)
... OK
Testing level-triggered on HIGH on PIN_IN_0 (when input is LOW when setting up IRQ)
... OK
Testing level-triggered on HIGH on PIN_IN_0 (when input is HIGH when setting up IRQ)
... OK
Testing level-triggered on LOW on PIN_IN_0 (when input is HIGH when setting up IRQ)
... OK
Testing level-triggered on LOW on PIN_IN_0 (when input is LOW when setting up IRQ)
... OK
TEST SUCCEEDED
```
</details>
### Issues/PRs references
Depends on https://github.com/RIOT-OS/RIOT/pull/19407
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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>
