To be able to reconfigure the PLL multiplier in clock configuration, the existing value has to be reset first. This becomes necessary when changing the core clock, e.g. when booting with riotboot an application that uses USB.
To allow CPU specific definitions in `cpu.h`, `riscv_common/cpu.h` is renamed to ``riscv_common/cpu_common.h` and included in new `cpu.h` files for FE310 and GD32V.
19450: cpu/esp32: fix compilation issues with GCC 12.2 r=benpicco a=gschorcht
### Contribution description
This PR provides the changes in `cpu/esp32` and `cpu/esp_common` to fix the compilation issues with GCC v12.2. It is required as the first step in the preparation of the upgrade to ESP-IDF version 5.1.
**Please note**: Insead of fixing the ESP-IDF 4.4 code itself by a big bunch of patches to fix the compilation problems with GCC v12.2, it temporarily disables some warnings. The reason is that the ESP-IDF 5.1 requires GCC v12.2 and should be fixed for this compiler version by the vendor.
### Testing procedure
Green CI
The change were already tested with all ESP-specific modules like `esp_now`, `esp_wifi`, `esp_spi` and `esp_ble` for all supported ESP platforms.
### Issues/PRs references
Prerequisite for https://github.com/RIOT-OS/riotdocker/pull/227
Fixes issue #19421
19476: native/syscalls: rename real_clock_gettime to clock_gettime r=benpicco a=Teufelchen1
### Contribution description
When compiling RIOT for native using a recent LLVM and enabling ASAN, one might encounter "Duplicated symbol".
This is due to a name clash with `real_clock_gettime()` in compiler-rt from [LLVM](f50246da65), I renamed RIOTs `real_clock_gettime` and just default to the posix function `clock_gettime`. The wrapper existed, most likely, for consistency only.
(The best solution would probably to convince the LLVM folks to declare their symbol as `static` and refactor a bit)
### Testing procedure
Passing CI should be enough.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
19460: cpu/stm32/usbdev_fs: fix ep registration and EP_REG assignments r=gschorcht a=dylad
### Contribution description
This PR provides two fixes for the `usbdev_fs` driver:
- Fix endpoints registration
- Fix assignment of toggleable bits in EP_REG(x) registers
These bugs were encountered with the USBUS MSC implementation.
Regarding the endpoints registration:
For the `usbdev_fs` peripheral, IN and OUT endpoints of the same index must have the same type.
For instance, if EP1 OUT is a bulk endpoint, EP1 IN must either be unused or used as bulk too but it cannot be used as interrupt or isochronous.
With the previous check, the following registration pattern (EP OUT Bulk -> EP IN Interrupt -> EP IN Bulk) would assign both EP OUT Bulk and EP IN Interrupt to same endpoint index. So the configuration would be broken.
Applying the same registration pattern with this patch would now produce EP OUT Bulk -> 1 / EP IN Interrupt -> 2 / EP IN Bulk 1. Which is a working configuration for this IP.
and for the second fix:
EP_REG(x) registers have a total of 6 toggleable bits. Those bits can only be toggled if we write a one to it, otherwise writing a zero has no effect
This commit fixes all the access to these registers to prevent from modifying these bits when not needed.
Without this patch, the endpoint status (VALID / NACK / STALL) can be erroneously modify because bits are not cleared when assigning the new content to the register and thus make the bits toggle and change values.
### Testing procedure
This can be tested with tests/usbus_msc on any board using this `usbdev_fs` driver.
It is easier to test this PR with #19443 alongside. Then the following would be enough:
`CFLAGS='-DSECTOR_COUNT=64' USEMODULE='mtd_emulated' make -j8 BOARD=p-nucleo-wb55 -C tests/usbus_msc flash`
Otherwise this can also be tested by attaching a SPI<->SDCARD adapter.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
EP_REG(x) registers have a total of 6 toggleable bits. Those bits can only be toggled if we write a one to it, otherwise writing a zero has no effect
This commit fixes all the access to these registers to prevent from modifying these bits when not needed
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
For the usbdev_fs peripheral, IN and OUT endpoints of the same index must have the same type.
For instance, if EP1 OUT is a bulk endpoint, EP1 IN must either be unused or used as bulk too but it cannot be used as interrupt or isochronous.
With the previous check, the following registration pattern (EP OUT Bulk -> EP IN Interrupt -> EP IN Bulk) would assign both EP OUT Bulk and EP IN Interrupt to same endpoint index. So the configuration would be broken.
Applying the same registration pattern with this patch would now produce EP OUT Bulk -> 1 / EP IN Interrupt -> 2 / EP IN Bulk 1. Which is a working configuration for this IP
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
The comments still claim STM32F1 support is missing, but this was
recently added.
Also, drop an empty line to fix `too many consecutive empty lines`
nitpick of the CI.
The driver previously failed to reliably clear the RXNE bit, resulting
in the next transfer to incorrectly read a stale register value. This
was noticed with the SD card SPI driver on an STM32F4, in which the
0xff byte of the previous byte transfer was returned instead of the
actual status byte, throwing the SD card driver off the rails.
The commit defines a new common CPU symbol `CPU_COMMON_ESP32X` in Kconfig that is used by all `CPU_FAM_ESP32x` symbols which selects features, modules and packages that are common for all ESP32x SoC variants. This avoids the selection of features, modules and packages again and again for each ESP32x SoC variant.
A number of ESP-IDF header files that are needed to compile RIOT include the header file `driver/gpio.h` only because of the definition of the type `gpio_num_t`. However, this header file contains the entire GPIO API definition of the ESP-IDF, which conflicts with that of RIOT.
The solution was to use a wrapper library that does not need to include the `driver/gpio.h` file of the ESP-IDF during compilation of RIOT code.
This commit provides another approach which does not require such a wrapper library. It just provides its own `driver/gpio.h` in RIOT that is included by ESP-IDF header files instead of the original `driver/gpio.h` in ESP-IDF. It defines only the required `gpio_num_t` if RIOT code is compiled but includes the original `driver/gpio.h` of ESP-IDF if ESP-IDF code is compiled. This avoids to create a wrapper library for each module.
19420: cpu/esp32: use ets_printf instead of puts in startup r=maribu a=gschorcht
### Contribution description
This PR provides a workaround that fixes the problem that restarting an application automatically after flashing it in download mode via USB Serial/JTAG doesn't work and requires a hard reset by pressing the RESET button before it starts.
The reason that the application doesn't restart automatically after flashing it is that an exception occurs if `puts` or `printf` is called during startup before the first interrupt driven context switch in `thread_yield_higher`. The console seems to hange after bootloader:
```
EESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380786
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x6c
load:0x403ce000,len:0x7ec
load:0x403d0000,len:0x2170
entry 0x403ce000
Pro cpu up.
```
However, the system stucks in a exception/printf loop. ESP32-C3 and ESP32-S3 are affected.
### Testing procedure
Flash a ESP32-C3 or ESP32-S3 board that don't have a USB-to-UART chip with reset logic on board, for example
```
BOARD=hip-badge make -j8 -C tests/shell flash
```
or
```
BOARD=esp32s3-pros3 make -j8 -C tests/shell flash
```
Connect a terminal to the the board. Without the PR, the console doesn't seem to work and the RESET button has to pressed explicitly to get it working. With the PR, the console should work.
The problem can also be caused when using
```
dist/tools/esptools/espreset.py -p /dev/ttyACM0
```
while connected with a terminal to the board. Without the PR, the console output stops after
```
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380786
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x6c
load:0x403ce000,len:0x7ec
load:0x403d0000,len:0x2170
entry 0x403ce000
Pro cpu up.
```
while it continues with the PR as following:
```
main(): This is RIOT! (Version: 2023.04-devel-713-gcb721-boards/
test_shell.
>
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19397: drivers/usbdev_synopsys_dwc2: fix and reenable DMA mode r=benpicco a=gschorcht
### Contribution description
This PR fixes the DMA mode for all STM32 USB OTG HS cores (including that for STM32F4xx CID 1.xxx) and reenables it. It fixes remaining problems in issue #19359.
This PR includes also includes some changes that are needed to use the DMA mode:
- EP number is used as defined in CMSIS (if defined) for STM32
- `periph_usbdev_hs` feature is added in Kconfig
- `periph_usbdev_hs` feature is added in board definition of `stm32f429i-disc1`
- largest number of available EPs is used for STM32 instead of the smallest number (to be able to use all EPs of HS peripheral)
- `stm32f429i-disco` is removed from blacklist in `tests/usbus_cdc_ecm` since it uses the HS peripheral
### Testing procedure
The following tests should work
```python
USEMODULE=stdio_cdc_acm BOARD=stm32f429i-disc1 make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[526755.875691] usb 1-2.2: new full-speed USB device number 106 using xhci_hcd
[526755.977853] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x84 has invalid maxpacket 512, setting to 64
[526755.977856] usb 1-2.2: config 1 interface 3 altsetting 1 endpoint 0x2 has invalid maxpacket 512, setting to 64
[526755.978762] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[526755.978764] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[526755.978766] usb 1-2.2: Product: stm32f429i-disc1
[526755.978768] usb 1-2.2: Manufacturer: RIOT-os.org
[526755.978769] usb 1-2.2: SerialNumber: 7C156425A950A8EB
[526755.991190] cdc_acm 1-2.2:1.0: ttyACM1: USB ACM device
[526755.998131] cdc_ether 1-2.2:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, a6:f6:4a:85:1d:c9
[526756.044150] cdc_ether 1-2.2:1.2 enp0s20f0u2u2i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_utmi' BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[528733.480207] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[528733.707800] usb 1-4.4: new high-speed USB device number 111 using xhci_hcd
[528733.808257] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[528733.808260] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[528733.808263] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[528733.808642] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[528733.808645] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[528733.808647] usb 1-4.4: Product: stm32f723e-disco
[528733.808649] usb 1-4.4: Manufacturer: RIOT-os.org
[528733.808651] usb 1-4.4: SerialNumber: A6BAC4E1B1E0806B
[528733.811988] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[528733.814456] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, e6:75:97:3a:74:ba
[528733.854371] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0
```
</details>
```python
USEMODULE='stdio_cdc_acm periph_usbdev_hs_ulpi' BOARD=stm32f746g-disco make -j8 -C tests/usbus_cdc_ecm flash
```
<details>
<summary>Test results</summary>
```python
[529000.944482] usb 1-4.3.4: reset high-speed USB device number 32 using xhci_hcd
[529003.728260] usb 1-4.4: new high-speed USB device number 114 using xhci_hcd
[529003.833107] usb 1-4.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[529003.833111] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[529003.833113] usb 1-4.4: config 1 interface 1 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[529003.833743] usb 1-4.4: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[529003.833747] usb 1-4.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[529003.833749] usb 1-4.4: Product: stm32f746g-disco
[529003.833751] usb 1-4.4: Manufacturer: RIOT-os.org
[529003.833753] usb 1-4.4: SerialNumber: 66FE8934D1A363E0
[529003.837143] cdc_acm 1-4.4:1.0: ttyACM1: USB ACM device
[529003.839755] cdc_ether 1-4.4:1.2 usb0: register 'cdc_ether' at usb-0000:00:14.0-4.4, CDC Ethernet Device, 6a:88:1f:1f:b1:f0
[529003.879025] cdc_ether 1-4.4:1.2 enp0s20f0u4u4i2: renamed from usb0```
```
</details>
### Issues/PRs references
Fixes#19359
19416: cpu/rpx0xx/cmsis: Update vendor header files r=benpicco a=maribu
### Contribution description
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no longer containing bit-fields to represent different fields within registers. While this would generally ease writing code, the RP2040 has the unpleasant feature of corrupting the remaining bits of the register when a write access that is not word-sized occurs in the memory mapped I/O area. This could happen e.g. when a bit field is byte-sized and byte-aligned.
### Testing procedure
No binary changes (hopefully).
### Issues/PRs references
This adds a few additional vendor defines, notably for USB. If anyone were to implement USB, this would be a requirement.
19418: cpu/gd32v: fix gpio_read in periph_gpio r=benpicco a=gschorcht
### Contribution description
This PR fixes a bug in `gpio_read` which made `gpio_read` completely unusable!
A small bug with big consequences. In `gpio_read` the combined port | pin_num parameter `pin` was used instead of the pin number `pin_num` for the call of `_pin_is_input`. This caused the problem that for example instead of accessing GPIOA->CTL0 with address 0x40010800, address 0x60018c00 was accessed. As a result, a pin was randomly detected as input or output and thus a result was arbitrarily returned. Approx. 50% of all inputs always returned LOW.
I found this error by coincidence when I tried to find out why the BOOT0 button on a Sipeed Longan Nano is not usable as a button in RIOT.
### Testing procedure
Flash `tests/periph_gpio`
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio flash
```
and use commands
```
init_in 0 8
read 0 8
```
Without this PR, the pin is always LOW. With the PR, the pin should be HIGH when the BOOT button is pressed.
### Issues/PRs references
19419: boards/sipeed-longan-nano: add BOOT as user button r=benpicco a=gschorcht
### Contribution description
This PR makes the BOOT button usable as a user button.
### Testing procedure
The test requires PR #19418 to work.
Flash and test:
```
BOARD=sipeed-longan-nano make -j8 -C tests/saul flash term
```
The output
```
Dev: BOOT Type: SENSE_BTN
Data: 0
```
should change to
```
Dev: BOOT Type: SENSE_BTN
Data: 1
```
when the BOOT button is pressed.
### Issues/PRs references
Depends on PR #19418
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Generated new vendor header files from upstream SVD files using:
./SVDConv "$PICO_SDK_DIR"/src/rp2040/hardware_regs/rp2040.svd \
--generate=header --fields=macro --fields=enum
Note: The missing `--fields=struct` flag resulted in the header no
longer containing bit-fields to represent different fields
within registers. While this would generally ease writing code,
the RP2040 has the unpleasant feature of corrupting the
remaining bits of the register when a write access that is not
word-sized occurs in the memory mapped I/O area. This could
happen e.g. when a bit field is byte-sized and byte-aligned.
19407: cpu/stm32/periph: Implement GPIO LL for STM32F1 without IRQ support (yet) r=gschorcht a=maribu
### Contribution description
This implements GPIO LL support for the STM32F1 in the first commit. IRQ support is added with https://github.com/RIOT-OS/RIOT/pull/19412.
This sneaks in a second commit replacing the `expect()` calls in `tests/periph_gpio_ll` with a trivial five-liner that doesn't `panic()`, so that stdio output will still be delivered on high level stdio implementations. The tests provides a lot of useful output to aid debugging, so its a great usability improvement if the test makes sure to actually deliver that output.
### Testing procedure
<details><summary><code>make -C tests/periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:09,188 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:10,299 # START
2023-03-17 18:55:10,307 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:10,309 # Test / Hardware Details:
2023-03-17 18:55:10,310 # ========================
2023-03-17 18:55:10,311 # Cabling:
2023-03-17 18:55:10,313 # (INPUT -- OUTPUT)
2023-03-17 18:55:10,315 # P2.10 (PC10) -- P2.2 (PC2)
2023-03-17 18:55:10,318 # P2.12 (PC12) -- P2.3 (PC3)
2023-03-17 18:55:10,322 # Number of pull resistor values supported: 1
2023-03-17 18:55:10,325 # Number of drive strengths supported: 1
2023-03-17 18:55:10,328 # Number of slew rates supported: 3
2023-03-17 18:55:10,330 # Valid GPIO ports:
2023-03-17 18:55:10,332 # - PORT 0 (PORT A)
2023-03-17 18:55:10,333 # - PORT 1 (PORT B)
2023-03-17 18:55:10,335 # - PORT 2 (PORT C)
2023-03-17 18:55:10,336 # - PORT 3 (PORT D)
2023-03-17 18:55:10,338 # - PORT 4 (PORT E)
2023-03-17 18:55:10,338 #
2023-03-17 18:55:10,341 # Testing gpio_port_pack_addr()
2023-03-17 18:55:10,343 # =============================
2023-03-17 18:55:10,343 #
2023-03-17 18:55:10,344 # All OK
2023-03-17 18:55:10,344 #
2023-03-17 18:55:10,346 # Testing gpip_ng_init()
2023-03-17 18:55:10,348 # ======================
2023-03-17 18:55:10,348 #
2023-03-17 18:55:10,354 # Testing is_gpio_port_num_valid() is true for PORT_OUT and PORT_IN:
2023-03-17 18:55:10,354 #
2023-03-17 18:55:10,358 # Testing input configurations for PIN_IN_0:
2023-03-17 18:55:10,361 # Support for input with pull up: yes
2023-03-17 18:55:10,366 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,369 # Support for input with pull down: yes
2023-03-17 18:55:10,374 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,378 # Support for input with pull to bus level: no
2023-03-17 18:55:10,383 # Support for floating input (no pull resistors): yes
2023-03-17 18:55:10,388 # state: in, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,388 #
2023-03-17 18:55:10,392 # Testing output configurations for PIN_OUT_0:
2023-03-17 18:55:10,397 # Support for output (push-pull) with initial value of LOW: yes
2023-03-17 18:55:10,401 # state: out-pp, slew: slowest, value: off
2023-03-17 18:55:10,404 # Output is indeed LOW: yes
2023-03-17 18:55:10,408 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,411 # Output can be pushed HIGH: yes
2023-03-17 18:55:10,417 # Support for output (push-pull) with initial value of HIGH: yes
2023-03-17 18:55:10,420 # state: out-pp, slew: slowest, value: on
2023-03-17 18:55:10,424 # Output is indeed HIGH: yes
2023-03-17 18:55:10,430 # Support for output (open drain with pull up) with initial value of LOW: no
2023-03-17 18:55:10,437 # Support for output (open drain with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,443 # Support for output (open drain) with initial value of LOW: yes
2023-03-17 18:55:10,449 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: off
2023-03-17 18:55:10,452 # Output is indeed LOW: yes
2023-03-17 18:55:10,458 # Support for output (open drain) with initial value of HIGH: yes
2023-03-17 18:55:10,465 # state: out-od, slew: slowest, pull: none, schmitt trigger: off, value: on
2023-03-17 18:55:10,470 # state: in, pull: down, schmitt trigger: off, value: off
2023-03-17 18:55:10,474 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,478 # state: in, pull: up, schmitt trigger: off, value: on
2023-03-17 18:55:10,483 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,488 # Support for output (open source) with initial value of LOW: no
2023-03-17 18:55:10,494 # Support for output (open source) with initial value of HIGH: no
2023-03-17 18:55:10,501 # Support for output (open source with pull up) with initial value of HIGH: no
2023-03-17 18:55:10,508 # Support for output (open source with pull up) with initial value of LOW: no
2023-03-17 18:55:10,511 # Support for disconnecting GPIO: yes
2023-03-17 18:55:10,515 # Output can indeed be pulled LOW: yes
2023-03-17 18:55:10,519 # Output can indeed be pulled HIGH: yes
2023-03-17 18:55:10,519 #
2023-03-17 18:55:10,523 # Testing Reading/Writing GPIO Ports
2023-03-17 18:55:10,526 # ==================================
2023-03-17 18:55:10,526 #
2023-03-17 18:55:10,529 # testing initial value of 0 after init
2023-03-17 18:55:10,531 # ...OK
2023-03-17 18:55:10,535 # testing setting both outputs_optional simultaneously
2023-03-17 18:55:10,537 # ...OK
2023-03-17 18:55:10,541 # testing clearing both outputs_optional simultaneously
2023-03-17 18:55:10,543 # ...OK
2023-03-17 18:55:10,547 # testing toggling first output (0 --> 1)
2023-03-17 18:55:10,548 # ...OK
2023-03-17 18:55:10,552 # testing toggling first output (1 --> 0)
2023-03-17 18:55:10,553 # ...OK
2023-03-17 18:55:10,557 # testing toggling second output (0 --> 1)
2023-03-17 18:55:10,558 # ...OK
2023-03-17 18:55:10,562 # testing toggling second output (1 --> 0)
2023-03-17 18:55:10,563 # ...OK
2023-03-17 18:55:10,569 # testing setting first output and clearing second with write
2023-03-17 18:55:10,570 # ...OK
2023-03-17 18:55:10,575 # testing setting second output and clearing first with write
2023-03-17 18:55:10,576 # ...OK
2023-03-17 18:55:10,580 # All input/output operations worked as expected
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,580 #
2023-03-17 18:55:10,582 # TEST SUCCEEDED
2023-03-17 18:55:10,588 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 456 }]}
```
</details>
<details><summary><code>make -C tests/bench_periph_gpio_ll BOARD=nucleo-f103rb flash term</code></summary>
```
2023-03-17 18:55:42,192 # Help: Press s to start test, r to print it is ready
s
2023-03-17 18:55:44,616 # START
2023-03-17 18:55:44,624 # main(): This is RIOT! (Version: 2023.04-devel-683-g9c3812-cpu/stm32/periph/gpio_ll)
2023-03-17 18:55:44,624 #
2023-03-17 18:55:44,626 # Benchmarking GPIO APIs
2023-03-17 18:55:44,628 # ======================
2023-03-17 18:55:44,628 #
2023-03-17 18:55:44,632 # estimating loop overhead for compensation
2023-03-17 18:55:44,635 # -----------------------------------------
2023-03-17 18:55:44,642 # 4168 us for 50000 iterations
2023-03-17 18:55:44,642 #
2023-03-17 18:55:44,647 # periph/gpio: Using 2x gpio_set() and 2x gpio_clear()
2023-03-17 18:55:44,651 # ---------------------------------------------------
2023-03-17 18:55:44,706 # 50000 iterations took 45840 us (50008 us uncompensated)
2023-03-17 18:55:44,713 # Two square waves pins at 1090750 Hz ( 999840 Hz uncompensated)
2023-03-17 18:55:44,719 # ~66 CPU cycles per square wave period (~72 cycles uncompensated)
2023-03-17 18:55:44,719 # :'-(
2023-03-17 18:55:44,719 #
2023-03-17 18:55:44,724 # periph/gpio_ll: Using gpio_ll_set() and gpio_ll_clear()
2023-03-17 18:55:44,729 # -------------------------------------------------------
2023-03-17 18:55:44,738 # 50000 iterations took 695 us (4863 us uncompensated)
2023-03-17 18:55:44,745 # Two square waves pins at 71942446 Hz ( 10281719 Hz uncompensated)
2023-03-17 18:55:44,750 # ~1 CPU cycles per square wave period (~7 cycles uncompensated)
2023-03-17 18:55:44,751 # :-D
2023-03-17 18:55:44,751 #
2023-03-17 18:55:44,755 # periph/gpio: Using 4x gpio_toggle()
2023-03-17 18:55:44,757 # -----------------------------------
2023-03-17 18:55:44,965 # 50000 iterations took 198646 us (202814 us uncompensated)
2023-03-17 18:55:44,972 # Two square waves pins at 251704 Hz ( 246531 Hz uncompensated)
2023-03-17 18:55:44,977 # ~286 CPU cycles per square wave period (~292 cycles uncompensated)
2023-03-17 18:55:44,978 # :'-(
2023-03-17 18:55:44,978 #
2023-03-17 18:55:44,982 # periph/gpio_ll: Using 2x gpio_ll_toggle()
2023-03-17 18:55:44,985 # -----------------------------------------
2023-03-17 18:55:45,010 # 50000 iterations took 15972 us (20140 us uncompensated)
2023-03-17 18:55:45,017 # Two square waves pins at 3130478 Hz ( 2482621 Hz uncompensated)
2023-03-17 18:55:45,023 # ~23 CPU cycles per square wave period (~29 cycles uncompensated)
2023-03-17 18:55:45,023 # :'-(
2023-03-17 18:55:45,023 #
2023-03-17 18:55:45,026 # periph/gpio: Using 4x gpio_write()
2023-03-17 18:55:45,029 # ----------------------------------
2023-03-17 18:55:45,097 # 50000 iterations took 58345 us (62513 us uncompensated)
2023-03-17 18:55:45,103 # Two square waves pins at 856971 Hz ( 799833 Hz uncompensated)
2023-03-17 18:55:45,109 # ~84 CPU cycles per square wave period (~90 cycles uncompensated)
2023-03-17 18:55:45,109 # :'-(
2023-03-17 18:55:45,110 #
2023-03-17 18:55:45,113 # periph/gpio_ll: Using 2x gpio_ll_write()
2023-03-17 18:55:45,117 # ----------------------------------------
2023-03-17 18:55:45,128 # 50000 iterations took 2777 us (6945 us uncompensated)
2023-03-17 18:55:45,135 # Two square waves pins at 18005041 Hz ( 7199424 Hz uncompensated)
2023-03-17 18:55:45,141 # ~4 CPU cycles per square wave period (~10 cycles uncompensated)
2023-03-17 18:55:45,141 # :-)
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,141 #
2023-03-17 18:55:45,142 # TEST SUCCEEDED
2023-03-17 18:55:45,149 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 448 }]}
```
</details>
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Use the largest instead of the smallest number of available EPs for this definition. This became necessary to be able to use all EPs of a USB OTG HS peripheral if enabled.
19371: sys/usbus: check for the number of required and provided EPs in static configurations r=dylad a=gschorcht
### Contribution description
This PR provides a static check at compile time whether the number of EPs required in a static configuration does not exceed the number of EPs provided by the USB device.
#### Background
In issue #19359 the problem was reported that `usbus_cdc_ecm` didn't work together with `stdio_cdc_acm` on some STM32 boards. The reason for some of the boards was simply that the application tried to allocate more EPs than available and simply ignored this and just didn't work.
#### Solution
Since `auto_init_usb` uses a static configuration with exactly one USBUS stack instance and one USB device, at least in case `auto_init` is used a static check can be carried out to make sure that the number of EPs required by the application doesn't exceed the number of EPs provided by the USB device. For this purpose, each `usbus_*` module defines the number of IN and OUT EPs required by that module. Each USB device driver defines the number of EPs provided by USB device if it differs from the default of 8 EPs. During the auto initialization the total number of required IN and OUT EPs is then compared with the number of EPs provided by the USB device using a static assert.
### Testing procedure
1. Green CI
2. Compilation of
```python
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f439zi make -j8 -C tests/usbus_cdc_ecm
```
should lead to compilation error
```python
sys/auto_init/usb/auto_init_usb.c:81:1: error: static assertion failed: "Number of required IN endpoints exceeded"
_Static_assert(USBUS_EP_IN_REQUIRED_NUMOF <= USBDEV_NUM_ENDPOINTS,
^~~~~~~~~~~~~~
Makefile.base:146: recipe for target 'tests/usbus_cdc_ecm/bin/nucleo-f439zi/auto_init_usbus/auto_init_usb.o' failed
```
while compilation of
```
USEMODULE='stdio_cdc_acm' BOARD=nucleo-f767zi make -j8 -C tests/usbus_cdc_ecm
```
should work.
### Issues/PRs references
Fixes issue #19359 partially.
19382: tests/pkg_nanors: use static allocation r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
The STM32 periph_timer driver reads the timer's status flags, then
clears them all. It is possible that a timer interrupt could occur
between reading the flag and clearing it. This would lead to a lost
interrupt.
The timer's status flags can be cleared by software, but can only be set
by the hardware. This patch takes advantage of this by only clearing the
flags it knows are set. The rest of the flags are set, which doesn't
actually change their state.
17086: usbdev: Add dedicated stall functions r=benpicco a=bergzand
### Contribution description
This PR adds dedicated stall functions for usbdev peripherals. Two
functions are added. The first function (usbdev_ep_stall) to enable and
disable the stall condition on generic endpoints. The second function is
a dedicated function to set the stall condition on endpoint zero in both
directions. This status can only be set and should automatically be
cleared by the usbdev implementation (or hardware) after a new setup
request is received from the host.
### Testing procedure
- examples/usbus_minimal should still enumerate correctly on the host side.
- #17085 can be used to demonstrate the ep0_stall function with the `tests/usbus_cdc_acm_stdio/` test
### Issues/PRs references
None
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19343: ztimer: add ztimer_stopwatch convenience functions r=benpicco a=benpicco
19349: cpu/native: Switch to ztimer for gettimeofday r=benpicco a=MrKevinWeiss
### Contribution description
A xtimer is somewhat taken over by ztimer this explicitly uses ztimer instead of relying on the compatibility layer.
### Testing procedure
`make all test -C tests/cpp11_mutex/`
and green murdock I guess.
### Issues/PRs references
19353: doc: add quicklink to boards in navbar r=benpicco a=OlegHahm
### Contribution description
Finding a list of supported boards and how to use them is an essential information. Currently this list is somewhat hidden under "Modules" which is not very intuitive. Hence, I propose to (at least) put a link in the side menu to this overview page.
### Testing procedure
1. Call `make doc`
2. Check the sidebar `${RIOT_BASE}/doc/doxygen/html/index.html` for an entry "Supported Boards"
19361: nanocoap_sock: ensure response address is the same as request address r=benpicco a=benpicco
19363: Fix stm32 timer periodic r=benpicco a=Enoch247
### Contribution description
From the commit msg:
> cpu/stm32/periph/timer: remove unneeded header
>
> I see no reason this header should be included. It does not exist in
> RIOT's source tree. This patch removes the include.
and
> cpu/stm32/periph/timer: fix execution flow
>
> The implmentation of `timer_set_absolute()` has The following problems.
> First, it attempts to restore the auto reload register (ARR) to it's
> default if the ARR was previosly set by `timer_set_periodic()` by
> comparing it to the channel's capture compare (CC) register _after_ it
> has already set the CC register. Secondly, it clears spurious IRQs
> _after_ the CC register has been set. If the value being set is equal to
> the timer's current count (or the two become equal before the supurios
> IRQ clearing happens), this could cause a legitimate IRQ to be cleared.
>
> The implmentation of `timer_set()` has the same error in handling the
> ARR as described above.
>
> This patch reorders the operations of both functions to do:
>
> 1. handle ARR
> 2. clear spurious IRQs
> 3. set channel's CC
> 4. enable IRQ
>
> Additionally, the calulation of `value` in `timer_set()` is moved
> earlier in the function's exec path as a pedantic measure.
### Testing procedure
I tested by doing the following:
1. `make -C tests/periph_timer BOARD=nucleo-f767zi all flash term`
2. press s
3. press [ENTER]
4. observe test passes
5. `make -C tests/periph_timer_periodic BOARD=nucleo-f767zi all flash term`
6. press s
7. press [ENTER]
8. observe test passes
9. `make -C tests/periph_timer_short_relative_set BOARD=nucleo-f767zi all flash term`
10. press s
11. press [ENTER]
12. observe test passes
### Issues/PRs references
- none known
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Oleg Hahm <oleg@hobbykeller.org>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
The implmentation of `timer_set_absolute()` has The following problems.
First, it attempts to restore the auto reload register (ARR) to it's
default if the ARR was previosly set by `timer_set_periodic()` by
comparing it to the channel's capture compare (CC) register _after_ it
has already set the CC register. Secondly, it clears spurious IRQs
_after_ the CC register has been set. If the value being set is equal to
the timer's current count (or the two become equal before the supurios
IRQ clearing happens), this could cause a legitimate IRQ to be cleared.
The implmentation of `timer_set()` has the same error in handling the
ARR as described above.
This patch reorders the operations of both functions to do:
1. handle ARR
2. clear spurious IRQs
3. set channel's CC
4. enable IRQ
Additionally, the calulation of `value` in `timer_set()` is moved
earlier in the function's exec path as a pedantic measure.
19341: Picolibc updates r=benpicco a=keith-packard
### Contribution description
Minor updates to picolibc support for newer versions of picolibc, including 1.8.
### Testing procedure
Here's the current build result for a board I happen to have on my bench right now:
```
$ make -C examples/blinky BOARD=nucleo-f103rb FEATURES_REQUIRED=picolibc
...
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:319:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
319 | _READ_WRITE_RETURN_TYPE read(int fd, void *dest, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/keithp/src/RIOT/sys/picolibc_syscalls_default/syscalls.c:351:1: error: unknown type name '_READ_WRITE_RETURN_TYPE'
351 | _READ_WRITE_RETURN_TYPE write(int fd, const void *src, size_t count)
| ^~~~~~~~~~~~~~~~~~~~~~~
...
```
### Description of changes
1. Fix the read/write return values (Picolibc 1.8 uses POSIX standard types now)
2. Add new symbols to linker scripts (Picolibc needs help dealing with TLS alignment)
3. Align stack and thread local storage block during thread setup.
19345: cpu/riscv_common: convert to uword_t usage r=benpicco a=dylad
### Contribution description
This PR makes use of `uword_t` type in a few places in `cpu/riscv_common`.
This should not have any effect on produced binaries.
### Testing procedure
CI should be enough.
### Issues/PRs references
Quickly adapt from #16994. It will help for 64 bits support one day ;)
Co-authored-by: Keith Packard <keithp@keithp.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Newer picolibc versions require some additional symbols defined in the
linker script to correctly manage alignment constraints on thread
local storage.
Signed-off-by: Keith Packard <keithp@keithp.com>
19329: MAINTAINING.md: add some notes on Bors r=benpicco a=benpicco
19330: native/stdio: Explicitly provide getchar r=chrysn a=chrysn
### Contribution description
This ensures that even when libc does not implement getchar through getc, any custom stdio is still in the loop when getchar is used.
Frankly, I don't know when this broke -- I'm pretty sure custom stdio worked just a few days ago -- but either way, without this patch RIOT on native currently bypasses a configured stdio for me.
### Testing procedure
* `make -C examples/saul all debug`
* `break stdio_read`
* `run`
Without this patch, observe how the shell runs w/o ever breaking. After, lots of breakpoint hits.
This is the way it behaves for me (Debian sid, libc6:i386 2.36-8). If it works for you before this patch, we might start bisecting the differences between the systems, but we may also accept that libcs may imlpement getchar in different ways, and not all of them pass by the getc which we're patching.
### Issues/PRs references
This is needed for testing #19289.
The implementation stems from the `fgetc(3)` man page, which states that "getchar() is equivalent to getc(stdin)".
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: chrysn <chrysn@fsfe.org>
This allows automatically moving format strings to flash, provided that
code previously compiled fine with `-Wformat-nonliteral` (which in RIOT
is the case due to `-Wformat=2`).
This adds a layer of convenience abstraction over classical Harvard
architectures (like most AVRs) that do not map the flash memory into
the data address space and modern Harvard architectures or von-Neumann
architectures that do so. The motivation is to safe a lot of RAM for
AVR by storing constant strings into flash.
19165: cpu/sam0_common: adc: implement 16 bit mode by oversampling r=dylad a=benpicco
19303: dist/tools/insufficient_memory: Minor improvements r=benpicco a=maribu
### Contribution description
`create_makefile.sh`:
- address all shellcheck warnings
- make script POSIX shell compatible
- use nproc to set the number of parallel jobs to increase throughput
- print error messages when building fails
- run `make info-boards-supported` with `EXTERNAL_BOARD_DIRS=""` to avoid adding out-of-tree boards to `Makefile.ci`.
- classify output as "not supported" also when used features are blacklisted, not only when required features are missing
`add_insufficient_memory_board.sh`:
- classify output as "not supported" also when used features are blacklisted, not only when required features are missing
### Testing procedure
Run the script; it should still work.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19256: pkg/tinyusb: add GD32VF103 support r=gschorcht a=gschorcht
### Contribution description
This PR provides the tinyUSB support for GD32VF103 and enables the `tinyusb_device` feature as well as `stdio_tinyusb_cdc_acm` for GD32VF103 boards.
### Testing procedure
```
BOARD=sipeeed-longan-nano make -C tests/shell flash term
```
should work
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19269: cpu/gd32v/periph_i2c: interrupt based driver r=gschorcht a=gschorcht
### Contribution description
This PR provides an interrupt-driven version of the I2C low-level driver.
The existing I2C low-level driver for GDVF103 uses a busy-waiting approach where the status register is continuously polled while waiting for a certain status when sending or receiving. The MCU is thus occupied the whole time during a send or receive operation.
The driver provided with this PR uses an interrupt-driven approach. This is, while waiting for a certain status when sending or receiving, the calling thread is suspended and woken up by interrupts.
Since the I2C controller allows to receive up to two bytes before the application has to react, receiving a single byte, two bytes or more than two bytes needs a different handling for correct receiption. This requires a tricky implementation which distinguish a number of different case. There the driver requires 860 byte more ROM and 8 byte more RAM.
### Testing procedure
The driver should work with any I2C sensor/actuator. It was tested with
- `tests/driver_bmp180`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
BMP180 test application
+------------Initializing------------+
Initialization successful
+------------Calibration------------+
AC1: 8448
AC2: -1208
AC3: -14907
AC4: 33310
AC5: 24774
AC6: 19213
B1: 6515
B2: 49
MB: -32768
MC: -11786
MD: 2958
+--------Starting Measurements--------+
Temperature [°C]: 22.0
Pressure [hPa]: 1006.49
Pressure at see level [hPa]: 1025.55
Altitude [m]: 157
+-------------------------------------+
Temperature [°C]: 22.0
Pressure [hPa]: 1006.56
Pressure at see level [hPa]: 1025.58
Altitude [m]: 157
+-------------------------------------+
```
</details>
- `tests/driver_ccs811`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
CCS811 test application
+------------Initializing------------+
+--------Starting Measurements--------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 0
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 0
eCO2 [ppm]: 400
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
TVOC [ppb]: 7
eCO2 [ppm]: 446
+-------------------------------------+
```
</details>
- `tests/driver_sht3x`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-355-g940c7-cpu/gd32v/periph_i2c_interrupt_driven)
SHT3X test application
+------------Initializing------------+
Initialization successful
+--------Starting Measurements--------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.50
+-------------------------------------+
Temperature [°C]: 21.47
Relative Humidity [%]: 54.53
+-------------------------------------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.48
+-------------------------------------+
Temperature [°C]: 21.46
Relative Humidity [%]: 54.47
+-------------------------------------+
```
</details>
- `tests/driver_l3gxxxx`
<details>
```
main(): This is RIOT! (Version: 2023.04-devel-375-g75547-cpu/gd32v/periph_i2c_interrupt_driven)
L3GXXXX gyroscope driver test application
Initializing L3GXXXX sensor
[OK]
gyro [dps] x: +0, y: -1, z: -2
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: +0, y: +0, z: +0
gyro [dps] x: -1, y: +0, z: +4
gyro [dps] x: +0, y: +0, z: -21
gyro [dps] x: +0, y: +0, z: +6
gyro [dps] x: -43, y: +0, z: -13
gyro [dps] x: -21, y: -2, z: +0
gyro [dps] x: +0, y: +1, z: +3
gyro [dps] x: +25, y: +0, z: +0
```
</details>
- `tests/driver_hd44780` with `pcf8574a` I2C interface
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19284: boards: support for the LILYGO TTGO T8 ESP32-S2 board r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the LILYGO TTGO T8 ESP32-S2 board which has a OLED display (not yet supported) and a SD-Card slot on board.
The board is equipped with a USB-C connector that connects either to a USB-to-UART bridge or to the USB-OTG/JTAG interface of the ESP32-S2 via some DIP switches.
The PR includes a very small fix of printf format string in `tests/malloc`. I can split it off.
### Testing procedure
t.b.d.
### Issues/PRs references
19286: cpu/esp_common: use generic WIFI_SSID/WIFI_PASS defines r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE
### Contribution description
The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.
### Testing procedure
Any application using MTD in conjunction with a board with an at24cxxx.
19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1
### Contribution description
Hi! 🦎
When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.
### Testing procedure
Before this patch:
Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
#0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
#1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
#2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
#3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
```
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.
Co-authored-by: Hendrik van Essen <hendrik.vanessen@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19263: cpu/stm32/periph/timer: don't stop counter r=maribu a=Enoch247
### Contribution description
From the git comment msg:
If a timer's channel was set with a really small realtive duration from now, such that it would be missed (underflowed), the driver would stop the timer, potentially causing missed ticks. It was stopped to ensure that the channel's output-compare register could be set to the current counter value, before re-enabling the timer's counter. This is a condition that will ensure that the underflow won't happen again and the interrupt will fire, at the cost of losing some ticks for very high speed clocks.
This patch replaces the logic that stopped the timer. Instead it uses a register provided by the timer hardware to trigger timer interrupts via software.
### Testing procedure
1. do
``` bash
$ cd tests/periph_timer_short_relative_set
$ make BOARD=nucleo-f303ze flash term
```
1. follow prompts to run test
1. observe all tests pass
1. apply patch below to break test
1. rerun test
1. observe test fails, so new method is doing its job
##### patch to intentionally break test
```` diff
diff --git a/cpu/stm32/periph/timer.c b/cpu/stm32/periph/timer.c
index 64a6f3a656..7078c46ab4 100644
--- a/cpu/stm32/periph/timer.c
+++ b/cpu/stm32/periph/timer.c
`@@` -177,7 +177,7 `@@` int timer_set(tim_t tim, int channel, unsigned int timeout)
if (value > timeout) {
/* time till timeout is larger than requested --> timer already expired
* ==> let's make sure we have an IRQ pending :) */
- dev(tim)->EGR |= (TIM_EGR_CC1G << channel);
+ //dev(tim)->EGR |= (TIM_EGR_CC1G << channel);
}
````
### Issues/PRs references
- none known
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
If a timer's channel was set with a really small realtive duration from
now, such that it would be missed (underflowed), the driver would stop
the timer, potentially causing missed ticks. It was stopped to ensure
that the channel's output-compare register could be set to the current
counter value, before re-enabling the timer's counter. This is a
condition that will ensure that the underflow won't happen again and the
interrupt will fire, at the cost of losing some ticks for very high
speed clocks.
This patch replaces the logic that stopped the timer. Instead it uses a
register provided by the timer hardware to trigger timer interrupts via
software.
17045: sys/coding: add XOR based coding module r=benpicco a=benpicco
19243: cpu/gd32v: add periph_gpio_ll and periph_gpio_ll_irq support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_gpio_ll` and `periph_gpio_ll_irq` support for GD32VF103. Level triggered interrupts are emulated.
`periph_gpio_ll_irq` could be split off from this PR as a separate PR if necessary.
### Testing procedure
Use any GD32V board and connect PA0 -> PB0 and PA1 -> PB1 where PA is the output port and PB the input port. With these connections `tests/periph_gpio_ll` should work.
```
BOARD=sipeed-longan-nano make -j8 -C tests/periph_gpio_ll flash term
```
If necessary, change the input and output pins by setting the environment variables and connect the corresponding pins, for example for `seeedstudio-gd32` PA1 -> PB8 and PA8 -> PB9:
```
PIN_OUT_0=1 PIN_OUT_1=8 PIN_IN_0=8 PIN_IN_1=9 BOARD=seedstudio-gd32 make -j8 -C tests/periph_gpio_ll flash term
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19240: tools/doccheck: add simple exclude to doccheck r=benpicco a=kfessel
while doccheck runs for #19228 and #19220, i saw some spikes in memory consumption, turned out that was `grep -Evf dist/tools/doccheck/exclude_patterns` using about 2GB RAM. This PR changes that.
### Contribution description
add `exclude_simple` to `doccheck` drived from `exclude patterns`
`sort`ed and `uniq`ued the simple excludes
removes no longer needed patterns from `exclude patterns`
simple excludes are string rules (no patterns just strings)
how to apply these:
in this PR:
*remove the path and line number from the rule
* that made some of them doubles of each other
* sorted and uniqued them.
* this set of excludes is no longer path specific (an exception covers all paths but may of them still contain a file name)
another possible solution would be to have the excludes line number specific.
### Testing procedure
run `dist/tools/doccheck/check.sh`
compare memory consumption of
master: `grep -Evf dist/tools/doccheck/exclude_patterns`
to
this PR: `grep -Fvf dist/tools/doccheck/exclude_simple`
### Issues/PRs references
19248: cpu/gd32v: add periph_dac support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_dac` support for GD32VF103.
### Testing procedure
`tests/periph_dac` should work on `sipeed-longan-nano` port on PA4 and PA5.
### Issues/PRs references
19255: boards/esp*: complete SD Card MTD config r=benpicco a=gschorcht
### Contribution description
This PR provides the remaining changes necessary to use the generic MTD SD Card configuration as described in PR #19216.
This includes defining the MTD offset for SD cards, since the default `MTD_0` device always uses the internal flash device, and the completion of the configuration for the ESP32 boards with a SD card interface.
### Testing procedure
`tests/vfs_default` should work now with SD Cards:
```
main(): This is RIOT! (Version: 2023.04-devel-323-gfcc07)
mount points:
/nvm0
/sd0
data dir: /sd0
> vfs df
Mountpoint Total Used Available Use%
/nvm0 3052 KiB 8 KiB 3044 KiB 0%
/sd0 7580 MiB 3632148992 B 21089792 B 99%
```
### Issues/PRs references
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19251: tests/driver_dac_dds: fix output of sine and saw functions r=benpicco a=benpicco
19254: cpu/gd32v: add periph_rtc_mem support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_rtc_mem` support for GD32VF103.
A modified version of this driver could also be used for STM32F1.
### Testing procedure
`tests/periph_rtt` should work on any GD32V board, for example:
```
BOARD=sipeed-longan-nano make -C tests/periph_rtt flash
```
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.04-devel-319-gebc86-cpu/gd32v/periph_rtc_mem)
RIOT RTT low-level driver test
RTT configuration:
RTT_MAX_VALUE: 0xffffffff
RTT_FREQUENCY: 32768
Testing the tick conversion
Trying to convert 1 to seconds and back
Trying to convert 256 to seconds and back
Trying to convert 65536 to seconds and back
Trying to convert 16777216 to seconds and back
Trying to convert 2147483648 to seconds and back
All ok
Initializing the RTT driver
RTC mem OK
This test will now display 'Hello' every 5 seconds
RTT now: 1
Setting initial alarm to now + 5 s (163841)
rtt_get_alarm() PASSED
RTC mem OK
```
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
This file contains the definitions for the DWC2 USB OTG FS IP Core from Synopsys as also defined in the CMSIS Device Peripheral Access Layer for each STM32 MCU and in the same way for ESP32x SoCs. GD32V MCUs use the same USB IP Core, but the vendor headers for these MCUs use a different register structure and different identifiers. To be able to use the same driver `usbdev_synopsys_dwc2`, the relevant USB IP core definitions have been extracted from `cmsis/f7/Include/stm32f767xx.h` which is under the copyright of STMicroelectronics, see below. This is the same file used by ESP32x SoCs but modified for GD32V MCUs.
19249: boards/gd32v: improve board definitions r=benpicco a=gschorcht
### Contribution description
This PR provides some small improvements of the existing board definitions for GD32VF103 boards for more flexibel default configurations and documentation of the board peripherals:
- Allow the remapping of SPI0 pins in SPI configuration (ae984b0bea)
- More flexible I2C configuration (0c337583b4)
The default I2C device configuration allows to define up to two I2C devices `I2C_DEV(0)` and `I2C_DEV(1)`. `I2C_DEV(0)` is always defined if the I2C peripheral is enabled by the module `periph_spi`. The second I2C device `I2C_DEV(1)` is only defined if `I2C_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two I2C devices depending on whether other peripherals are enabled that would collide with the I2C devices.
- More flexible SPI configuration (edbf59e37e)
The default SPI device configuration allows to define up to two SPI devices `SPI_DEV(0)` and `SPI_DEV(1)`. `SPI_DEV(0)` is always defined if the SPI peripheral is enabled by the module `periph_spi`. The second SPI device `SPI_DEV(1)` is only defined if `SPI_DEV_1_USED` is defined by the board. This allows to use the default configuration with one or two SPI devices depending on whether other peripherals are enabled that would collide with the SPI devices.
Furthermore, the CS signal in the SPI configuration is given by a define that can be overriden with another pin if
the default CS signal is connected to an unused hardware.
- Improve ADC config for Sipeed-Longan-Nano (c9c587ee00)
The ADC configuration was too complex. It was hard to follow when certain ADC lines are available. Furthermore, the order of ADC lines did depend on the use of other peripherals. Now, either the TFT display is not connected and all ADC lines are available or the TFT display is connected and the second SPI device is used so that only the first 4 ADC lines are available.
- Improve Kconfig for Sipeed-Longan-Nano (025f4fdf00)
Board-specific configuration not shown any longer directly in the top level menu but within a submenu.
- Improve peripherals documentation (7f0d560dd8, e24abe495a)
Available peripherals for the board are now documented in two tables ordered by RIOT peripheral names and by pins.
Although the different changes are small and mostly related to the documentation, I could split the PR if necessary.
### Testing
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18863: boards/esp32s2-mini: add definition for ESP32 S2 Mini r=gschorcht a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
16782: drivers/mfrc522: add new driver r=benpicco a=HendrikVE
### Contribution description
This PR adds support for the MFRC522. It is quite common in the Arduino world and it is quite cheap. The driver connects to the MFRC522 via SPI and is heavily based on the Arduino driver available [here](https://github.com/miguelbalboa/rfid). Basically it was ported, but with several improvements in readability and documentation.
### Testing procedure
The given (manual) test provides single commands for some driver functions.
19201: cpu/gd32v: add periph_i2c support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_i2c` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
The driver is a modified version of the driver for STM32F1 with some changes that were necessary to get it working on GD32V. As for STM32F1, the driver is using polling instead of interrupts for now. It will be implemented interrupt-driven later.
### Testing procedure
`tests/periph_i2c` as well as a test with any I2C sensor should work. The driver was tested with `tests/driver_l3gxxxx` and `tests/driver_bmp180`.
### Issues/PRs references
Co-authored-by: Hendrik van Essen <hendrik.ve@fu-berlin.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
When a timer is set, any pending interrupts must be cleared before the interrupt is enabled for the channel. Otherwise the interrupt would be triggered immediately when the timer is set.
19192: cpu/esp32: fixes for boot issues and crashes on ESP32 r=kaspar030 a=Flole998
### Contribution description
In syscalls_init() there is a call to malloc(), which will return NULL if the heap is not initialized before, causing the entire board to fail booting if MODULE_ESP_IDF_HEAP is used.
API of [vTaskDelete()](https://www.freertos.org/a00126.html) says, that if NULL is passed to vTaskDelete the calling task should be deleted.
This PR needs a backport to 2023.01.
### Testing procedure
Just compiling on the ESP32S2 and running it with WiFi caused it to not start anymore, no output, nothing. When Null is written to that null-pointer it hangs.
The second commit fixed an issue/assertion fail that happens when the WiFi connection drops/disconnects.
### Issues/PRs references
Issue was introduced with PR #19146
Co-authored-by: Flole998 <Flole998@users.noreply.github.com>
In syscalls_init() there is a call to malloc(), which will return NULL if the heap is not initialized before, causing the entire board to fail booting if MODULE_ESP_IDF_HEAP is used.
19185: cpu/gd32v: add periph_gpio_irq support r=gschorcht a=gschorcht
### Contribution description
This PR provides the `periph_gpio_irq` support and is one of a bunch of follow up PRs that complete the peripheral drivers for GD32VF103.
### Testing procedure
Use a GD32VF103 board and flash `tests/periph_gpio`. Note: The Sipeed Longan Nano works also with `seeedstudio-gd32` board defintion and could be used for testing.
```
BOARD=seeedstudio-gd32 make -C tests/periph_gpio flash (until PR #19170 is merged only `seeedstudio
```
With the GPIO PB8 and PB9 connected, the following test sequence should work:
```
> init_out 1 8
> init_int 1 9 2 0
GPIO_PIN(1, 9) successfully initialized as ext int
> set 1 8
INT: external interrupt from pin 9
> clear 1 8
INT: external interrupt from pin 9
```
### Issues/PRs references
19187: cpu/gd32v: add pm_layered support in periph_pm r=gschorcht a=gschorcht
### Contribution description
This PR provides the `pm_layered` support and is one of a bunch of follow up PRs that complete the peripheral drivers for GD32VF103.
Since the configuration of the deep sleep and the standby mode require the access CSR (control and status registers) of the MCU, the Nuclei-SDK NMSIS is added as package which provides a low-level interface for Nuclei-based RISC-V MCUs.
### Testing procedure
The best way to test it is to rebase this PR onto PR #19186 and to flash `tests/periph_pm` to any GD32VF103 board. Note: The Sipeed Longan Nano works also with `seeedstudio-gd32` board definition and could be used for testing.
```
BOARD=seeedstudio-gd32 make -C tests/periph_pm flash
```
The test output should be:
```
main(): This is RIOT! (Version: 2023.04-devel-174-g7dc91-cpu/gd32v/periph_pm_test)
...
mode 0 blockers: 1
mode 1 blockers: 2
mode 2 blockers: 0
Lowest allowed mode: 2
```
Using command the `set_rtc 1 5` command should let the MCU deep sleep for 5 seconds
```
> set_rtc 1 5
Setting power mode 1 for 5 seconds.
␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀>
```
while command `set_rtc 1 5` should set the MCU into the standby mode which is left with restart.
```
> set_rtc 0 5
Setting power mode 0 for 5 seconds.
main(): This is RIOT! (Version: 2023.04-devel-174-g7dc91-cpu/gd32v/periph_pm_test)
...
mode 0 blockers: 1
mode 1 blockers: 2
mode 2 blockers: 0
Lowest allowed mode: 2
>
```
The garbage on UART interface after deep sleep is caused by the clock synchronisation that becomes necessary after deep sleep and is the same as for other boards.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18472: drivers/mrf24j40: add support for IEEE 802.15.4 Radio HAL r=benpicco a=jia200x
19175: drivers/periph_common/flashpage: fix silent error r=benpicco a=Enoch247
### Contribution description
This patch removes a test that silently hides failed writes to NULL. Instead, assert is used to ensure that the address is not NULL.
### Testing procedure
I am not certain how to update the tests to catch asserts. If this is possible, I will add a test, if someone will point me to a good example to learn from.
### Issues/PRs references
- none
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
19079: cpu/esp32: add periph_flashpage support r=kaspar030 a=gschorcht
### Contribution description
This PR provides the `periph_flashpage` support for ESP32x SoCs.
For byte-aligned read access to constant data in the flash, the MMU of all ESP32x SoCs allows to map a certain number of 64 kByte pages of the flash into the data address space of the CPU. This address space is called DROM. Normally the whole DROM address space is assigned to the section `.rodata`. The default flash layout used by all ESP32x SoCs is:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | `factory` partition with the app image |
The factory partition consists of a number of 64 kByte pages for the sections `.text`, `.rodata`, `.bss` and others. The `.text` and `rodata` sections are page-aligned and are simply mapped into the instruction address space (IROM) and the data address space (DROM), respectively. All other sections are loaded into RAM.
If the `periph_flashpage` module is used, the `periph_flashpage` driver
- decreases the size of the `.rodata` section in DROM address space by `CONFIG_ESP_FLASHPAGE_CAPACITY`,
- adds a section `.flashpage.writable` of size `CONFIG_ESP_FLASHPAGE_CAPACITY` at the end of DROM address space that is mapped into data address space of the CPU,
- reserves a region of size `CONFIG_ESP_FLASHPAGE_CAPACITY` starting from `0x10000` in front of the image partition `factory` and
- moves the image partition `factory` by `CONFIG_ESP_FLASHPAGE_CAPACITY` to address `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY`.
The new flash layout is then:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | flashpage region |
| `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY` | `factory` partition with the app image |
This guarantees that the flash pages are not overwritten if a new app image with changed size is flashed. `CONFIG_ESP_FLASHPAGE_CAPACITY` has to be a multiple of 64 kBytes.
~The PR includes PR #19077 and PR #19078 for the moment to be compilable.~
### Testing procedure
The following tests should pass.
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/periph_flashpage flash term
```
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/mtd_flashpage flash term
```
### Issues/PRs references
Depends on PR #19077
Depends on PR #19078
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht
### Contribution description
This PR provides
- the tinyUSB DFU and DFU Runtime support and
- the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images.
~This PR includes PR #18983 for now to be compilable.~
### Testing procedure
1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example
```
BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash
```
and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode:
```
dfu-util --list
```
3. Flash a first application using the following command:
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0
```
and check that the application starts and is seen as upgradable:
```
dfu-util --list
```
4. Restart the node in bootloader DFU mode by:
```
dfu-util -e
```
Flash a second application, for example
```
FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \
make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1
```
and check that the second application starts and is seen as upgradable:
```
dfu-util --list
```
### Issues/PRs references
~Depends on PR #18983~
19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn
### Contribution description
Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release.
I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK.
### Issues/PRs references
#19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice).
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chrysn <chrysn@fsfe.org>
18763: sys/tiny_strerror: add missing error codes r=benpicco a=maribu
### Contribution description
When double-checking the error codes provided by newlib by default (without magic defines, such as `__LINUX_ERRNO_EXTENSIONS__` or `__CYGWIN__`), some where still missing in `tiny_strerror()`. This adds the missing ones.
This in turn showed that three errno codes were missing in the avr-libc compat `errno.h`, which are added as well.
### Testing procedure
Murdock should double check that the added errno codes indeed are defined by default.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
The TX line is set and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output to avoid a several msec long LOW pulse resulting in some garbage.
Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pins used by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
If LOG_LEVEL >= 4, such as in `tests/log_printfnoformat`, the ESP-IDF config function called for the GPIO pins of the UART will output the configuration with `printf` before the `_GLOBAL_REENT` structure is initialized. This causes a crash during system startup. Therefore the initialization by `syscalls_init` must be called earlier in the startup procedure.
19050: boards/common/cc26xx cc13xx: clean up and fix flash configs r=benpicco a=maribu
### Contribution description
- Add support for XDS110 debugger via `OPENOCD_DEBUG_ADAPTER=xds110`
- Clean up OpenOCD configs in `boards/common/cc26xx_cc13xx`
- No longer hardcode the debugger to xds110, but use `OPENOCD_DEBUG_ADATER ?= xds110`
- Add support for cc13x0, cc13x2, cc26x0
- `boards/cc2650*`: drop custom OpenOCD config in favor of shared one
- add variables needed to support flashing with `PROGRAMMER=jlink`
- allow specifying a custom OpenOCD command to bring the device to a halt state, as the default `reset halt` (which causes a second reset) is causing issues with the ICEPick JTAG routers in the CC26xx - CC13xx devices
- Use `halt` instead of `reset halt` for CC26xx / CC13xx boards in OpenOCD to avoid issues in flashing
### Testing procedure
```
make BOARD=cc2650-launchpad -C examples/default flash
```
Should now work. The same should still work for other cc26xx cc13xx boards.
### Issues/PRs references
Partially fixes: https://github.com/RIOT-OS/RIOT/issues/18750
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19109: cpu/gd32v: fix and extend Kconfig clock settings r=benpicco a=gschorcht
### Contribution description
This PR fixes the following issus of the clock configuration which led to highly deviating peripheral clocks so that the UART interface was not usable in my case:
1. Setting the `RCU_CTL` register just to the IRC8M bit also removes the IRC8M calibration and trim adjust value in this register. Therefore IRC8M calibration and trim adjust value have to be preserved and the IRC8M has to be set.
2. `CLOCK_HXTAL` is a value and not a flag, so that shifting to the left changes anything in the register but does not set the PLLSEL bit. `RCU_CFG0_PLLSEL_Msk` has to be used instead to set the PLLSEL bit.
3. `CONFIG_BOARD_HAS_HXTAL` is used to indicate that the board has an HXTAL connected. If the HXTAL is present, it is used as PLL clock source. But if the HXTAL is not present, the half IRC8M clock should be used as PLL clock source and must not be disabled at the end of clock settings. Using IRC8M clock as PLL clock source also requires another PLL multiplication factor.
Issues 1 and 2 led to the problem that IRC8M was used without calibration instead of HXTAL. With the fixes, the GD32V is working with as well as without HXTAL correctly.
Furthermore, the Kconfig configuration has been extended. It is now possible to configure the HXTAL frequency as well, since the GD32VF103 allows HXTAL clocks from 3 MHz to 25 MHz. This has currently been added directly to the board's Kconfig, as it is currently the only GD32VF103 board. It should be moved to a common Kconfig later when more GD32V boards are added.
### Testing procedure
`BOARD=seeedstudio-gd32 make -C tests/shell flash term` should still work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The configuration whether a HXTAL is present and what its clock frequency is will be added to Kconfig. Since it is the only GD32V board at the moment, the configuration is added to the Kconfig of the board, but should be moved to a common Kconfig later when more GD32V boards are added.
