19856: tests/net/gcoap_fileserver: Fix failing nightlies r=benpicco a=MrKevinWeiss
### Contribution description
This test has been failing inconsistently in the nightlies and sometimes on unrelated PRs. I was able to reproduce it with murdock and as soon as I added some print statements to the test it went away. Since the issue is something to do with a failure when comparing 2 files after a node sends a file I am guessing that the comparison comes occasionally too fast and the file is not ready.
Maybe there is some more synchronization needed after a `ncput` but for now just adding a small sleep should prevent this issue.
### Testing procedure
Run murdock multiple times or try to get it failing on a local setup then apply the PR...
### Issues/PRs references
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19854: cpu/esp_common: esp-wifi: drop assert(val) r=benpicco a=benpicco
19858: tests/drivers/shtcx: don't repeat last string on error r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
To detect misconfigurations of addresses and sizes, the whole memory is filled word-wise with it's addresses. If the content doesn't match, it prints the address and the content.
f
This triggers a known bug much more often than with gnu toolchains to
the point that merging this PR without disabling the test would
render the CI useless.
19487: nanocoap: implement extended tokens (RFC 8974) r=benpicco a=benpicco
19808: boards: add ESP32-S3-USB-OTG support r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [ESP32-S3-USB-OTG](https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32s3/esp32-s3-usb-otg/user_guide.html) board.
The SD card can only be used in SPI mode at the moment. As soon as PR #19786 is merged, the SD/MMC support can be enabled and the SD card can then be used in SD mode with 4-bit data bus width.
The display uses uses the ST7789 driver IC that is compatible with the ST7735. For that purpose the ST7735 driver is extended by a pseudomodule definition `st7789` for the ST7789 which is enabled by the board and enables automatically the `st7789` (e57c48a33ee2a869c15603788e5306ba066f91cf). Vise versa, board's `Makefile.dep` enables automatically the `st7789` pseudomodule if the `st7735` is used. The pseudomodule `st7789` is just used to increase the upper limit for supported lines. This change is also part of PR #19807.
~The PR includes a very small documentation fix for ESP32-S3-DevKit board that was noticed during the development of this board definition (1155b6ac1b8efa39d8a0bd7150e602095159fdc1).~
### Testing procedure
The board has been tested with all basic tests for supported hardware including `tests/driver/st3375`:
- [x] tests/drivers/st3375
- [x] tests/periph/gpio
- [x] tests/periph/pwm
- [x] tests/periph/spi
- [x] tests/periph/uart
- [x] tests/sys/usbus_cdc_ecm
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
19712: cpu/riscv: Add PMP driver r=MrKevinWeiss a=Teufelchen1
### Contribution description
Hi! 🐘
this adds a basic RISC-V physical memory protection (PMP) driver to RIOT. Well, 'driver' might be a stretched, feels more like a little utility :)
EDIT: Also added a no-execute RAM option for the hifive & a corresponding test
Since I only have an Hifive rev b, it's only enabled on this board / cpu. I also tested the code on an ESP32-C but the feature can't be enabled there, as `cpu/riscv_common/` is not used by the ESP32...
### Testing procedure
* Grab a hifive rev b
* go to `examples/hello-world`
* Add `USEMODULES += periph_pmp` to the `Makefile`
* Include `pmp.h` in `main.c`
* Add code e.g. `print_pmpcfg(0);`
* compile & flash & term
You should see something like this:
```
# Hello World!
# You are running RIOT on a(n) hifive1b board.
# This board features a(n) fe310 MCU.
# pmp00cfg: - R-X OFF 0x00000000 - 0x00000000
```
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
19766: core/lib: make the use of DEBUG_BREAKPOINT on assert optional r=gschorcht a=gschorcht
### Contribution description
This PR makes the use of `DEBUG_BREAKPOINT` on failed assertion optional.
The behavior of `assert` has been changed with PR #19368. Instead of printing some useful information, either a breakpoint is inserted and the execution of the MCU stops in debugger or a endless while loop is executed.
Before PR #19368 the user got on failed assertion:
```
Starting ESP32x with ID: 7cdfa1e36a34
ESP-IDF SDK Version v4.4.1-0-g1329b19fe49
...
*** RIOT kernel panic:
FAILED ASSERTION.
*** halted.
```
This was very helpful during development, especially to identify quickly the cause of problems with `DEBUG_ASSERT_VERBOSE` enabled, e.g. when misconfiguration led to failed assertions.
With PR #19368 the user gets an address in best case (or even `0` on platforms like ESP32), in worst case the MCU seems to stuck, e.g.
```
Starting ESP32x with ID: 7cdfa1e36a34
ESP-IDF SDK Version v4.4.1-0-g1329b19fe49
...
0
```
The problem with the new behavior is that
- a user doesn't get a quick indication of what happened
- there is not always an easy way to attach a debugger
This PR therefore makes the use of `DEBUG_BREAKPOINT` optional using `DEBUG_ASSERT_BREAKPOINT` define.
### Testing procedure
Add `assert(0)` in `examples/hello-world/main.c` and compile with and w/o `CFLAGS='-DDEBUG_ASSERT_BREAKPOINT'`.
With `DEBUG_ASSERT_BREAKPOINT` the execution should stop in `assert_failue`. Without `DEBUG_ASSERT_BREAKPOINT`, the information as generated before PR #19368 and the execution should stop in `panic_arch`.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
- Rename all `arduino_pinmap.h` to `arduino_iomap.h`
- An empty `arduino_pinmap.h` that just includes `arduino_iomap.h`
is provided for backward compatibility
- Move all info from `arduino_board.h` into the new file as trivial
macros, so that they can also be used outside of sketches
- The new name reflects the fact not just pin mappings, but also
other I/O features such as PWMs are mapped
- Drop all `arduino_board.h`
- `arduino_board.h` and `arduino_iomap.h` now provide the exact
same information, just in a different format
- a generic `arduino_board.h` is provided instead that just
uses the info in `arduinio_iomap.h` and provides them in the
format the code in `sys/arduino` expects it
- Add fine grained features to indicate for mappings
- availability of mappings for analog pins, DAC pins, PWM pins,
UART devices, SPI/I2C buses to the corresponding RIOT
identification can now be expressed:
- `arduino_pins`: `ARDUINO_PIN_0` etc. are available
- `arduino_analog`: `ARDUINO_A0` etc. are available
- `arduino_pwm`: `ARDUINO_PIN_13_PWM_DEV` etc. are available
- `arduino_dac`: `ARDUINO_DAC0` etc. are available
- `arduino_uart`: `ARDUINO_UART_D0D1` or similar are available
- `arduino_spi`: `ARDUINO_SPI_ISP` or similar are available
- `arduino_i2c`: `ARDUINO_I2C_UNO` or similar are available
- mechanical/electrical compatibility with specific form factors
can now be expressed as features:
- `aruino_shield_nano`: Arduino NANO compatible headers
- `aruino_shield_uno`: Arduino UNO compatible headers
- `aruino_shield_mega`: Arduino MEGA compatible headers
- `aruino_shield_isp`: ISP header is available
This provides the groundwork to implement shield support as modules
that can rely on the I/O mappings, rather than having to provide a
configuration per board.
19718: drivers/dht: busy wait reimplementation r=benpicco a=hugueslarrive
### Contribution description
In PR #19674, I also provided quick and dirty fixes to restore functionality on esp8266 and enable operation on AVR. While reviewing PR #18591, it became apparent to me that this driver needed a refresh, particularly its migration to ztimer.
The cause of the malfunction on esp8266 was that since the default switch to ztimer as the backend for xtimer, XTIMER_BACKOFF was no longer taken into account. Therefore, the correction I provided in PR #19674 simply made explicit what was previously done implicitly with xtimer and now needs to be done explicitly with ztimer (spinning instead of sleeping).
Moreover, it was unnecessarily complex to measure the pulse duration in a busy-wait implementation, which required 2 calls to ztimer_now() and 32-bit operations expensive on 8-bit architecture. Instead, it is sufficient to read the state of the bus at the threshold moment.
Finally, in practice, it is possible to reduce the read interval (down to less than 0.5s for DHT22) by "harassing" the DHT with start signals until it responds.
This re-implementation brings the following improvements:
- Many backports from `@maribu's` IRQ based implementation (#18591):
- Use of ztimer
- Use of errno.h
- Use of a dht_data structure to pass arguments, to facilitate integration
- Adaptation of the bit parsing technique to parse bits into the data array
- Reintroduction of DHT11/DHT22 differentiation.
- Separation of `dht_read()` steps into functions for better readability and the ability to share certain functions among different implementations
- Sensor presence check in `dht_init()`
- ~~Automatic adjustment to a minimum data hold time~~
- Default input mode changed to open drain (a pull-up resistor should be placed close to the output if necessary but not close to the input)
- AVR support without platform-specific handling by avoiding ztimer_spin() and using the overflow of an 8-bit variable as a pre-timeout to minimize time-consuming ztimer_now() calls
Regarding the changes in the start signal sequence and the removal of the `_reset()` function:
~~In the previous implementation, there was an unnecessary spike at the beginning of the signal sequence, corresponding to START_HIGH_TIME. This spike has been removed in the re-implementation, as it is unnecessary. Instead, the MCU now simply pulls the signal low for START_LOW_TIME and then releases the bus, which is sufficient for initiating communication with the DHT sensor.~~ Actually, it is necessary to raise the bus level; otherwise, the _wait_for_level() called immediately after to check the response of the DHT may read the port before the signal level is raised, resulting in a false positive.
Additionally, the previous implementation had an issue where the MCU switched back to output mode and went high immediately after reading the 40 bits of data. However, the DHT sensor was still transmitting 2 or 3 additional bytes of '0' at that point, causing a conflict. This issue has been resolved in the re-implementation:
~~Regarding the optimization for AVR, I have performed measurements of `_wait_for_level()` until timeout (85 loops):~~
~~- on esp8266-esp-12x: 264 µs, which is 3.11 µs per loop~~
~~- on nucleo-f303k8: 319 µs, which is 3.75 µs per loop~~
~~- on arduino-nano: 3608 µs, which is 42.45 µs per loop~~
~~Duration measurements on the Arduino Nano:~~
19737: dist/tools/openocd: start debug-server in background and wait r=benpicco a=fabian18
19746: buildsystem: Always expose CPU_RAM_BASE & SIZE flags r=benpicco a=Teufelchen1
### Contribution description
Hello 🐧
This moves the definition of `CPU_RAM_BASE/SIZE` from being only available in certain situation to be always available.
Reason for change is to simplify common code in the cpu folder.
In cooperation with `@benpicco`
### Testing procedure
Passing CI
### Issues/PRs references
First usage will be in the PMP driver. Although there is more code in RIOT that could be refactored to use these defines instead of hacks / hardcoded values.
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
- many backports from @maribu's IRQ based implementation (#18591)
- use of ztimer and errno.h
- separation of dht_read() steps into functions for better readability
- reintroduction of DHT11/DHT22 differentiation
- sensor presence checking in dht_init()
- default input mode changed to open drain
- AVR support without platform-specific handling by avoiding
ztimer_spin() and using the overflow of an 8-bit variable as a
pre-timeout to minimize time-consuming ztimer_now() calls
- add a new DHT11_2022 type for 0.01 °C resolution devices
- data caching removed
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19743: tests/unittests: improve int size detection r=maribu a=maribu
### Contribution description
Deduce from the value of `INT_MAX` whether `int` is 16 bit or 32 bit, rather than check CPU names.
19744: tests: update tests for MSP430 CPU r=maribu a=maribu
### Contribution description
Using the builtin `__MSP430__` macro is fool-proof and stable even if one would try to rename and reorganize the MSP430 cpu code.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19706: boards/olimex-msp430-h2618: add new board r=maribu a=maribu
### Contribution description
This adds support of the Olimex MSP430-H2618 board. This board has plenty of RAM and ROM for an MSP430 board (even more than the z1), but still is easily obtainable.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19212: shell/rtc: use rtc_tm_normalize() to sanitize input r=benpicco a=benpicco
19360: gcoap: make use coap_build_reply() in gcoap_resp_init() r=benpicco a=benpicco
19401: shell/cmds: add genfile command r=benpicco a=benpicco
19645: sys/isrpipe: Replace xtimer with ztimer_usec r=benpicco a=MrKevinWeiss
### Contribution description
Getting ready for the xtimer dep.
### Testing procedure
Green murdock, there is no explicit test for isrpipe but since it runs xtimer compat it should operate the same.
### Issues/PRs references
19720: tests: remove unnecessary use of floating point r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19695: drivers/hih6130: avoid using floats r=maribu a=maribu
### Contribution description
- avoid using floating point arithmetic
- use ztimer instead of xtimer
- use fmt to print fixed point numbers in the test app
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19693: sys/color: extend unittest and fix module r=maribu a=kfessel
### Contribution description
this extends the unittest for sys_color testing more colors
### Testing procedure
```
RIOT_tree/tests/unittests$ make tests-color test
```
will fail since our `rgb2hsv` implementation is wrong (or is using an other colorspace than hsv2rgb (without documenting))
the new `hsv2rgb` test will succeed
### Issues/PRs references
#19614 was the reason i had a look at this
#1315 added the rgb2hsv and hsv2rgb function
#9940 added the test for black special case
https://www.vagrearg.org/content/hsvrgb << some optimization for that function (avoiding float)
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19696: drivers/mq3: avoid use of floats r=maribu a=maribu
19698: tests/pkg/lvgl: avoid using floats r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19691: drivers/bmx055: fix crazy use of FPU r=maribu a=maribu
### Contribution description
As the title says...
19694: tests/drivers/epd_bw_spi_disp_dev: fix accidental use of FPU r=maribu a=maribu
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
19686: sys/string_utils: add memchk() r=maribu a=benpicco
19687: tests/unittests: remove old workaround for SAML1X and gcc9.X bug r=maribu a=dylad
### Contribution description
This reverts #13462, this workaround is no longer needed with newer GCC version.
### Testing procedure
Try to compile tests/unittests for `saml11-xpro` or `saml10-xpro`
### Issues/PRs references
This is a revert of #13462.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19650: drivers/nrf24l01p: model in kconfig r=aabadie a=aabadie
19660: cpu/rpx0xx: Fix kconfig model r=aabadie a=MrKevinWeiss
### Contribution description
Broken master due to incorrect model of the periph_pio in kconfig.
### Testing procedure
Green murdock (now that the board is added to the list)
### Issues/PRs references
Look at the master CI...
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19618: cpu/stm32: fix riotboot settings for L4 and WB r=benpicco a=gschorcht
### Contribution description
This PR fixes the `riotboot` configuration for L4 and WB.
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work at all. Furthermore, a minimum `RIOTBOOT_LEN` of `0x2000` is required for L4.
Found when investigating the compilation errors for `bootloaders/riotboot_serial` in PR #19576.
### Testing procedure
1. Green CI.
2. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
```
In master these commands give
```
0x400
```
With this PR these commands give
```
0x200
```
as expected.
3. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
```
In master these commands give
```
0x1000
```
With this PR these commands give
```
0x2000
```
as expected.
### Issues/PRs references
19639: tests/net/gnrc_mac_timeout: add automated test r=aabadie a=aabadie
19644: gnrc_ipv6_nib: include RIO with all subnets in downstream RA r=benpicco a=benpicco
19649: gnrc_sixlowpan_iphc: prefix bits outside context must be zero r=benpicco a=benpicco
19656: gnrc/ipv6_auto_subnets: allow to configure minimal prefix length r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
- Replace all users of `$(RIOTBASE)/build` with the already present
`$(BUILD_DIR)` variable
- Replace all users of `$(BUILD_DIR)/pkg` with the already present
`$(PKGDIRBASE)` variable
- Create a `CACHEDIR.TAG` file in the `$(BUILD_DIR)`
18056: pkg/cmsis: use unique package for CMSIS headers, DSP and NN modules r=benpicco a=aabadie
19571: cpu/stm32/periph_adc: fixes and improvements for L4 support r=benpicco a=gschorcht
### Contribution description
This PR provides the following fixes and improvements for the `periph_adc` implementation for STM32L4.
- Support STM32L496AG added.
- Instead of defining the number of ADC devices for each MCU model, the number of ADC devices is determined from ADCx definitions in CMSIS header.
- MCU specific register/value defines are valid for all L4 MCUs, model based conditional compilation is removed.
- The ADC clock disable function is fixed using a counter. The counter is incremented in `prep` and decremented in `done`. The ADC clock is disabled if the counter becomes 0.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- The ASCR register is available and has to be set for all STM32L471xx, STM32L475xx, STM32L476xx, STM32L485xx and STM32L486xx MCUs. Instead of using the CPU model for conditional compilation, the CPU line is used to support all MCU of that lines.
- Setting of SQR1 is fixed. Setting the SQR1 did only work before because the `ADC_SRQ_L` is set to 0 for a sequence length of 1.
- Setting the `ADC_CCR_CKMODE` did only work for the reset state. It is now cleared before it is set. Instead of using the `ADC_CCR_CKMODE_x` bits to set the mode, the mode defines are used.
- Support for V_REFINT as ADC channel added.
### Testing procedure
19589: gnrc/gnrc_netif_hdr_print: printout timestamp if enabled r=aabadie a=chudov
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: chudov <chudov@gmail.com>
19585: tests: move leftover sys related tests to test/sys + move tests/sys/candev to tests/drivers r=aabadie a=aabadie
19586: tests: move net related applications to test/net r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19582: tests: move nimble and lwip related to test applications to tests/pkg r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19573: cpu/stm32/periph_dac: small improvements r=maribu a=gschorcht
### Contribution description
This PR provides the following improvements for `periph_dac` on STM32
- Support for `RCC_APB1ENR1_DAC1EN` symbol added.
- For boards that have not connected the V_REF+ pin to an external reference voltage, the VREFBUF peripheral can be used as V_REF+ (if supported) by setting `VREFBUF_ENABLE=1`.
- If the DAC peripheral has a mode register (`DAC_MCR`), it is set to normal mode with buffer enabled and connected to external pin and on-chip peripherals. This allows to measure the current value of a DAC channel with an ADC channel or to use the DAC channel also for other on-chip peripherals.
### Testing procedure
- Green CI
- `tests/periph_dac` should still work for any board supporting the `periph_dac` feature.
### Issues/PRs references
19579: doc/doxygen/src/flashing.md: work around Doxygen bug r=maribu a=maribu
### Contribution description
Doxygen fails to render inline code in headers correctly in the version the CI uses. So, work around the issue by not typestetting `stm32flash` as inline code but as regular text.
19583: tests: move cpu related applications to tests/cpu r=maribu a=aabadie
19584: tests/build_system/external_board_dirs: fix broken symlinks r=maribu a=aabadie
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19565: tests: move core related applications to their own tests/core/ folder r=maribu a=aabadie
19568: tests: move remaining driver related applications to tests/drivers r=maribu a=aabadie
19574: cpu/stm32/periph_gpio: reset PU/PD for ADC channels r=maribu a=gschorcht
### Contribution description
This PR provides a small fix that is relevant when a GPIO has been used as input/output with a pull resistor before it is initialized as an ADC channel.
The PU/PD configuration has to be `0b00` for analog outputs which is corresponds to the reset state. However, if the GPIO is not in the reset state but was used digital input/output with any pull resistor, the PU/PD configuration has also to be reset to use it as ADC channel.
### Testing procedure
- Green CI
- The `periph_adc` test application should still work for any board that supports the `periph_adc` feature.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19564: tests: move all bench applications to their own tests/bench/ folder r=aabadie a=aabadie
19569: tests/lua_loader: move to tests/pkg/lua_loader r=aabadie a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19552: tests: move all periph applications to their own periphs/ folder r=gschorcht a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19522: tests/periph_rtt: Fix for tick conversion test r=benpicco a=chudov
### Contribution description
Type casting and `printf` formatting for the `RTT_MAX_VALUE` and `RTT_FREQUENCY` are fixed so 32-bit value is properly handled by 'avr-libc'.
The original tick conversion test assumes that `RTT_FREQUENCY` is power of 2 so forward and backward ticks to seconds conversion results in the original ticks value. To fix it the result of the forward-backward conversion is compared with `ticktest / RTT_FREQUENCY * RTT_FREQUENCY` that considers rounding errors.
Changes were tested on deRFmega256 and nrf52840dongle.
### Testing procedure
tests/periph_rtt on a board with ATmega256RFR2 shall:
* show correct RTT_MAX_VALUE
* conversion check shall report no error.
### Issues/PRs references
Fixes#15940
Co-authored-by: chudov <chudov@gmail.com>
19368: debug: add DEBUG_BREAKPOINT() macro, set breakpoint on failed assertion r=benpicco a=benpicco
19529: cpu/stm32/periph/dac: optimize setting DAC r=benpicco a=Enoch247
### Contribution description
The current implmentation right shifted the 16 bit value passed into `dac_set()` down to the 12 bits that the DAC is actually capable of. This patch drops the shift and instead writes the 16 bit value to the DAC's left aligned 12 bit wide data holding register.
### Testing procedure
do something like:
``` c
#include "perip/dac.h"
int main(void)
{
dac_set(DAC_LINE(0), 0xffff/2);
return 0;
}
```
- observe DAC's output is half of vref
### Issues/PRs references
- none known
19531: tests/unittests: allow passing `UNIT_TESTS` via env r=benpicco a=kaspar030
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
19525: semtech-loramac: extend list of supported radio with sx1261, sx1262 and sx1268 r=maribu a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19346: pkg/tinydtls: allow build for AVR r=benpicco a=benpicco
19512: SUBSYSTEMS.md: add jia200x to subsystems r=benpicco a=jia200x
19513: boards/nrf52840dongle/doc: Update nrfutil pointers r=benpicco a=chrysn
### Contribution description
Nordic changed its nrfutil; this change adjust to it.
I'm not fully happy with recommending that tool at all due to its bad quality (see rambling in https://github.com/RIOT-OS/RIOT/issues/19511), but short of soldering on a debug header or touch-probing it with wires it's the only way in to the device. I may later add follow-up recommendations to switch to riotboot, but this now at least fixes the immediate issue.
### Testing procedure
* Look at the updated documentation.
### Issues/PRs references
Closes: https://github.com/RIOT-OS/RIOT/issues/19511
19514: dist/testbed-support: remove obsolete boards from iotlab archi r=benpicco a=aabadie
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
