19146: cpu/esp32: fix and improve UART initialization r=benpicco a=gschorcht
### Contribution description
This PR fixes issue #19138 that was introduced with PR #19100. It contains the following changes to fix the problems and to improve the UART initialization:
- If `LOG_LEVEL` is greater or equal 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 by `earlier in the startup procedure.
- 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 pinsused by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
- 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.
- To avoid a several msec long LOW pulse resulting in some garbage during the UART initialization, the TX line is set to HIGH and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output.
The PR requires a backport to 2023.1
### Testing procedure
The following tests should work with this PR:
- [ ] `tests/log_color`
- [ ] `tests/log_printfnoformat`
- [ ] `tests/sys_arduino`
### Issues/PRs references
Fixes#19138
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19071: boards/rpi-pico-w: initial support for rpi pico W board r=maribu a=krzysztof-cabaj
### Contribution description
This PR adds initial RIOT OS support for the Raspberry Pico W - the Raspberry Pico with a Wifi/Bluetooth Infineon CYW 43439 module (*).
The code is based on PR #15822 and contains changes associated with small differences between RPi Pico and Pico W. The most important is that LED0 is connected to the CYW 43439 module and without PIO (PR #17425) cannot be used (RP2040 and CYW 43439 are connected together using SPI and Pico SDK utilize PIO to program SPI). Current LED0 implementation is similar to one for `native` board and prints appropriate texts on STDIO.
(*) Currently network connectivity not implemented.
### Testing procedure
Flash sample program and look at doc:
```
make doc
xdg-open doc/doxygen/html/group__boards__rpi__pico__w.html
```
### Issues/PRs references
Based on PR #15822.
Needs PR #17425.
Additional doc:
[Raspberry Pi Pico and Pico W](https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html)
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
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.
19141: shell/rtc: Fix out of bounds access; document error behavior r=maribu a=chrysn
### Contribution description
### Testing procedure
Should be trivial enough, especially as the difference is hard to spot interactively.
On native, run the default example (and wait for the traffic to settle).
Then, run
```
> rtc poweron
> rtc settime 2022-01-01 00:00:00
> rtc settime 2022-99-01 00:00:00
```
Both still work, but the latter doesn't access unassigned memory any more
### Issues/PRs references
This fixes an issue that was submitted anonymously.
Co-authored-by: chrysn <chrysn@fsfe.org>
With b30efeeb65 a warning was introduced when using `make term` without
the proper toolchain installed (e.g. when using BUILD_IN_DOCKER, but
`term` outside of the docker). This removes this warning
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>
19102: gh-actions: report release-tests result to Matrix r=maribu a=miri64
19128: boards: common: stdio_cdc_acm: let tests wait a bit for serial port r=miri64 a=miri64
19133: makefiles/utils/strings.mk: Fix version_is_greater_or_equal r=maribu a=maribu
### Contribution description
The Makefile function `version_is_greater_or_equal` is used to check if a version of GNU Make is at least the required one. However, it has the built-in assumption the version numbers have to format x.y.z, but Alpine Linux currently ships GNU Make 4.4. This results in `$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell, which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to printing `0` with the given padding, if the number given to print is empty.
### Testing procedure
Append
```Makefile
$(info A=$(call version_is_greater_or_equal,4.2.0,4.2.0))
$(info B=$(call version_is_greater_or_equal,4.2,4.2.0))
$(info C=$(call version_is_greater_or_equal,4.1,4.2.0))
$(info D=$(call version_is_greater_or_equal,4.1.9,4.2.0))
$(info E=$(call version_is_greater_or_equal,5.1.9,4.2.0))
$(info F=$(call version_is_greater_or_equal,5.0.0,4.2.0))
$(info G=$(call version_is_greater_or_equal,4.2.1,4.2.0))
$(info H=$(call version_is_greater_or_equal,4.3.1,4.2.0))
```
e.g. to `makefiles/utils/strings.mk`, build something and observe the info output.
This yields
```
A=1
B=1
C=
D=
E=1
F=1
G=1
H=1
```
for me and does not complain about invalid `printf` invocations.
### Issues/PRs references
None
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The Makefile function `version_is_greater_or_equal` is used to check if
a version of GNU Make is at least the required one. However, it has
the built-in assumption the version numbers have to format x.y.z,
but Alpine Linux currently ships GNU Make 4.4. This results in
`$(call _pad_number,3,)` which runs `printf '$03d' ''` in the shell,
which is not valid.
This fixes the issue by making `_pad_number` more robust by fall back to
printing `0` with the given padding, if the number given to print is
empty.
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.
19129: boards/seeedstudio-gd32: fix HXTAL clock in Kconfig r=miri64 a=gschorcht
### Contribution description
This PR fixes the wrong default value of `CLOCK_HXTAL` in Kconfig introduced with PR #19109. It was accidentally set to the default value of 80 MHz instead of 8 MHz.
### Testing procedure
```
python3 dist/tools/compile_test/compile_like_murdock.py -a tests/shell -b seeedstudio-gd32 -j8
```
Without the PR the command gives:
```
tests/shell seeedstudio-gd32 FAIL: Kconfig hash mismatch
```
WIth the PR the compile test should pass:
```
tests/shell seeedstudio-gd32 PASS
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19122: boards/qn9080dk: Improve doc and add J-Link support r=benpicco a=maribu
### Contribution description
- document that the QN9080DK has an alternative firmware for the debugger/programmer that supports J-Link
- allow selecting the debugger firmware via parameter / environment variable
- add `JLINK_DEVICE` parameter to allow flashing via J-Link
### Testing procedure
- read the doc generated by the CI
- run `make flash BOARD=qn9080dk QN9080DK_JLINK=1` and `make flash BOARD=qn9080dk QN9080DK_JLINK=0`
- Confirm that in the former case flashing uses J-Link (if installed) or OpenOCD using the jlink interface (if J-Link is not installed)
- Confirm that in the second case (`QN9080DK_JLINK=0`) flashing uses OpenOCD and the dap interface.
- I tested this with the actual hardware, but it is sufficient to just check if the invocation of the flashing script is sane
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19125: dist/tools/esptools/export.sh: fixes IDF_TOOLS_PATH default setting r=benpicco a=gschorcht
### Contribution description
This PR re-adds the setting of the default value of the variable `IDF_TOOLS_PATH` which was accidentally removed with PR #18385.
The `IDF_TOOLS_PATH` variable is used by the ESP-IDF to define the path where the Espressif toolchain is installed. Reusing this variable to set the path of the toolchain in RIOT allows the use of an existing Espressif toolchain if it has already been installed with ESP-IDF. If the variable is not defined it is set to `${HOME}/.espressif` as described in [documentation](https://doc.riot-os.org/group__cpu__esp32.html#esp32_local_toolchain_installation):
```
if [ -z ${IDF_TOOLS_PATH} ]; then
IDF_TOOLS_PATH=${HOME}/.espressif
fi
```
Unfortunatly were these 3 lines be removed in `dist/tools/esptools/export.sh` accidentially with #18385 so that it became necessary to set this variable manually. If the variable was not set, the `dist/tools/esptools/export.sh` script didn't work for the Espressif toolchain installed with the companion script `dist/tools/esptools/install.sh`.
### Testing procedure
```
dist/tools/esptools/install.sh esp32
. dist/tools/esptools/export.sh esp32
```
Without the PR, the export doesn't work, with the PR it works.
### Issues/PRs references
Fixes PR #18385
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Typically, OpenOCD is already performing a reset on connect. A
`reset halt` to bring the target to a `halt` state for flashing will
result in the device going through a second reset cycle. This can be
problematic with some device, such as the CC26xx MCUs. For these
devices, an `OPENOCD_CMD_RESET_HALT := -c 'halt'` will avoid the second
reset that is causing the issues.
Place common OpenOCD configs for the different cc13xx and cc26xx
families in boards/common/cc26xx_cc13xx/dist and automatically select
the correct one based on the (prefix of the) value of `$(CPU_MODEL)`, if
`OPENOCD_CONFIG` was not specified and no custom `openocd.cfg` is
located in the board's `dist` folder.
The `cc2650-launchpad` and `cc2650stk` have been adapted to use the
common config instead.
This adds the configuration to allow choosing the XDS110 used in
cc13xx-launchpad and cc26xx-launchpad boards via the
`OPENOCD_DEBUG_ADAPTER` variable.
19123: pkg/esp8266_sdk: fix version string generation r=kaspar030 a=gschorcht
### Contribution description
This PR (hopefully) fixes the problem of different binary hashes for the same application in subsequent compilations.
Patching a package creates a new HEAD of the package repository. Using `git describe --tag` to generate a version string used for the ESP8266 bootloader therefore generates a different version string for each new compilation, which in turn results in different hash values of the binaries for the same application in subsequent compilations in CI. To use the commit in `git describe --tag` for commit used by the package, the commit has to specified in the command.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Patching a package creates a new HEAD of the package repository. Using `git describe --tag` to generate a version string used for the ESP8266 bootloader therefore generates a different version string for each new compilation, which in turn results in different hash values of the binaries for the same application in subsequent compilations in CI. To use the commit in `git describe --tag` for commit used by the package, the commit has to specified in the command.
