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.
17810: drivers/slipdev: implement sleep states r=benpicco a=benpicco
18348: sys/net/gnrc/pktbuf_static: make use of alignas() r=maribu a=maribu
### Contribution description
Since we are now using C11, we can make use of `alignas()` provided by `<stdalign.h>` to make the alignment code easier to read.
### Testing procedure
I didn't expect this to change binaries, but is safes 4 bytes. `elf_diff` shows that the compiler (at least GCC 11.3.0) was not able to detect that `gnrc_pktbuf_static_buf` was just an alias for `_pktbuf_buf`. That makes sense since it would be hard without LTO to rule out external writes to `gnrc_pktbuf_static_buf`, unless one would have added a `const` (to the pointer, not to the data the pointer points to).
The [output of `elf_diff`](https://mari-bu.de/pr_18348_gnrc_pktbuf_static_elf_diff.html) looks otherwise quite unscary.
Also:
```
$ make BOARD=nucleo-f767zi -C tests/unittests/ tests-pktbuf flash test
make: Entering directory '/home/maribu/Repos/software/RIOT/tests/unittests'
Building application "tests_unittests" for "nucleo-f767zi" with MCU "stm32".
[...]
Welcome to pyterm!
Type '/exit' to exit.
READY
s
START
.............................................
OK (45 tests)
make: Leaving directory '/home/maribu/Repos/software/RIOT/tests/unittests'
```
### Issues/PRs references
None
19120: CI: seperate check-labels and check-commits workflows r=maribu a=kaspar030
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
- 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
19115: boards/hip-badge: fix doc rendering r=benpicco a=benpicco
19116: makefiles/cargo-targets.inc.mk: Fix RISC-V target r=kaspar030 a=maribu
### Contribution description
Update the list of target triples to match
`makefiles/arch/riscv.inc.mk`. This fixes compilation with toolchains other than the obsolete toolchain that uses the incorrect `riscv-none-embed` triple.
### Testing procedure
```
make BOARD=hifive1b -C examples/rust-gcoap
```
Fails on `master` with a recent RISC-V toolchain, but hopefully compiles with this PR.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
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.
Update the list of target triples to match
`makefiles/arch/riscv.inc.mk`. This fixes compilation with toolchains
other than the obsolete toolchain that uses the incorrect
`riscv-none-embed` triple.
19113: boards/native: Drop backward compatibility code for glibc <= 2.17 r=maribu a=maribu
### Contribution description
Even Debian [oldstable is now at glibc 2.28](https://packages.debian.org/source/buster/glibc), so it is safe to assume that nobody needs this anymore.
This also fixes garbage on the terminal on musl systems, where `ldd --version` is not supported (and output on `stderr` was not redirected to `/dev/null`).
### Testing procedure
The CI will check if this breaks the `native` board.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Even Debian oldstable is now at glibc 2.28, so it is safe to assume that
nobody needs this anymore.
This also fixes garbage on the terminal on musl systems, where
`ldd --version` is not supported (and output on `stderr` was not
redirected to `/dev/null`).
19112: cpu/riscv_common/periph_timer: Fix timer_clear() r=benpicco a=maribu
### Contribution description
Previously, timer_clear() was a no-op, resulting in spurious IRQs from already canceled timeouts. This fixes the issue.
### Testing procedure
```
$ make BOARD=hifive1b flash test -C tests/periph_timer
[...]
Welcome to pyterm!
Bench Clock Reset Complete
ATE0-->ATE0
OK
AT+BLEINIT=0-->OK
AT+CWMODE=0-->OK
Help: Press s to start test, r to print it is ready
READY
s
START
main(): This is RIOT! (Version: 2023.01-devel-773-g441b69)
Test for peripheral TIMERs
Available timers: 1
Testing TIMER_0:
TIMER_0: initialization successful
TIMER_0: stopped
TIMER_0: set channel 0 to 5000
TIMER_0: starting
TIMER_0: channel 0 fired at SW count 3164199 - init: 3164199
TEST SUCCEEDED
```
(In `master`, the test fails with a spurious IRQ.)
### Issues/PRs references
https://github.com/RIOT-OS/RIOT/issues/18976
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19090: boards/hamilton: Add minimal doc r=benpicco a=maribu
### Contribution description
The doc of the board is still suboptimal, but at least an image to identify what board this is and a link to further information is a starting point.
### Testing procedure
The static tests will do.
### Issues/PRs references
None.
19111: boards/common/nrf52: Fix detection of JLinkExe r=kaspar030 a=maribu
### Contribution description
For nRF52 J-Link was intended to be preferred as programmer over OpenOCD when both are available, but falling back to OpenOCD when JLinkExe is not found in `$PATH`. However, there was call the shell missing to actually detect `JLinkExe`.
### Testing procedure
E.g. `make BOARD=nrf52840dk -C examples/default flash` should use J-Link again as default when both are installed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19110: boards/hifive1b: minor improvements r=kaspar030 a=maribu
### Contribution description
- Cleaning up flash config
- Only defaulting to J-Link as flasher when actually installed
- Add TTY_BOARD_FILTER to more reliably select the TTY of the HiFive1b board
### Testing procedure
- Flashing should still work
- Flashing should prefer J-Link over OpenOCD when both are available
- Flashing should prefer OpenOCD over J-Link when J-Link is not found
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
For nRF52 J-Link was intended to be preferred as programmer over OpenOCD
when both are available, but falling back to OpenOCD when JLinkExe is
not found in `$PATH`. However, there was call the shell missing to
actually detect `JLinkExe`.
- OpenOCD and J-Link flash configuration can be provided
unconditionally, as those variables do not conflict with any others
- Only use J-Link as default flasher if actually installed
`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.
`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.
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.
19106: core/lib: Add macros/utils.h header r=aabadie a=maribu
### Contribution description
The macros CONCAT(), MIN(), and MAX() are defined over and over again in RIOT's code base. This de-duplicates the code by moving the macros to a common place.
### Testing procedure
Generated binaries don't change, as this only a de-duplication of macros that doesn't change their definition.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19099: dist/tools/usb-serial: Clean up legacy scripts r=aabadie a=maribu
### Contribution description
Refactor the old bash scripts to use `ttys.py` instead and update the documentation.
### Testing procedure
The pi fleet should still work without modification.
### Issues/PRs references
Fixes https://github.com/RIOT-OS/RIOT/issues/15814
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
