20003: coap: create typedef for CoAP methods r=benpicco a=benpicco
20028: nanocoap: fix incorrect uses of coap_get_code() r=benpicco a=benpicco
20036: boards/nucleo-l4r5zi : add PWM configuration r=benpicco a=krzysztof-cabaj
### Contribution description
This PR adds to the Nucleo-l4r5zi PWM configuration
### Testing procedure
Flash the board using `tests/periph/pwm` program. Check if you could, for example, change LED
intensity using PWM.
### Issues/PRs references
None.
20041: pkg/littlefs2: bump to v2.8.1 r=benpicco a=bergzand
### Contribution description
Minor version number bump.
### Testing procedure
- Check if I copied the correct commit hash.
- Run the tests.
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
20032: boards/nucleo-l552ze: add PWM configuration r=benpicco a=krzysztof-cabaj
### Contribution description
This PR adds to the Nucleo-l552ze-q PWM configuration
### Testing procedure
Flash the board using `tests/periph/pwm` program. Check if you could, for example, change LED
intensity using PWM.
### Issues/PRs references
None.
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
19465: drivers/mtd: use XFA for pointers to defined MTDs r=benpicco a=gschorcht
### Contribution description
This PR provides the support to hold pointers to defined MTDs within a XFA. The XFA allows
- to access MTDs of different types (`mtd_flashpage`, `mtd_sdcard`, `mtd_emulated`, ...) by an index
- to determine the number of MTDs defined in the system.
### Testing procedure
To be defined once PR #19443 is merged because emulated MTDs will allow to test this PR on arbitrary boards.
### Porting Guide
For external boards:
- remove the `MTD_NUMOF` definition from `board.h`
- add `MTD_XFA_ADD(<mtd_dev>, <idx>);` to the definition of `<mtd_dev>`.
- `MTD_0`, `MTD_1`, … defines are no longer needed.
### Issues/PRs references
Related to PR #19443
19981: Fletcher32: Add incremental API r=benpicco a=bergzand
### Contribution description
This PR extends the current fletcher32 checksum with an incremental API mode. This way the bytes to be checksummed can be supplied via multiple successive calls and do not have to be provided in a single consecutive buffer.
I've also rephrased the warning with the original function a bit as that function uses an `unaligned_get_u16` to access the data. The data thus does not require alignment, but the length does need to be supplied as number of 16 bit words.
### Testing procedure
The test has been extended
### Issues/PRs references
None
19995: sys/psa_crypto: Fix macro for public key max size and SE example r=benpicco a=Einhornhool
### Contribution description
#### 1. Wrong public key size when using secure elements, introduced by #19954
Fixed conditions for key size macros in `crypto_sizes.h`.
#### 2. EdDSA and ECDSA examples fail when using a secure element because of unsopported changes introduced by #19954
Updated `example/psa_crypto` to use only supported functions for secure elements.
### Testing procedure
Build `example/psa_crypto` for secure elements and run application
Output on master:
```
2023-10-19 14:33:24,372 # main(): This is RIOT! (Version: 2019.07-devel-22378-gb6772)
2023-10-19 14:33:24,372 # HMAC SHA256 took 56393 us
2023-10-19 14:33:24,372 # Cipher AES 128 took 68826 us
2023-10-19 14:33:24,372 # *** RIOT kernel panic:
2023-10-19 14:33:24,373 # HARD FAULT HANDLER
2023-10-19 14:33:24,373 #
2023-10-19 14:33:24,373 # *** rebooting...
```
Output with fixes:
```
2023-10-19 13:35:24,715 # main(): This is RIOT! (Version: 2019.07-devel-22384-g8ef66-dev/psa-crypto-fixes)
2023-10-19 13:35:24,715 # HMAC SHA256 took 56374 us
2023-10-19 13:35:24,715 # Cipher AES 128 took 68805 us
2023-10-19 13:35:24,715 # ECDSA took 281164 us
2023-10-19 13:35:24,715 # All Done
```
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19943: cpu/stm32: FMC used for low-level LCD parallel interface r=maribu a=gschorcht
### Contribution description
This PR provides the implementation of the LCD low-level MCU 8080 parallel interface using the FMC peripheral.
### Testing procedure
```
BOARD=stm32f723e-disco make -C tests/drivers/st77xx flash
```
and
```
BOARD=stm32l496g-disco make -C tests/drivers/st77xx flash
```
should work on top of PR #19941. Drawing operations should be much faster.
### Issues/PRs references
Depends on PR #19941
19978: treewide: fix typos to make codespell happy r=maribu a=maribu
### Contribution description
- fixes typos in comments and docs (no generated firmware changes expected)
- fixes a typo in a string in a GUI of a utility program
- add some false positives to the ignore list
### Testing procedure
- No generated binaries (except for the GUI version of the utility program to flash the MSB-A2) should change
- The diff should not look too scary
### Issues/PRs references
None
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Either the wiki is down, or the image was removed from upstream. This
replaces it with the same image hosted on the zephyr doc. As a site
effect, code spell likes the new URL much more.
19760: cpu/sam0_common/periph: add low-level SDMMC peripheral driver for SDHC r=benpicco a=gschorcht
### Contribution description
This PR implements the low-level SDIO/SDMMC peripheral driver for SAM0 SDHC according to the definition in #19539.
### Testing procedure
```
BOARD=same54-xpro make -C tests/drivers/sdmmc
```
```
BOARD=same54-xpro make -C tests/sys/vfs_default
```
### Issues/PRs references
~Depends on PR #19539~
Depends on PR #19899
19946: posix_sockets.c: Fix 2 byte int compilation errors r=benpicco a=mrdeep1
19956: cpu/esp32: fix heap definition for ESP32-S2 and ESP32-S3 r=benpicco a=gschorcht
### Contribution description
For ESP32-S2 and ESP32-S3 the symbol `_heap_end` must not be used as `_eheap` for the newlibc `malloc` and function `sbrk`.
`_heap_end` is used by the ESP-IDF heap implementation `esp-idf-heap` and points to the highest possible address (0x40000000) that could be used for the heap in ESP-IDF. It doesn't point to the top address of the unused SRAM area that can be used in newlibc `malloc` and function `sbrk`. Instead, the origin and the length of `dram0_0_seg` must be used to calculate the end of the heap `_eheap`.
The problem only occurs for the newlibc `malloc` when the `sbrk` function is used but not for the ESP-IDF heap implementation `esp_idf_heap`.
### Testing procedure
Use any ESP32-S2 or ESP32-S3 board and flash `tests/sys/malloc`, e.g.
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart' BOARD=esp32s3-pros3 make -j8 -C tests/sys/malloc flash
```
Without the PR the `nm` command will give the wrong address
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
40000000 A _eheap
```
The test will stuck, i.e. the allocation of memory stops when the top of unused SRAM is reached and the board restarts when the watchdog timer expires. With the PR it should work as expected
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-309-g4669e)
calloc(zu, zu) = 0x10000000
CHUNK_SIZE: 16384
NUMBER_OF_TESTS: 3
Allocated 16384 Bytes at 0x3fc8c4b0, total 16384
...
Allocated 16384 Bytes at 0x3fcec6f0, total 409792
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403763e3
```
With this PR the `nm` command should give a address in unused SRAM address space
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
3fcca000 A _eheap
```
and the test should pass.
### Issues/PRs references
19957: cpu/esp32: fix Octal SPI RAM for ESP32-S3 r=benpicco a=gschorcht
### Contribution description
This PR fixes Octal SPI RAM handling for ESP32-S3.
Functions that are used during the initialization of the Octal SPI RAM must reside in IRAM instead of Flash. Otherwise, the system stucks during boot once the Octal SPI RAM is enabled. The reason is that the Flash is not available during the initialization of the Octal SPI RAM and the functions that are called during that initialization can't be accessed in Flash. As a result the call of such a function leads to code that is messed up and the system crashes.
The PR also includes the documentation fixe for the `esp32s3-box`. It also includes a small documentation fix regarding the SPI RAM for the `esp32s3-pros3` board.
### Testing procedure
Use a board that has Octal SPI RAM and flash `tests/sys/malloc`, e.g.:
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart esp_spi_ram esp_log_startup' \
BOARD=esp32s3-box make -C tests/sys/malloc
```
Without the PR, the system stuck during boot once the information for the Octal SPI RAM is print
```
ESP-ROM:esp32s3-20210327
...
I (133) boot: Loaded app from partition at offset 0x10000
I (134) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id : 0x02 (generation 3)
density : 0x03 (64 Mbit)
good-die : 0x01 (Pass)
Latency : 0x01 (Fixed)
VCC : 0x01 (3V)
SRF : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen : 0x01 (32 Byte)
Readlatency : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
```
and the board restarts when the watchdog timer expires.
With this PR, the system starts as expected.
```
ESP-ROM:esp32s3-20210327
...
I (132) boot: Loaded app from partition at offset 0x10000
I (133) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id : 0x02 (generation 3)
density : 0x03 (64 Mbit)
good-die : 0x01 (Pass)
Latency : 0x01 (Fixed)
VCC : 0x01 (3V)
SRF : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen : 0x01 (32 Byte)
Readlatency : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
Found 64MBit SPI RAM device
SPI RAM mode: sram 40m
PSRAM initialized, cache is in normal (1-core) mode.
Pro cpu up.
Single core mode
SPI SRAM memory test OK
Initializing. RAM available for dynamic allocation:
At 3FC8C150 len 00053EB0 (335 KiB): D/IRAM
At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
At 3FCF0000 len 00008000 (32 KiB): DRAM
Starting ESP32x with ID: f412fafd0f8c
ESP-IDF SDK Version v4.4.1
Current clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 SLOW=150000
PRO cpu is up (single core mode, only PRO cpu is used)
PRO cpu starts user code
Adding pool of 8192K of external SPI memory to heap allocator
Used clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 FAST=8000000 SLOW=150000
XTAL calibration value: 3643448
Heap free: 8754851 bytes
Board configuration:
UART_DEV(0) txd=43 rxd=44
LED pins=[ ]
BUTTONS pins=[ 0 ]
Starting RIOT kernel on PRO cpu
Help: Press s to start test, r to print it is ready
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Jon Shallow <supjps-libcoap@jpshallow.com>
19953: boards/esp32s3-wt32-sc01-plus: fix Kconfig r=aabadie a=gschorcht
### Contribution description
This PR fixes a remaining Kconfig mismatch. It should fix the last compilation problem of the nightly.
### Testing procedure
```
python3 dist/tools/compile_test/compile_like_murdock.py -a tests/drivers/ili9341/ -b esp32s3-wt32-sc01-plus
```
should fail w/o this PR but should succeed with this PR.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19914: boards: complete SD Card MTD definition for several bords r=benpicco a=gschorcht
### Contribution description
This PR completes the MTD definition for the following boards:
- `seeedstudio-gd32`
- `sipeed-longan-nano` including `sipeed-longan-nano-tft`
- `waveshare-nrf52840-eval-kit`
- ESP32x boards that have an SPI SD Card interface and use `mtd_sdcard_default`
### Testing procedure
Green CI
### Issues/PRs references#19465
Prerequisite for PR #19465
19915: drivers/lcd: support MCU 8080 8-bit parallel mode r=benpicco a=gschorcht
### Contribution description
LCD driver ICs usually support
- SPI serial mode,
- MCU 8080 8-bit parallel mode and
- MCU 8080 16-bit parallel mode.
This PR extends the LCD display driver API to support the MCU 8080 8-/16-bit parallel modes and implements a GPIO-driven MCU 8080 8-bit parallel mode.
The following features are already working locally and will be provided as follow-on PRs for which this PR is a prerequisite.
- GPIO-driven bit-banging implementation of the 16-bit mode of the MCU 8080 parallel interface
- Enabling the display on `stm32f723e-disco` and `stm32l496g-disco` using the feature above
- Definition of a low-level API for the parallel modes using the LCD controller of the MCU
- Using FMC for the display on `stm32f723e-disco` and `stm32l496g-disco`
- Using LCD controller for the display of `esp32-wt32-sc01-plus` (PR #19917)
### Testing procedure
The PR can be tested with PR #19917 on top of this PR.
```
BOARD=esp32s3-wt32-sc01-plus make -j8 -C tests/drivers/st77xx flash
```
The following video shows the test.
**Please note** The test is pretty slow because the display has 480 x 320 pixels and the MCU 8080 8-bit parallel interface is realized by a GPIO-driven bit-banging implementation where each GPIO of the data bus is set separately. A follow-up PR will use the ESP32-S3 LCD controller and DMA for this board. This PR just defines the extension of the driver by the parallel interface and provides the bit-banging implementation for MCUs that don't have a LCD controller on chip.
https://github.com/RIOT-OS/RIOT/assets/31932013/c1e3e3d7-05d9-4ca5-8fff-9a5eaca50fba
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19919: drivers/st77xx: introduce rotation defines r=benpicco a=gschorcht
### Contribution description
The PR introduces counterclockwise rotations for the definition of parameter `ST77XX_PARAM_ROTATION`.
It is more intuitive and universal to use `ST77XX_ROTATION_{0,90,180,270}` instead of `ST77XX_ROTATION_{ST77XX_ROTATION_{VERT,VERT_FLIP,HORZ,HORZ_FLIP}`, especially because the orientation of the display may vary with respect to the orientation of the board.
### Testing procedure
`tests/drivers/st77xx` should still work, for example:
```
BOARD=adafruit-pybadge make -C tests/drivers/st77xx flash
```
```
BOARD=esp32s3-usb-otg make -j8 -C tests/drivers/st77xx flash
```
### Issues/PRs references
19931: boards: fix documentation for GD32V boards and doxygen 1.9.4 r=benpicco a=gschorcht
### Contribution description
This PR fixes some small problems in documentation of `sipeed-longan-nano`, `sipeed-longan-nano-tft` and `seeedstudio-gd32` for doxygen 1.9.4 that is used on `doc.riot-os.org`.
Doxygen version 1.9.4 doesn't like anymore
- single double quotes as symbol for the inches unit in the text
- line breaks in `[]()` to avoid exhausting the 100 characters per line.
See https://doc.riot-os.org/group__boards__sipeed__longan__nano.html for example.
Doxygen 1.9.1 which is part of `riot-docker` container didn't have theses problems 😟
### Testing procedure
Documentation should be fixed.
### Issues/PRs references
19935: boards/nucleo64: fix SPI Arduino mapping for most boards r=benpicco a=maribu
### Contribution description
Before, the Arduino SPI mapping for all Nucleo-64 boards was incorrect. With this, the situation improves to the following:
- [x] nucleo-f030r8
- [ ] nucleo-f070rb
- No SPI buses provided.
- [x] nucleo-f072rb
- [x] nucleo-f091rc
- [x] nucleo-f103rb
- [ ] nucleo-f302r8
- No SPI bus at D11, D12, D13 provided
- [x] nucleo-f303re
- [x] nucleo-f334r8
- [x] nucleo-f401re
- [x] nucleo-f410rb
- [x] nucleo-f411re
- [x] nucleo-f446re
- [x] nucleo-g070rb
- [x] nucleo-g071rb
- [x] nucleo-g431rb
- [x] nucleo-g474re
- [x] nucleo-l053r8
- [x] nucleo-l073rz
- [x] nucleo-l152re
- No SPI bus at D11, D12, D13 provided
- [x] nucleo-l452re
- [x] nucleo-l476rg
- [x] nucleo-wl55jc
The remaining offenders still need to be fixed, but that is better done one PR at a time.
### Testing procedure
- Check if the SPI device provided in the given `boards/<BOARD_NAME>/incude/periph_conf.h` is indeed `SPI_DEV(0)`, or in `periph_conf.h` the correct SPI dev is found
- this should be fine for all boards above, except for the unchecked ones
or:
- run https://github.com/RIOT-OS/RIOT/pull/19932: The SPI test should pass now
### Issues/PRs references
Bug found in https://github.com/RIOT-OS/RIOT/pull/19932#issuecomment-1726305437
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
The pins P5.2, P5.1, P5.3 configured as SPI pins are only routed to
USART1 and not to USART0, but previously USART0 was configured as
peripheral backing the bus. This fixes the peripheral configuration by
changing it to USART1.
This is quite unfortunate as USART1 is also used to provide the UART
interface used for `stdio`. Hence, one can either use `stdio` or SPI.
A feature conflict between UART and SPI has therefore been added.
Note that while it would be possible to use P3.2, P3.1, P3.3 to provide
SPI with USART0, this would not work in practise: P3.1 and P3.3 are
connected to the CC1020 transceiver.
Switching to P3.4/P3.5 for UART to provide it using USART 0 would also
resolve the resource conflict. However, these pins are not available
via any of the header and would require soldering the UART<->USB
adapter directly to the pins of the MCU chip on the PCB. It is therefore
much more user friendly to keep the UART bus backed by USART1 to use
pins P3.6 and P3.7 that are easily accessible via the pin header.
19825: drivers: rename st7735 to more generic st77xx r=aabadie a=gschorcht
### Contribution description
This PR provides the following changes:
- renames the driver `st7735` to `st77xx`
- renames the test `st7735` to `st77xx`
- models controller variants as pseudomodules `st7735`, `st7789` and `st7796`
- removes the buggy initialization as a workaround to use reset defaults, see issue #19818
- adds backward compatibility header files for `ST7735_PARAM_*` symbols
- adds a test board for compilation test of backward compatibility
- updates the corresponding board definitions
The PR should solve the remaining dependency issues in KConfig we had by using `st7735` module for different controller variants. The backward compatibility header files should work for boards that still use `ST7735_PARAM_*` in their board definitions so that the board defintions at user's side use shouldn't be affected.
~To be compilable, the PR includes PR #19824.~
### Testing procedure
- Green CI
- `tests/drivers/disp_dev` and `tests/drivers/st77xx` should still work for all boards using a ST77xx display.
- The PR was already tested for these tests for:
- [x] `adafruit-pybadge`
- [x] `esp32s2-lilygo-ttgo-t8`
- [x] `esp32s3-usb-otg`
- [x] `sipeed-longan-nano`
### Issues/PRs references
Workaround for issue #19818
Preqruisite for PR #19827
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19910: boards/stm32f469i-disco: enable FMC with SDRAM support r=aabadie a=gschorcht
### Contribution description
This PR enables the FMC support on the `stm32f469i-disco` board and the on-board SDRAM ISSI IS42S32400F-6BL with 16 MByte.
### Testing procedure
1. `tests/periph/fmc` should succeed, just compile and flash the app with
```
BOARD=stm32f469i-disco make -C tests/periph/fmc flash term
```
2. `tests/sys/malloc` should also use the SDRAM. Use
```
USEMODULE=periph_fmc_sdram CFLAGS='-DCHUNK_SIZE=131072' \
BOARD=stm32f469i-disco make -C tests/sys/malloc flash term
```
and check that the heap also uses the memory in the range from `0xc0000000` to `0xc0fffffff`.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18547: sys: PSA Crypto API implementation r=MrKevinWeiss a=Einhornhool
### Contribution description
This adds an implementation of the ARM [PSA Crypto API](https://armmbed.github.io/mbed-crypto/html/index.html) specification to RIOT.
It is a cryptographic API that supports software and hardware backends as well as the use of multiple secure elements, which can be configured with Kconfig.
It integrates indirect, identifier based key management to support persistent storage of key material in local memory and devices with protected key storage.
A description of the implementation design and an evaluation of the processing time and memory overhead in RIOT has been published here: [Usable Security for an IoT OS: Integrating the Zoo of Embedded Crypto Components Below a Common API](https://arxiv.org/abs/2208.09281)
#### Implementation status
So far this implementation supports the following operations:
- Volatile key storage
- AES in CBC mode
- Hashes (MD5, SHA1, SHA224, SHA256)
- HMAC SHA256
- ECDSA with NIST P192 and P256 curves
The following backends are supported so far:
- RIOT Cipher Module
- RIOT Hash Module
- Micro ECC library package
- Cryptocell 310 hardware accelerator on the Nordic NRF52840dk
- Microchip ATECC608A secure element
Other operations and backends as well as persistent key storage can and will be implemented by me and anyone who wants to contribute in the future.
### Testing procedure
So far there is a show case application in `examples/psa_crypto` to demonstrate the usage and configuration of different backends of the API (refer to the application README for more information).
Co-authored-by: Lena Boeckmann <lena.boeckmann@haw-hamburg.de>
19851: boards/stm32f769i-disco: enable FMC with SDRAM support r=aabadie a=gschorcht
### Contribution description
This PR enables the FMC support on the `stm32f769i-disco` board and the on-board SDRAM MT48LC4M32B2B5-6A with 16 MByte.
The PR also includes a very small documentation fix for the `stm32f746g-disco` board (commit
f761e2d616c861e4857563bae26152bc1f1699d7) and removes double empy line in the test app `tests/periph/fmc`.
### Testing procedure
1. `tests/periph/fmc` should succeed, just compile and flash the app with
```
BOARD=stm32f769i-disco make -C tests/periph/fmc flash term
```
2. `tests/sys/malloc` should also use the SDRAM. Use
```
USEMODULE=periph_fmc_sdram CFLAGS='-DCHUNK_SIZE=131072' \
BOARD=stm32f769i-disco make -C tests/sys/malloc flash term
```
and check that the heap also uses the memory in the range from `0xc0000000` to `0xc0fffffff`.
**UPDATE:** Tested with a `stm32f769i-disco` board.
<details>
<summary>Output from <b>tests/periph/fmc</b></summary>
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-88-gdcecc-boards/stm32f769i_disco_fmc)
FMC HCLK freq 216 MHz
8-bit data `@0xc0000000,` 16-bit data `@0xc0000100,` 32-bit data `@0xc0ffff00`
------------------------------------------------------------------------
C0000000 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
C0000010 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
C0000020 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
C0000030 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
C0000040 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
C0000050 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
C0000060 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
C0000070 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
C0000080 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
C0000090 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
C00000A0 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF
C00000B0 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
C00000C0 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
C00000D0 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
C00000E0 E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF
C00000F0 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
------------------------------------------------------------------------
C0000100 00 80 01 81 02 82 03 83 04 84 05 85 06 86 07 87
C0000110 08 88 09 89 0A 8A 0B 8B 0C 8C 0D 8D 0E 8E 0F 8F
C0000120 10 90 11 91 12 92 13 93 14 94 15 95 16 96 17 97
C0000130 18 98 19 99 1A 9A 1B 9B 1C 9C 1D 9D 1E 9E 1F 9F
C0000140 20 A0 21 A1 22 A2 23 A3 24 A4 25 A5 26 A6 27 A7
C0000150 28 A8 29 A9 2A AA 2B AB 2C AC 2D AD 2E AE 2F AF
C0000160 30 B0 31 B1 32 B2 33 B3 34 B4 35 B5 36 B6 37 B7
C0000170 38 B8 39 B9 3A BA 3B BB 3C BC 3D BD 3E BE 3F BF
C0000180 40 C0 41 C1 42 C2 43 C3 44 C4 45 C5 46 C6 47 C7
C0000190 48 C8 49 C9 4A CA 4B CB 4C CC 4D CD 4E CE 4F CF
C00001A0 50 D0 51 D1 52 D2 53 D3 54 D4 55 D5 56 D6 57 D7
C00001B0 58 D8 59 D9 5A DA 5B DB 5C DC 5D DD 5E DE 5F DF
C00001C0 60 E0 61 E1 62 E2 63 E3 64 E4 65 E5 66 E6 67 E7
C00001D0 68 E8 69 E9 6A EA 6B EB 6C EC 6D ED 6E EE 6F EF
C00001E0 70 F0 71 F1 72 F2 73 F3 74 F4 75 F5 76 F6 77 F7
C00001F0 78 F8 79 F9 7A FA 7B FB 7C FC 7D FD 7E FE 7F FF
------------------------------------------------------------------------
C0FFFF00 00 40 80 C0 01 41 81 C1 02 42 82 C2 03 43 83 C3
C0FFFF10 04 44 84 C4 05 45 85 C5 06 46 86 C6 07 47 87 C7
C0FFFF20 08 48 88 C8 09 49 89 C9 0A 4A 8A CA 0B 4B 8B CB
C0FFFF30 0C 4C 8C CC 0D 4D 8D CD 0E 4E 8E CE 0F 4F 8F CF
C0FFFF40 10 50 90 D0 11 51 91 D1 12 52 92 D2 13 53 93 D3
C0FFFF50 14 54 94 D4 15 55 95 D5 16 56 96 D6 17 57 97 D7
C0FFFF60 18 58 98 D8 19 59 99 D9 1A 5A 9A DA 1B 5B 9B DB
C0FFFF70 1C 5C 9C DC 1D 5D 9D DD 1E 5E 9E DE 1F 5F 9F DF
C0FFFF80 20 60 A0 E0 21 61 A1 E1 22 62 A2 E2 23 63 A3 E3
C0FFFF90 24 64 A4 E4 25 65 A5 E5 26 66 A6 E6 27 67 A7 E7
C0FFFFA0 28 68 A8 E8 29 69 A9 E9 2A 6A AA EA 2B 6B AB EB
C0FFFFB0 2C 6C AC EC 2D 6D AD ED 2E 6E AE EE 2F 6F AF EF
C0FFFFC0 30 70 B0 F0 31 71 B1 F1 32 72 B2 F2 33 73 B3 F3
C0FFFFD0 34 74 B4 F4 35 75 B5 F5 36 76 B6 F6 37 77 B7 F7
C0FFFFE0 38 78 B8 F8 39 79 B9 F9 3A 7A BA FA 3B 7B BB FB
C0FFFFF0 3C 7C BC FC 3D 7D BD FD 3E 7E BE FE 3F 7F BF FF
------------------------------------------------------------------------
fill complete memory of 16384 kByte, a . represents a 16 kByte block
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
ready
check memory content, a + represents one 16 kByte block of matching data
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ready
------------------------------------------------------------------------
Doing some benchmarks
write 8 bit: 233018us --- 0.013us per call --- 71999656 calls per sec
write 16 bit: 116510us --- 0.013us per call --- 71999038 calls per sec
write 32 bit: 563125us --- 0.134us per call --- 7448264 calls per sec
read 8 bit: 900066us --- 0.053us per call --- 18639984 calls per sec
read 16 bit: 1165181us --- 0.138us per call --- 7199403 calls per sec
read 32 bit: 225729us --- 0.053us per call --- 18581148 calls per sec
ready
------------------------------------------------------------------------
print first and last memory block after benchmark, should be 0xaa
C0000000 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000010 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000020 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000030 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000040 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000050 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000060 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000070 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000080 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0000090 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000A0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000B0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000C0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000D0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000E0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C00000F0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF00 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF10 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF20 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF30 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF40 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF50 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF60 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF70 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF80 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFF90 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFA0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFB0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFC0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFD0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFE0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
C0FFFFF0 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
------------------------------------------------------------------------
[SUCCESS]
{ "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 412}]}
```
</details>
<details>
<summary>Output from <b>tests/sys/malloc</b></summary>
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-88-gdcecc-boards/stm32f769i_disco_fmc)
calloc(zu, zu) = 0x10000000
CHUNK_SIZE: 131072
NUMBER_OF_TESTS: 3
Allocated 131072 Bytes at 0x200013a8, total 131072
Allocated 131072 Bytes at 0x200213c0, total 262152
Allocated 131072 Bytes at 0x200413d8, total 393232
Allocated 131072 Bytes at 0xc0000008, total 524312
Allocated 131072 Bytes at 0xc0020010, total 655392
Allocated 131072 Bytes at 0xc0040018, total 786472
Allocated 131072 Bytes at 0xc0060020, total 917552
Allocated 131072 Bytes at 0xc0080028, total 1048632
Allocated 131072 Bytes at 0xc00a0030, total 1179712
Allocated 131072 Bytes at 0xc00c0038, total 1310792
Allocated 131072 Bytes at 0xc00e0040, total 1441872
Allocated 131072 Bytes at 0xc0100048, total 1572952
Allocated 131072 Bytes at 0xc0120050, total 1704032
Allocated 131072 Bytes at 0xc0140058, total 1835112
Allocated 131072 Bytes at 0xc0160060, total 1966192
Allocated 131072 Bytes at 0xc0180068, total 2097272
Allocated 131072 Bytes at 0xc01a0070, total 2228352
Allocated 131072 Bytes at 0xc01c0078, total 2359432
Allocated 131072 Bytes at 0xc01e0080, total 2490512
Allocated 131072 Bytes at 0xc0200088, total 2621592
Allocated 131072 Bytes at 0xc0220090, total 2752672
Allocated 131072 Bytes at 0xc0240098, total 2883752
Allocated 131072 Bytes at 0xc02600a0, total 3014832
Allocated 131072 Bytes at 0xc02800a8, total 3145912
Allocated 131072 Bytes at 0xc02a00b0, total 3276992
Allocated 131072 Bytes at 0xc02c00b8, total 3408072
Allocated 131072 Bytes at 0xc02e00c0, total 3539152
Allocated 131072 Bytes at 0xc03000c8, total 3670232
Allocated 131072 Bytes at 0xc03200d0, total 3801312
Allocated 131072 Bytes at 0xc03400d8, total 3932392
Allocated 131072 Bytes at 0xc03600e0, total 4063472
Allocated 131072 Bytes at 0xc03800e8, total 4194552
Allocated 131072 Bytes at 0xc03a00f0, total 4325632
Allocated 131072 Bytes at 0xc03c00f8, total 4456712
Allocated 131072 Bytes at 0xc03e0100, total 4587792
Allocated 131072 Bytes at 0xc0400108, total 4718872
Allocated 131072 Bytes at 0xc0420110, total 4849952
Allocated 131072 Bytes at 0xc0440118, total 4981032
Allocated 131072 Bytes at 0xc0460120, total 5112112
Allocated 131072 Bytes at 0xc0480128, total 5243192
Allocated 131072 Bytes at 0xc04a0130, total 5374272
Allocated 131072 Bytes at 0xc04c0138, total 5505352
Allocated 131072 Bytes at 0xc04e0140, total 5636432
Allocated 131072 Bytes at 0xc0500148, total 5767512
Allocated 131072 Bytes at 0xc0520150, total 5898592
Allocated 131072 Bytes at 0xc0540158, total 6029672
Allocated 131072 Bytes at 0xc0560160, total 6160752
Allocated 131072 Bytes at 0xc0580168, total 6291832
Allocated 131072 Bytes at 0xc05a0170, total 6422912
Allocated 131072 Bytes at 0xc05c0178, total 6553992
Allocated 131072 Bytes at 0xc05e0180, total 6685072
Allocated 131072 Bytes at 0xc0600188, total 6816152
Allocated 131072 Bytes at 0xc0620190, total 6947232
Allocated 131072 Bytes at 0xc0640198, total 7078312
Allocated 131072 Bytes at 0xc06601a0, total 7209392
Allocated 131072 Bytes at 0xc06801a8, total 7340472
Allocated 131072 Bytes at 0xc06a01b0, total 7471552
Allocated 131072 Bytes at 0xc06c01b8, total 7602632
Allocated 131072 Bytes at 0xc06e01c0, total 7733712
Allocated 131072 Bytes at 0xc07001c8, total 7864792
Allocated 131072 Bytes at 0xc07201d0, total 7995872
Allocated 131072 Bytes at 0xc07401d8, total 8126952
Allocated 131072 Bytes at 0xc07601e0, total 8258032
Allocated 131072 Bytes at 0xc07801e8, total 8389112
Allocated 131072 Bytes at 0xc07a01f0, total 8520192
Allocated 131072 Bytes at 0xc07c01f8, total 8651272
Allocated 131072 Bytes at 0xc07e0200, total 8782352
Allocated 131072 Bytes at 0xc0800208, total 8913432
Allocated 131072 Bytes at 0xc0820210, total 9044512
Allocated 131072 Bytes at 0xc0840218, total 9175592
Allocated 131072 Bytes at 0xc0860220, total 9306672
Allocated 131072 Bytes at 0xc0880228, total 9437752
Allocated 131072 Bytes at 0xc08a0230, total 9568832
Allocated 131072 Bytes at 0xc08c0238, total 9699912
Allocated 131072 Bytes at 0xc08e0240, total 9830992
Allocated 131072 Bytes at 0xc0900248, total 9962072
Allocated 131072 Bytes at 0xc0920250, total 10093152
Allocated 131072 Bytes at 0xc0940258, total 10224232
Allocated 131072 Bytes at 0xc0960260, total 10355312
Allocated 131072 Bytes at 0xc0980268, total 10486392
Allocated 131072 Bytes at 0xc09a0270, total 10617472
Allocated 131072 Bytes at 0xc09c0278, total 10748552
Allocated 131072 Bytes at 0xc09e0280, total 10879632
Allocated 131072 Bytes at 0xc0a00288, total 11010712
Allocated 131072 Bytes at 0xc0a20290, total 11141792
Allocated 131072 Bytes at 0xc0a40298, total 11272872
Allocated 131072 Bytes at 0xc0a602a0, total 11403952
Allocated 131072 Bytes at 0xc0a802a8, total 11535032
Allocated 131072 Bytes at 0xc0aa02b0, total 11666112
Allocated 131072 Bytes at 0xc0ac02b8, total 11797192
Allocated 131072 Bytes at 0xc0ae02c0, total 11928272
Allocated 131072 Bytes at 0xc0b002c8, total 12059352
Allocated 131072 Bytes at 0xc0b202d0, total 12190432
Allocated 131072 Bytes at 0xc0b402d8, total 12321512
Allocated 131072 Bytes at 0xc0b602e0, total 12452592
Allocated 131072 Bytes at 0xc0b802e8, total 12583672
Allocated 131072 Bytes at 0xc0ba02f0, total 12714752
Allocated 131072 Bytes at 0xc0bc02f8, total 12845832
Allocated 131072 Bytes at 0xc0be0300, total 12976912
Allocated 131072 Bytes at 0xc0c00308, total 13107992
Allocated 131072 Bytes at 0xc0c20310, total 13239072
Allocated 131072 Bytes at 0xc0c40318, total 13370152
Allocated 131072 Bytes at 0xc0c60320, total 13501232
Allocated 131072 Bytes at 0xc0c80328, total 13632312
Allocated 131072 Bytes at 0xc0ca0330, total 13763392
Allocated 131072 Bytes at 0xc0cc0338, total 13894472
Allocated 131072 Bytes at 0xc0ce0340, total 14025552
Allocated 131072 Bytes at 0xc0d00348, total 14156632
Allocated 131072 Bytes at 0xc0d20350, total 14287712
Allocated 131072 Bytes at 0xc0d40358, total 14418792
Allocated 131072 Bytes at 0xc0d60360, total 14549872
Allocated 131072 Bytes at 0xc0d80368, total 14680952
Allocated 131072 Bytes at 0xc0da0370, total 14812032
Allocated 131072 Bytes at 0xc0dc0378, total 14943112
Allocated 131072 Bytes at 0xc0de0380, total 15074192
Allocated 131072 Bytes at 0xc0e00388, total 15205272
Allocated 131072 Bytes at 0xc0e20390, total 15336352
Allocated 131072 Bytes at 0xc0e40398, total 15467432
Allocated 131072 Bytes at 0xc0e603a0, total 15598512
Allocated 131072 Bytes at 0xc0e803a8, total 15729592
Allocated 131072 Bytes at 0xc0ea03b0, total 15860672
Allocated 131072 Bytes at 0xc0ec03b8, total 15991752
Allocated 131072 Bytes at 0xc0ee03c0, total 16122832
Allocated 131072 Bytes at 0xc0f003c8, total 16253912
Allocated 131072 Bytes at 0xc0f203d0, total 16384992
Allocated 131072 Bytes at 0xc0f403d8, total 16516072
Allocated 131072 Bytes at 0xc0f603e0, total 16647152
Allocated 131072 Bytes at 0xc0f803e8, total 16778232
Allocated 131072 Bytes at 0xc0fa03f0, total 16909312
Allocated 131072 Bytes at 0xc0fc03f8, total 17040392
Allocations count: 130
Free 131072 Bytes at 0x200013a8, total 16909328
Free 131072 Bytes at 0x200213c0, total 16778248
Free 131072 Bytes at 0x200413d8, total 16647168
Free 131072 Bytes at 0xc0000008, total 16516088
Free 131072 Bytes at 0xc0020010, total 16385008
Free 131072 Bytes at 0xc0040018, total 16253928
Free 131072 Bytes at 0xc0060020, total 16122848
Free 131072 Bytes at 0xc0080028, total 15991768
Free 131072 Bytes at 0xc00a0030, total 15860688
Free 131072 Bytes at 0xc00c0038, total 15729608
Free 131072 Bytes at 0xc00e0040, total 15598528
Free 131072 Bytes at 0xc0100048, total 15467448
Free 131072 Bytes at 0xc0120050, total 15336368
Free 131072 Bytes at 0xc0140058, total 15205288
Free 131072 Bytes at 0xc0160060, total 15074208
Free 131072 Bytes at 0xc0180068, total 14943128
Free 131072 Bytes at 0xc01a0070, total 14812048
Free 131072 Bytes at 0xc01c0078, total 14680968
Free 131072 Bytes at 0xc01e0080, total 14549888
Free 131072 Bytes at 0xc0200088, total 14418808
Free 131072 Bytes at 0xc0220090, total 14287728
Free 131072 Bytes at 0xc0240098, total 14156648
Free 131072 Bytes at 0xc02600a0, total 14025568
Free 131072 Bytes at 0xc02800a8, total 13894488
Free 131072 Bytes at 0xc02a00b0, total 13763408
Free 131072 Bytes at 0xc02c00b8, total 13632328
Free 131072 Bytes at 0xc02e00c0, total 13501248
Free 131072 Bytes at 0xc03000c8, total 13370168
Free 131072 Bytes at 0xc03200d0, total 13239088
Free 131072 Bytes at 0xc03400d8, total 13108008
Free 131072 Bytes at 0xc03600e0, total 12976928
Free 131072 Bytes at 0xc03800e8, total 12845848
Free 131072 Bytes at 0xc03a00f0, total 12714768
Free 131072 Bytes at 0xc03c00f8, total 12583688
Free 131072 Bytes at 0xc03e0100, total 12452608
Free 131072 Bytes at 0xc0400108, total 12321528
Free 131072 Bytes at 0xc0420110, total 12190448
Free 131072 Bytes at 0xc0440118, total 12059368
Free 131072 Bytes at 0xc0460120, total 11928288
Free 131072 Bytes at 0xc0480128, total 11797208
Free 131072 Bytes at 0xc04a0130, total 11666128
Free 131072 Bytes at 0xc04c0138, total 11535048
Free 131072 Bytes at 0xc04e0140, total 11403968
Free 131072 Bytes at 0xc0500148, total 11272888
Free 131072 Bytes at 0xc0520150, total 11141808
Free 131072 Bytes at 0xc0540158, total 11010728
Free 131072 Bytes at 0xc0560160, total 10879648
Free 131072 Bytes at 0xc0580168, total 10748568
Free 131072 Bytes at 0xc05a0170, total 10617488
Free 131072 Bytes at 0xc05c0178, total 10486408
Free 131072 Bytes at 0xc05e0180, total 10355328
Free 131072 Bytes at 0xc0600188, total 10224248
Free 131072 Bytes at 0xc0620190, total 10093168
Free 131072 Bytes at 0xc0640198, total 9962088
Free 131072 Bytes at 0xc06601a0, total 9831008
Free 131072 Bytes at 0xc06801a8, total 9699928
Free 131072 Bytes at 0xc06a01b0, total 9568848
Free 131072 Bytes at 0xc06c01b8, total 9437768
Free 131072 Bytes at 0xc06e01c0, total 9306688
Free 131072 Bytes at 0xc07001c8, total 9175608
Free 131072 Bytes at 0xc07201d0, total 9044528
Free 131072 Bytes at 0xc07401d8, total 8913448
Free 131072 Bytes at 0xc07601e0, total 8782368
Free 131072 Bytes at 0xc07801e8, total 8651288
Free 131072 Bytes at 0xc07a01f0, total 8520208
Free 131072 Bytes at 0xc07c01f8, total 8389128
Free 131072 Bytes at 0xc07e0200, total 8258048
Free 131072 Bytes at 0xc0800208, total 8126968
Free 131072 Bytes at 0xc0820210, total 7995888
Free 131072 Bytes at 0xc0840218, total 7864808
Free 131072 Bytes at 0xc0860220, total 7733728
Free 131072 Bytes at 0xc0880228, total 7602648
Free 131072 Bytes at 0xc08a0230, total 7471568
Free 131072 Bytes at 0xc08c0238, total 7340488
Free 131072 Bytes at 0xc08e0240, total 7209408
Free 131072 Bytes at 0xc0900248, total 7078328
Free 131072 Bytes at 0xc0920250, total 6947248
Free 131072 Bytes at 0xc0940258, total 6816168
Free 131072 Bytes at 0xc0960260, total 6685088
Free 131072 Bytes at 0xc0980268, total 6554008
Free 131072 Bytes at 0xc09a0270, total 6422928
Free 131072 Bytes at 0xc09c0278, total 6291848
Free 131072 Bytes at 0xc09e0280, total 6160768
Free 131072 Bytes at 0xc0a00288, total 6029688
Free 131072 Bytes at 0xc0a20290, total 5898608
Free 131072 Bytes at 0xc0a40298, total 5767528
Free 131072 Bytes at 0xc0a602a0, total 5636448
Free 131072 Bytes at 0xc0a802a8, total 5505368
Free 131072 Bytes at 0xc0aa02b0, total 5374288
Free 131072 Bytes at 0xc0ac02b8, total 5243208
Free 131072 Bytes at 0xc0ae02c0, total 5112128
Free 131072 Bytes at 0xc0b002c8, total 4981048
Free 131072 Bytes at 0xc0b202d0, total 4849968
Free 131072 Bytes at 0xc0b402d8, total 4718888
Free 131072 Bytes at 0xc0b602e0, total 4587808
Free 131072 Bytes at 0xc0b802e8, total 4456728
Free 131072 Bytes at 0xc0ba02f0, total 4325648
Free 131072 Bytes at 0xc0bc02f8, total 4194568
Free 131072 Bytes at 0xc0be0300, total 4063488
Free 131072 Bytes at 0xc0c00308, total 3932408
Free 131072 Bytes at 0xc0c20310, total 3801328
Free 131072 Bytes at 0xc0c40318, total 3670248
Free 131072 Bytes at 0xc0c60320, total 3539168
Free 131072 Bytes at 0xc0c80328, total 3408088
Free 131072 Bytes at 0xc0ca0330, total 3277008
Free 131072 Bytes at 0xc0cc0338, total 3145928
Free 131072 Bytes at 0xc0ce0340, total 3014848
Free 131072 Bytes at 0xc0d00348, total 2883768
Free 131072 Bytes at 0xc0d20350, total 2752688
Free 131072 Bytes at 0xc0d40358, total 2621608
Free 131072 Bytes at 0xc0d60360, total 2490528
Free 131072 Bytes at 0xc0d80368, total 2359448
Free 131072 Bytes at 0xc0da0370, total 2228368
Free 131072 Bytes at 0xc0dc0378, total 2097288
Free 131072 Bytes at 0xc0de0380, total 1966208
Free 131072 Bytes at 0xc0e00388, total 1835128
Free 131072 Bytes at 0xc0e20390, total 1704048
Free 131072 Bytes at 0xc0e40398, total 1572968
Free 131072 Bytes at 0xc0e603a0, total 1441888
Free 131072 Bytes at 0xc0e803a8, total 1310808
Free 131072 Bytes at 0xc0ea03b0, total 1179728
Free 131072 Bytes at 0xc0ec03b8, total 1048648
Free 131072 Bytes at 0xc0ee03c0, total 917568
Free 131072 Bytes at 0xc0f003c8, total 786488
Free 131072 Bytes at 0xc0f203d0, total 655408
Free 131072 Bytes at 0xc0f403d8, total 524328
Free 131072 Bytes at 0xc0f603e0, total 393248
Free 131072 Bytes at 0xc0f803e8, total 262168
Free 131072 Bytes at 0xc0fa03f0, total 131088
Free 131072 Bytes at 0xc0fc03f8, total 8
Free count: 130
...
Free 131072 Bytes at 0xc0fc03f8, total 8
Free count: 130
[SUCCESS]
{ "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 396 }]}
```
</details>
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19355: boards/adafruit-itsybitsy-m4: configure littleFS on external flash r=aabadie a=benpicco
19883: drivers/stmpe811: introduce conversion for X and Y coordinates r=aabadie a=gschorcht
### Contribution description
To obtain coordinates from the touch panel that correspond to the display coordinates, it is often necessary to convert the coordinates by swapping and mirroring. Instead of hard coding this conversion, it is now controlled by an additional conversion parameter. For the sake of simplicity, possible rotations are predefined.
The PR fixes `tests/pkg/lgvl_touch` for the `stm32f429i-disc1` board where the coordinates from the touch panel seem to be mirrored in relation to the screen coordinates at the vertical axis.
### Testing procedure
Flash `tests/pkg/lvgl_touch`. Without this PR the coordinates of the button don't correspond to the touch panel coordinates once the button has been pressed. Instead they seem to be mirrored at the vertical axis. With this PR, the coordinates should be correct.
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19887: cpu/efm32/periph: add DAC support for EFM32 Series 1 (VDAC) r=aabadie a=gschorcht
### Contribution description
This PR provides a small change for `periph_dac` to support the VDACs of EFM32 Series 1 MCUs. It was tested with `sltb009a` board for which this PR includes the DAC configuration.
### Testing procedure
`tests/periph/dac` should work for the `sltb009a` board. I've tested it already.
```
BOARD=sltb009a make -j8 -C tests/periph/dac flash
```
### Issues/PRs references
Depends on PR #19886
19898: tests/net/gcoap_fileserver: disable test on CI r=aabadie a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19539: drivers/periph_sdmmc: define a High-level SDIO/SD/MMC API and low-level SDMMC periperal driver interface r=benpicco a=gschorcht
### Contribution description
This PR provides a SDIO/SD/MMC Device API (SDMMC). It implements a SD host controller driver that provides a high-level functions using a low-level SDIO/SD/MMC peripheral driver for accessing
- MultiMediaCards (MMC) and Embedded MultiMediaCards (eMMC)
- SD Memory Cards (SD Cards) with Standard Capacity (SDSC), High Capacity (SDHC) or Extended Capacity (SDXC).
It supports:
- 1-bit, 4-bit and 8-bit data bus width
- Default Speed and High Speed
- Auto-CLK
The SDIO/SD/MMC device API (SDMMC) is divided into two parts:
1. The high-level API that implements the SD Host Controller driver and allows
- to inititialize and identify different types of cards,
- to access them either blockwise or bytewise,
- to get information about the used card, and
- to send single commands or application specific commands to the card.
2. The low-level SDIO/SD/MMC peripheral driver implements the low-level functions required by the high-level device API. It has to be implemented for each MCU.
### Limitations:
- Only one card per SDIO/SD/MMC device is supported.
- eMMCs specific features are not supported.
- UHS-I, UHS-II and UHS-III are not supported.
### Testing procedure
PR #19540, PR #19760 or PR #19786 is needed to test this PR.
### Issues/PRs references
Prerequisite for PR #19540
Prerequisite for PR #19760
Prerequisite for PR #19786
19815: cpu/sam0_common/periph/sdhc: busy waiting and clock fixes r=benpicco a=benpicco
19860: drivers/ft5x06: fix vendor ID for FT6xx6 and FTxxxx register addresses r=benpicco a=gschorcht
### Contribution description
This PR provides a fix of the vendor ID for FT6xx6 touch panel driver ICs and a fix of register addresses for FTxxxx.
According to the [Application Note for FT6x06 CTPM](https://cdn-shop.adafruit.com/datasheets/FT6x06_AN_public_ver0.1.3.pdf), the vendor ID of FT6x06 touch panel driver ICs is `0x11` instead of `0xcd`. Although there are no information found in the Web about the FT6x36, the FT6336U touch panel of a ESP32-S3 WT32 SC01 Plus is also working with `0x11` as vendor ID so that it seems that FT6x36 is also using `0x11` as vendor ID.
Figured out with a `stm32f723e-disco` board (revision D03). Without this PR, `tests/drivers/ft5x06` gives:
```
+------------Initializing------------+
[ft5x06] init: invalid vendor ID: '0x11' (expected: 0xcd)
[Error] Initialization failed
```
With this PR it works as expected.
```
+------------Initializing------------+
Initialization successful
main(): This is RIOT! (Version: 2023.10-devel-96-gbb9011-drivers/ft5x06_fix_vendor_id)
FT5x06 test application
+------------Initializing------------+
[ft5x06] init: configuring touchscreen interrupt
Initialization successful
1 touch detected
[ft5x06] read gesture_id '0x00'
Touch 1 - X: 151, Y:138
[ft5x06] read gesture_id '0x00'
```
Some background information found in the Web:
- According to the [STM32CubeF7](c20e6dd15b/Drivers/BSP/STM32F723E-Discovery/stm32f723e_discovery_ts.c (L24-L27)) the FRIDA LCD panel mounted on the `stm32f723e-disco` board either uses FT6x36 (prior revision D) or FT3x67 (revision D). However, the FT5x06 driver type for the card is defined as FT6x06, which does not seem correct: bb9011c3fb/boards/stm32f723e-disco/include/board.h (L59)
- According to the [STM32CubeF7](c20e6dd15b/Drivers/BSP/Components/ft6x06/ft6x06.h (L269-L270)), the vendor ID for FT6x36 should be `0xcd`. However, the FT6336U on ESP32-S3 WT32 SC01 Plus works with vendor ID `0x11`.
- The [Adafruit FT6206 library](95118cd983/Adafruit_FT6206.h (L28)) uses `0x11` as vendor id.
- The `stm32l496g-disco` board uses a FT6236 which has vendor ID `0xcd`.
So the information available on the web is confusing. Maybe, a better solution would be to accept `0x11` as well as `0xcd` as vendor ID for FT6xxx touch panels. Unfortunately, there are no documents available on the registers directly from FocalTech 😟 so it seems to be more speculation than knowledge.
### Testing procedure
### Issues/PRs references
19886: cpu/efm32: fix DAC configuration r=benpicco a=gschorcht
### Contribution description
The EFM32 MCU allows the reference voltage to be configured per DAC device, not per DAC channel. Also, the DAC reference voltage was defined in the configuration but not used anywhere.
At the moment we have only defined one board (`stwstk6220a`) that uses the DAC, so changing the configuration interface shouldn't be critical.
### Testing procedure
`tests/periph/dac` should still work for the `stwstk6220a`
```
BOARD=slwstk6220a make -j8 -C tests/periph/dac flash
```
I don't have a `stwstk6220a` board (EFM32 Series 0) so that I can't test it. I could only test it for the `sltb009a` board (EFM32 Series 1) with the change for VDAC in PR #19887.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
After cleaning up the default config of SPI, this commit cleans up the configuration for `sipeed-longan-nano` a bit:
- PA4 is no longer used as default CS for `SPI_DEV(1)`
- At least one DAC channel PA4 is always available if DAC is used.
- PA4 is always available as ADC channel if DAC is not used.
- The order of ADC and DAC channels has been changed accordingly.
This commit includes the following cleanups:
- The macros `I2C_DEV_1_USED` and `SPI_DEV_1_USED` are now used with the values 0 and 1. This allows to enable but also to disable the second interface even if the board definition enables it by default.
- The second I2C device `I2C_DEV(1)` and the second SPI device `SPI_DEV(1)` are now disabled by default.
- The second SPI device `SPI_DEV(1)` now uses PB5 as default CS signal instead of PA4 to keep PA4 free for ADC or DAC even if `SPI_DEV(1)` is used, for example for the TFT display.
This commit introduces a separate board definition based on the `sipeed-longan-nano` board definition for the TFT version of the Sipeed Longan Nano board.
19798: cpu/nrf53: add I2C and SPI support r=benpicco a=dylad
### Contribution description
This PR provides support for nRF53 SPI and I2C.
It also moves common structs from each nRF CPU folder to `cpu/nrf5x_common` to avoid duplication.
Moreover, since nRF9160 and nRF5340 have shared IRQ for UART/SPI/I2C. Both this families now use a common file to register and manage these interrupts. Note that nRF9160 have different name for its interrupts than nRF5340 but they have the same purpose.
### Testing procedure
Since some structs were moved around, I think this PR should be carefully tested against nRF52, nRF53 and nRF9160 to avoid any issues.
On nRF5340DK-APP, SPI can be tested with its onboard SPI flash.
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19806: ztimer/periodic: remove timer on init if already running r=kaspar030 a=benpicco
19814: boards/sipeed-longan-nano: revert default to variant with TFT r=benpicco a=gschorcht
### Contribution description
This PR reverts commit 69fb00bdfa to fix CI compilation.
### Testing procedure
Green CI with full build.
### Issues/PRs references
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19764: drivers/shield_w5100: add module for the W5100 Ethernet Shield r=benpicco a=maribu
### Contribution description
This module provides no more than the correct configuration parameters for the `w5100` driver using the Arduino I/O mapping features. But by doing so, it will work out of the box with every mechanically and electrically compatible board for which the Arduino I/O mapping features are implemented.
19781: cpu/nrf{53,9160}: add pwm support r=benpicco a=dylad
### Contribution description
This PR moves the nRF52 PWM driver to `cpu/nrf5x_common` to allow nRF9160 and nRF53 to use this driver.
IP is identical on these families.
I didn't test on nRF9160DK and I didn't test if there is any regression on nRF52-based board as I don't have any so tests are welcome !
However it works fine on nRF53-based board.
### Testing procedure
Flash the `tests/periph/pwm` test application on `nrf5340dk` or `nrf9160dk`.
You can then use the `osci` command to make the onboard LEDs "breath".
You can also attach an oscilloscope and/or logic analyzer to watch the signal.
### Issues/PRs references
~~Based on #19769~~
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
Without KConfig presence of the TFT is assumed in anycase, with KConfig
it is optional. This turns the opt-in into an opt-out to match behavior
with make by default, fixing the nightly breakage.
19811: boards: add ESP32-S3-Box support r=gschorcht a=gschorcht
### Contribution description
This PR provides the support for the [ESP32-S3-Box](https://github.com/espressif/esp-box).
### Testing procedure
The board has been tested with all basic tests for supported hardware including `tests/drivers/ili9341`:
- [x] tests/drivers/ili9341
- [x] tests/periph/gpio
- [x] tests/periph/i2c
- [x] tests/periph/spi
- [x] tests/periph/uart
- [x] tests/sys/usbus_cdc_ecm
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
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>
19804: cpu/nrf{53,9160}: add periph_rtt support r=benpicco a=dylad
### Contribution description
This PR enables support for `periph_rtt` on both nRF9160 and nRF53.
This PR is based on #19803
I was only able to test on nrf5340dk-app as I don't have access to any nrf9160-based board.
Here is `test/periph/rtt` output for reference on `nrf5340dk-app`:
### Testing procedure
flash `tests/periph/rtt` on `nrf9160dk` or `nrf5340dk-app` and check the results.
```
s
2023-07-06 16:11:16,471 # START
2023-07-06 16:11:16,479 # main(): This is RIOT! (Version: 2023.07-devel-765-g02c65-cpu/nrf53/add_rtt_support)
2023-07-06 16:11:16,480 #
2023-07-06 16:11:16,482 # RIOT RTT low-level driver test
2023-07-06 16:11:16,483 # RTT configuration:
2023-07-06 16:11:16,485 # RTT_MAX_VALUE: 0x00ffffff
2023-07-06 16:11:16,487 # RTT_FREQUENCY: 1024
2023-07-06 16:11:16,487 #
2023-07-06 16:11:16,494 # Testing the tick conversion (with rounding if RTT_FREQUENCY is not power of 2)
2023-07-06 16:11:16,498 # Trying to convert 1 to seconds and back
2023-07-06 16:11:16,501 # Trying to convert 256 to seconds and back
2023-07-06 16:11:16,505 # Trying to convert 65536 to seconds and back
2023-07-06 16:11:16,509 # Trying to convert 16777216 to seconds and back
2023-07-06 16:11:16,514 # Trying to convert 2147483648 to seconds and back
2023-07-06 16:11:16,514 # All ok
2023-07-06 16:11:16,514 #
2023-07-06 16:11:16,517 # Initializing the RTT driver
2023-07-06 16:11:16,835 # This test will now display 'Hello' every 5 seconds
2023-07-06 16:11:16,835 #
2023-07-06 16:11:16,836 # RTT now: 4
2023-07-06 16:11:16,840 # Setting initial alarm to now + 5 s (5124)
2023-07-06 16:11:16,841 # rtt_get_alarm() PASSED
2023-07-06 16:11:16,846 # Done setting up the RTT, wait for many Hellos
2023-07-06 16:11:16,852 # { "threads": [{ "name": "main", "stack_size": 1536, "stack_used": 404 }]}
2023-07-06 16:11:21,833 # Hello
2023-07-06 16:11:26,831 # Hello
2023-07-06 16:11:31,830 # Hello
2023-07-06 16:11:36,828 # Hello
2023-07-06 16:11:41,826 # Hello
2023-07-06 16:11:46,825 # Hello
2023-07-06 16:11:51,823 # Hello
2023-07-06 16:11:56,821 # Hello
2023-07-06 16:12:01,821 # Hello
2023-07-06 16:12:06,819 # Hello
2023-07-06 16:12:11,817 # Hello
2023-07-06 16:12:16,815 # Hello
2023-07-06 16:12:21,813 # Hello
2023-07-06 16:12:26,811 # Hello
```
### Issues/PRs references
based on #19803
19807: boards/esp32s2-lilygo-ttgo-t8: fix display configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the display configuration for the ESP32-S2 LilyGO TTGO T8 (also known as LilyGo T-Display S2) which uses a ST7789 as display 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` (f57b6b70b8). 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.
### Testing procedure
```
BOARD=esp32s2-lilygo-ttgo-t8 make -C tests/drivers/st7735/ flash
```
should work:
### Issues/PRs references
19809: cpu/nrf53: add usbdev support r=benpicco a=dylad
### Contribution description
This PR enables `periph_usbdev` support on nRF5340DK-app board. Since the IP is the same as nRF52, the driver and its related data and structs were moved from `cpu/nrf52` to `cpu/nrf5x_common`
### Testing procedure
Test any USBUS related test application on `nrf5340dk-app`
`CFLAGS='-DSECTOR_COUNT=64' USEMODULE='mtd_emulated' make BOARD=nrf5340dk-app -C tests/sys/usbus_msc flash`
dmesg output:
```
[ 7466.262760] usb 1-2.1: new full-speed USB device number 16 using xhci_hcd
[ 7466.483916] usb 1-2.1: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[ 7466.483925] usb 1-2.1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 7466.483928] usb 1-2.1: Product: nrf5340dk-app
[ 7466.483931] usb 1-2.1: Manufacturer: RIOT-os.org
[ 7466.483933] usb 1-2.1: SerialNumber: AD0FD4AE806080C2
[ 7466.487010] usb-storage 1-2.1:1.0: USB Mass Storage device detected
[ 7466.487348] scsi host2: usb-storage 1-2.1:1.0
[ 7467.516789] scsi 2:0:0:0: Direct-Access RIOT-OS RIOT_MSC_DISK 1.0 PQ: 0 ANSI: 1
[ 7467.517152] sd 2:0:0:0: Attached scsi generic sg3 type 0
[ 7467.517501] sd 2:0:0:0: [sdd] 64 512-byte logical blocks: (32.8 kB/32.0 KiB)
[ 7467.517732] sd 2:0:0:0: [sdd] Write Protect is off
[ 7467.517733] sd 2:0:0:0: [sdd] Mode Sense: 03 00 00 00
[ 7467.517906] sd 2:0:0:0: [sdd] No Caching mode page found
[ 7467.517910] sd 2:0:0:0: [sdd] Assuming drive cache: write through
[ 7467.532159] sd 2:0:0:0: [sdd] Attached SCSI removable disk
```
I also tested `tests/sys/usbus_cdc_ecm` and `tests/sys/usbus/usbus_hid` succesfully.
### Issues/PRs references
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19789: cpu/nrf5x/periph/wdt: enable support for nRF53/nRF9160 r=benpicco a=dylad
### Contribution description
This PR enables support for the watchdog driver on nRF53.
This MCU has two watchdog peripherals, for now, it only uses the first one.
The use of the second watchdog can be add in a followup PR later.
### Testing procedure
Flash and play with `tests/periph/wdt` application.
### Issues/PRs references
None.
19796: boards/b_u585i_ iot02a/periph usbdev r=benpicco a=gschorcht
### Contribution description
This PR adds the USB OTG support for STM32U5 and the `b_u585i_iot02a` board.
This PR includes PR #19795 since it uses directly the changes made in PR #19795.
### Testing procedure
Compile and flash
```
BOARD=b-u585i-iot02a make -C tests/sys/usbus_cdc_ecm/ flash term
```
Use the `sudo dmesg` command to get the kernel messages.
```pyhon
[766948.556645] usb 1-2.2: new full-speed USB device number 108 using xhci_hcd
[766948.658688] usb 1-2.2: New USB device found, idVendor=1209, idProduct=7d00, bcdDevice= 1.00
[766948.658696] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[766948.658699] usb 1-2.2: Product: b-u585i-iot02a
[766948.658702] usb 1-2.2: Manufacturer: RIOT-os.org
[766948.658704] usb 1-2.2: SerialNumber: AA140057DA41D467
[766948.668681] cdc_ether 1-2.2:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-2.2, CDC Ethernet Device, ea:dc:44:71:d9:24
[766948.743250] cdc_ether 1-2.2:1.0 enxeadc4471d924: renamed from usb0
```
Use the `ifconfig` command on the node to determine the IPv6 LLUA and ping the node.
```
ping6 -c 3 fe80::e8dc:44ff:fe71:c524%enxeadc4471d924
PING fe80::e8dc:44ff:fe71:c524%enxeadc4471d924(fe80::e8dc:44ff:fe71:c524%enxeadc4471d924) 56 data bytes
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=1 ttl=64 time=0.523 ms
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=2 ttl=64 time=0.546 ms
64 bytes from fe80::e8dc:44ff:fe71:c524%enxeadc4471d924: icmp_seq=3 ttl=64 time=0.599 ms
```
### Issues/PRs references
Includes PR #19795
19802: cpu/nrf53: enable flashpage support r=benpicco a=dylad
### Contribution description
This PR enables flashpage support on nRF53 family.
The peripheral is identical to nRF52, just add the flashpage configuration and enable the module in both Makefiles.features and Kconfig.
### Testing procedure
run `/tests/periph/flashpage` on `nrf5340dk-app`
output of `make BOARD=nrf5340dk-app flash test`
```
/home/dylan/work/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
Twisted not available, please install it if you want to use pyterm's JSON capabilities
Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
>
>
test_last_raw
> test_last_raw
wrote raw short buffer to last flash page
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_last_pagewise
test_reserved_pagewise Write and verify short write on reserved page
test_last_raw Write and verify raw short write on last page available
> test_last_pagewise
wrote local page buffer to last flash page
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_reserved_pagewise Write and verify short write on reserved page
test_reserved_pagewise
test_last_raw Write and verify raw short write on last page available
> test_reserved_pagewise
Reserved page num: 5
Since the last firmware update this test has been run 0 times
wrote local page buffer to reserved flash page
When running on a bootloader, as an extra check, try restarting the board and check whether this application still comes up.
> help
help
Command Description
---------------------------------------
info Show information about pages
dump Dump the selected page to STDOUT
dump_local Dump the local page buffer to STDOUT
read Copy the given page to the local page buffer and dump to STDOUT
write Write the local page buffer to the given page
write_raw Write (ASCII, max 64B) data to the given address
erase Erase the given page buffer
edit Write bytes to the local page buffer
test Write and verify test pattern
test_last_pagewise Write and verify test pattern on last page available
test_reserved_pagewise Write and verify short write on reserved page
test_last_raw Write and verify raw short write on last page available
>
make : on quitte le répertoire « /home/dylan/work/RIOT/tests/periph/flashpage »
```
### Issues/PRs references
None.
19803: cpu/nrf5x_common: rework LFCLK source selection r=benpicco a=dylad
### Contribution description
This PR changes the source selection of LFCLK for all nRF families.
This idea is to use the values provided by Nordic vendor files to properly populate the source of the LFCLK. Then setup a per CPU check to ensure the value provided at board level is fine. In the end, the LFCLK source selection is a mere assignment.
The selection of the LFCLK source is still done at board level. I also add a bit of documentation to help users to select another value if needed.
I'll provide in a followup PR, `periph_rtt` support for both nRF9160 and nRF53.
### Testing procedure
CI should be enough I think. Otherwise, one can ran tests/periph/rtt on any nRF51-based board and any nRF52-based board.
You can also change the LFCLK source at board level to ensure the guards are doing their jobs.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
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>
The MSP430 vendor files already provide macros containing register
constants and symbols (provided via linker scripts) containing addresses
of peripheral registers. So lets make use of that rather than
maintaining a long list of constants.
19770: cpu/nrf5x_common: reset all available CC channels r=maribu a=dylad
### Contribution description
Properly reset all CC channels of a given timer at initialization (except the last one which seems to be used for capture only in the driver).
The issue with the previous code was that some CCs were not clear on some nRF52 MCUs.
For instance, nRF52840 has 4 CCs for its two first timers, then 6 CCs for all others.
nRF9160 and nRF5340 also have 6 CCs for all its timer peripherals.
Thus, loop through the reported number of channels and clear the associated register instead of hardcoding the first 3 CC channels.
### Testing procedure
CI should be enough I think.
### Issues/PRs references
None.
19773: cpu/nrf{52,9160}: remove duplicate sevonpend bit r=maribu a=dylad
### Contribution description
This PR removes duplicate calls of `SCB_SCR_SEVONPEND` bit in nRF52 and nRF9160.
This call is already done [here](7c320055a1/cpu/cortexm_common/cortexm_init.c (L60))
### Testing procedure
Flash a nRF52 or nRF9160-based board and check that the board is still alive.
### Issues/PRs references
None. I notice this duplicate call when porting nRF53.
19774: boards/frdm-k22f: fixes long lines in periph_conf.h r=maribu a=hugueslarrive
19775: boards/frdm-k64f: fixes long lines and comma separated by whitespaces… r=maribu a=hugueslarrive
… warnings
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
19771: boards/nrf9160dk: use all available CC timer channels r=dylad a=dylad
### Contribution description
`nRF9160` has 6 CC per timer.
You can `grep -ra "CC_NUM" cpu/nrf9160 ` to check it.
So let's use all available CC.
### Testing procedure
You can run `tests/periph/timer` to see the new CC.
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
The correct macro name is `ARDUINO_I2C_UNO` for Arduino UNO compatible
I2C bus location, or `ARDUINO_I2C_NANO` for Arduino Nano compatible
I2C bus location.
Rather than providing this for every board (or group of boards)
individually, it is better to provide this once relying on the Arduino
I/O mapping features.
- 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.
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
19730: boards/qn9080dk: fix periph conflict r=maribu a=maribu
### Contribution description
- Document which I2C/SPI/UART peripheral maps to which FLEXCONN IP block to easily detect potential overlap
- Switch conflict between SPI and I2C peripheral by using a different FLEXCONN for I2C
19731: boards/qn9080dk: update doc on flashing r=maribu a=maribu
### Contribution description
- update the doc on the internal programmer firmware:
- not only switching to J-Link, but also just updating it does improve reliability of flashing
- give hints in how to get the ~~shitty~~ wonderful update process working
- update notes on OpenOCD requirements
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
- update the doc on the internal programmer firmware:
- not only switching to J-Link, but also just updating it does
improve reliability of flashing
- give hints in how to get the ~~shitty~~ wonderful update process
working
- update notes on OpenOCD requirements
- Document which I2C/SPI/UART peripheral maps to which FLEXCONN IP
block to easily detect potential overlap
- Switch conflict between SPI and I2C peripheral by using a different
FLEXCONN for I2C
19717: boards/rpi-pico: update openocd.cfg file r=aabadie a=dylad
### Contribution description
This PR fixes the use of openOCD to flash a rpi-pico board.
Currently on master, trying to flash this board with openOCD (v12) and a CMSIS-DAP probe fails.
with this PR, it now works as expected (even debugging)
Moreover, the configuration file used by RIOT is now deprecated on openOCD v12 so changes it while we're at it.
master:
```
### Flashing Target ###
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swd
Warn : rp2040-core0.cfg configuration file is deprecated and will be
removed in the next release. Use following parameters instead:
-c 'set USE_CORE 0' -f target/rp2040.cfg
Warn : Transport "swd" was already selected
adapter speed: 4000 kHz
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E46170D59B552B2C
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x0bc12477
Error: [rp2040.cpu] Could not find MEM-AP to control the core
Warn : target rp2040.cpu examination failed
Info : starting gdb server for rp2040.cpu on 0
Info : Listening on port 37347 for gdb connections
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* rp2040.cpu cortex_m little rp2040.cpu unknown
Error: [rp2040.cpu] Could not find MEM-AP to control the core
Error: [rp2040.cpu] Debug AP not available, reset NOT asserted!
make: *** [/home/dylan/work/RIOT/examples/blinky/../../Makefile.include:855: flash] Error 1
make: Leaving directory '/home/dylan/work/RIOT/examples/blinky'
```
with this PR:
```
### Flashing Target ###
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swd
Warn : Transport "swd" was already selected
adapter speed: 4000 kHz
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E46170D59B552B2C
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 0
Info : Listening on port 40985 for gdb connections
Info : starting gdb server for rp2040.core1 on 0
Info : Listening on port 39901 for gdb connections
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* rp2040.core0 cortex_m little rp2040.cpu running
1 rp2040.core1 cortex_m little rp2040.cpu running
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes `@0x10000000,` in 32 sectors
Info : Padding image section 2 at 0x10003190 with 112 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x10003200 .. 0x1000ffff
auto erase enabled
wrote 12800 bytes from file /home/dylan/work/RIOT/tests/leds/bin/rpi-pico/tests_leds.elf in 1.516848s (8.241 KiB/s)
verified 12688 bytes in 0.089461s (138.503 KiB/s)
shutdown command invoked
Done flashing
```
### Testing procedure
Flash a `rpi-pico` board using openOCD.
### Issues/PRs references
None.
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
19705: boards/z1: fix broken clock configuration r=maribu a=maribu
### Contribution description
The MSP430F2xx family has on RSEL bit more than the MSP430x1xxx family. The first commit updates the clock calibration accordingly.
df5c319978 from https://github.com/RIOT-OS/RIOT/pull/19558 broke the clock configuration of the Z1 by relying on the incorrect documentation of what clock is actually used. Closely reading the convoluted clock initialization code revealed that no XT2 crystal is present (as also indicated by some comments in `board.c`), contradicting the `#define MSP430_HAS_EXTERNAL_CRYSTAL 1` in the `board.h`.
The second commit should restore behavior (but with calibrated DCO than hard coded magic numbers).
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
df5c319978 from
https://github.com/RIOT-OS/RIOT/pull/19558 broke the clock
configuration of the Z1 by relying on the incorrect documentation of
what clock is actually used. Closely reading the convoluted clock
initialization code revealed that no XT2 crystal is present (as also
indicated by some comments in `board.c`), contradicting the
`#define MSP430_HAS_EXTERNAL_CRYSTAL 1` in the `board.h`.
This now should restore behavior (but with calibrated DCO than
hard coded magic numbers).
The statement about the missing pin 1 marking on the JTAG header is
not correct. It's just a bit hidden between the JTAG header and the
power selector jumper.
This adds the three general purpose timers on STM32L4 boards in a
central place so that STM32L4 boards can just include it.
Some other families may also have TIM15 and TIM16 and could use this,
but likely some generalization is needed to use this for other
families as well. This can be added later on.
19593: boards/msb-430: add documentation r=maribu a=maribu
### Contribution description
This adds basic documentation, schematics, pinouts, and info how to get started with the `msb-430` board.
19597: sys/shell: Add coreclk command to shell_cmd_sys r=maribu a=maribu
### Contribution description
The coreclk shell command now prints the CPU frequency in Hz, which can be useful for boards with RC generated CPU frequency (e.g. RP2040, FE310, or MPS430Fx1xx MCUs allow this) which may quite a bit off the target frequency.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Provide a common clock initialization driver rather than leaving
clock initialization to the boards code. A declarative description of
the board's clock configuration using a struct does still allow to
fine-tune settings. In addition, a board is still allowed to just
provide a custom `void clock_init(void)` if there really is the need
to do crazy things.
19552: tests: move all periph applications to their own periphs/ folder r=gschorcht a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19548: boards/telosb: minor clean ups r=maribu a=maribu
### Contribution description
This cleans up the documentation and the header files of the TelosB board. It is supposed to not changed the generated firmware (except for debug symbols).
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19523: boards/iotlab-m3: enable l3g4200d_ng r=benpicco a=benpicco
19527: drivers/sdcard_spi: small cleanup r=benpicco a=gschorcht
### Contribution description
This PR provides a small cleanup:
- the copy of `sdcard_spi_params_t` is removed (commit bfc2a51f70)
- the documentation was changed to fit the 100 characters per line. (commit 36f0162b34)
It is not necessary to hold a complete copy `sdcard_spi_params_t` in the device descriptor. Constant parameters can be used directly from ROM instead. This saves 24 bytes of RAM.
### Testing procedure
Use any board with SD Card SPI interface. The driver test should still work, for example:
```
BOARD=esp32-wrover-kit make -j8 -C tests/driver_sdcard_spi flash term
```
```
main(): This is RIOT! (Version: 2023.07-devel-176-g7213c-drivers/sdcard_spi_cleanup)
SD-card spi driver test application
insert SD-card and use 'init' command to set card to spi mode
WARNING: using 'write' or 'copy' commands WILL overwrite data on your sd-card and
almost for sure corrupt existing filesystems, partitions and contained data!
> init
Initializing SD-card at SPI_0...
[OK]
>
```
### Issues/PRs references
19530: sys/xtimer: add missing "modules.h" include to `xtimer.h` r=benpicco a=kaspar030
19532: tests/unittests: tests-core-mbox: add missing `container.h` include r=benpicco a=kaspar030
19533: core: move macros/math.h to core/lib/include/macros r=benpicco a=kaspar030
19535: nanocoap_sock: defuse nanocoap_sock_get() API footgun r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
19526: boards/arduino-mkrwan1300: update board name to correct one r=aabadie a=FlapKap
Co-authored-by: Kasper Hjort Berthelsen <kasper.berthelsen@hotmail.com>
19516: cpu/rpx0xx: add initial ADC support r=dylad a=dylad
### Contribution description
This PR adds initial support for RP2040 ADC peripheral.
It is rather minimalist, and only use oneshot trigger to perform a single acquisition.
I've tested this PR using a potentiometer connected between GND and 3V3.
GP26, GP27, GP28 has been tested.
### Testing procedure
Select `ADC_RES_12BIT` and flash `tests/periph_adc`
`make BOARD=rpi-pico -C tests/periph_adc`
### Issues/PRs references
None.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
19447: boards/nucleo-f429zi: Provide 2nd timer r=benpicco a=maribu
### Contribution description
- Add a common timer config with two (instead of only one) timer using TIM2 + TIM5
- Mostly copy-pasting the cfg_timer_tim2.h and cfg_timer_tim5.h together
- Make use of that for the `nucleo-f429zi`
### Testing procedure
E.g. `tests/periph_timer`, but also grepping for TIM2 and TIM5 in `boards/nucleo-f429zi/include/periph_conf.h` to detect any conflict e.g. between PWM and timer config.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19432: boards/esp32: deduplication in common ESP32x board definitions r=benpicco a=gschorcht
### Contribution description
The PR reduced code duplication in `boards/common/esp32*`.
The PR moves the header files from `boards/common/esp32s3/include` that can be used for all types of ESP32x SoCs to a new common ESP32x board definition which is then included by all common ESP32x board definitions.
### Testing procedure
Green CI.
### Issues/PRs references
19461: drivers/enc28j60: fix ISR routine and bth r=benpicco a=peteut
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alain Péteut <alain.peteut@yahoo.com>
The board uses the USB OTG HS peripheral together with the on-hip FS PHY. Using the `periph_usbdev_hs` module increases the EP data size for the CDC ECM bulk endpoint to 512 bytes, which does not work for the FS interface. Module `periph_usbdev_hs` is therefore not used.
19417: boards/esp32c3-wemos-mini: add support for Wemos ESP32-C3 mini r=benpicco a=gschorcht
### Contribution description
This PR provides the support for the [Wemos ESP32-C3 mini](https://www.wemos.cc/en/latest/c3/c3_mini.html) board.
### Testing procedure
The board should work for provided features.
The board was already tested with:
- [x] `tests/driver_sht3x` using I2C
- [x] `tests/driver_l3gxxxx` using SPI
- [x] `tests/periph_adc`
- [x] `tests/periph_pwm`
- [ ] `tests/driver_ws281x`
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The commit moves the header files from `boards/common/esp32s3/include` that can be used for all types of ESP32x SoCs to a new common ESP32x board module.
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.
19410: boards/common/gd32v: improve openocd config r=benpicco a=gschorcht
### Contribution description
This PR improves the OpenOCD config for GD32V.
To restart GD32V after flashing, a special magic procedure has to be used. For short:
```python
halt
gd32vf103.cpu mww 0xe004200c 0x4b5a6978 # unlock 0xe0042008, the next write triggers a reset
riscv set_mem_access abstract # set abstract memory access
gd32vf103.cpu mww 0xe0042008 0x1 # write to 0xe0042008 to triggers a reset
riscv set_mem_access progbuf # set memory access mode back
resume
```
The final `resume` was missing so that a timeout with an error message happened after flashing, for example:
```python
wrote 14692 bytes from file tests/shell/bin/sipeed-longan-nano/tests_shell.elf in 1.845550s (7.774 KiB/s)
verified 14692 bytes in 0.071006s (202.063 KiB/s)
Info : JTAG tap: gd32vf103.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing) Inc), part: 0x9000, ver: 0x7)
Error: Timed out after 2s waiting for busy to go low (abstractcs=0x2001004). Increase the timeout with riscv set_command_timeout_sec.
Warn : Failed to write memory via abstract access.
Error: Target gd32vf103.cpu: Failed to write memory (addr=0xe0042008)
Error: progbuf=disabled, sysbus=disabled, abstract=failed
Error executing event reset-assert on target gd32vf103.cpu:
embedded:startup.tcl:1187: Error:
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 1187
shutdown command invoked
Done flashing
```
With the final `resume`, still an error message happens that hart 0 is unavialable, but the timeout with all these errors do not occur and OpenOCD exits immediatly:
```python
wrote 14732 bytes from file /home/gs/src/RIOT-Xtensa-ESP.esp-idf-4.4/tests/shell/bin/sipeed-longan-nano/tests_shell.elf in 1.516376s (9.488 KiB/s)
verified 14732 bytes in 0.045381s (317.021 KiB/s)
Info : JTAG tap: gd32vf103.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing) Inc), part: 0x9000, ver: 0x7)
Error: Hart 0 is unavailable.
Info : Hart 0 unexpectedly reset!
shutdown command invoked
Done flashing
```
### Testing procedure
Flash any GD32V board with and without this PR and observe the output.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19408: boards/esp32: enable RGB LED support r=benpicco a=gschorcht
### Contribution description
A couple of ESP32x boards have a SK68XXMINI-HS RGB LED on board.
- `esp32c3-devkit`
- `esp32s2-devkit`
- `esp32s3-devkit`
This RGB LED can be used with the driver module `ws2812x`. This PR adds the `WS2812X_PARAMS*` parameter definitions to the board definition and updates the documentation.
### Testing procedure
Use any of these boards to flash `tests/driver_ws2812x`, for example:
```
BOARD=esp32c3-devkit make -j8 -C tests/driver_ws281x/ flash
```
The RGB LED should work as expected.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19357: boards/adafruit-itsybitsy-m4: turn off APA102 LED on startup r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
19375: tools/renode: add support for target reset r=benpicco a=aabadie
19376: boards/stm32f4discovery: use default port to access stdio via cdc acm r=benpicco a=aabadie
19377: pkg/tinyusb: fix default VID/PID configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the default VID/PID configuration if tinyUSB board reset feature is used.
While reviewing PR #19086 I was wondering why `esp32s2-wemos-mini` requires to set `USB_VID`/`USB_PID` explicitly to `USB_VID_TESTING`/`USB_PID_TESTING`. The reason was that tinyUSB board reset feature wasn't declared as RIOT internal.
### Testing procedure
Flashing `esp32s2-wemos-mini` should still work.
```
BOARD=esp32s2-wemos-mini make -C tests/shell flash
```
The VID/PID should be `1209:7d00` and not `1209:7d01`.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19358: sys/usbus/cdc/ecm: fix High-Speed mode r=dylad a=gschorcht
### Contribution description
This PR provides some changes to fix the USBUS CDC ECM interface in High-Speed mode.
In High-Speed mode, the EP data size has to be at least 512 bytes instead of 64 Byte in Full-Speed mode. To be able to define configurations like EP data sizes depending on whether Full-Speed or High-Speed USB device peripherals are used, the feature `periph_usbdev_hs`/`HAD_PERIPH_USBDEV_HS` is introduced.
### Testing procedure
Use `tests/usbus_cdc_ecm` and any board with USB HS connector, for example:
```
USEMODULE=periph_usbdev_hs_utmi BOARD=stm32f723e-disco make -j8 -C tests/usbus_cdc_ecm flash
```
`ping` command works with this PR but doesn't work without this PR.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
A custom rainbow boot-up animation/delay gets old pretty quick
and we didn't actually init the LEDs anyway, so it would not be shown.
Drop the custom led_init() so the generic led_init() kicks in
and properly initializes the LEDs.
18682: pkg/lwext4: add lightweight implementation of the ext2/3/4 filesystem r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Boards with an integrated debugger/programmer that also provides the
serial as UART <--> USB adapter, the TTY serial matches the serial of
the programmer.
This adapts the `serial.inc.mk` to set the `DEBUG_ADAPTER_ID` to the
TTY serial if (and only if) `MOST_RECENT_PORT` *and*
`DEBUG_ADAPTER_ID_IS_TTY_SERIAL` both have a value of `1`. Boards with
an integrated programmer are expected to set
`DEBUG_ADAPTER_ID_IS_TTY_SERIAL` to `1` in their `Makefile.include`.
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>
19261: tests/{sys_fido2_ctap/usbus_board_reset}: fix stdio_usb_serial_jtag dependency r=gschorcht a=gschorcht
### Contribution description
This PR fixes the `stdio_usb_serial_jtag` dependency problem for `tests/sys_fido2_ctap` and `usbus_board_reset`.
- There are boards that select the STDIO backend used depending on whether `usbus` is enabled. Usually the `fido2_ctap_transport_hid` module pulls in `usbus_hid` and thus `usbus`, but since this dependency resolution is done after reading the `Makefile.dep` of the board, it may happen that the wrong STDIO backend is selected. Therefore `usbus` is selected directly in the `Makefile` of `tests/sys_fido2_ctap` .
- To improve the selection of the `stdio_usb_serial_jtag` backend in `esp32s3-pros3`, it checks for any `usbus_%` module not only `usbus`.
### Testing procedure
GreenCI
### Issues/PRs references
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>
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>
19088: boards: add esp32s3-pros3 support r=benpicco a=gschorcht
### Contribution description
This PR provides the support for [ESP32 ProS3](https://esp32s3.com/pros3.html#home) board from Unexpected Maker.
This board doesn't have a USB-to-Serial chip on board. Therefore, USB Serial/JTAG is used for STDIO and the board is flashed via the USB Seral/JTAG interface by default.
### Testing procedure
Flashing `tests/shell` should work.
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
After a reset, it can take several seconds before the CDC ACM interface becomes available as serial device `ttyACMx`. This was a change that was already made for `stdio_cdc_acm` in #19128.
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.
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.
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.
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>
The default timer configuration has been changed so that `TIMER0` and `TIMER1` are always timer devices. `TIMER2` can only be used as timer device if it is not used for PWM devices. `TIMER3` and `TIMER4` are only available as timer devices if they are supported by the CPU model and not used for PWM devices.
19199: sys/suit: Ensure previous thread is stopped before reusing its stack r=benpicco a=chrysn
### Contribution description
Closes: https://github.com/RIOT-OS/RIOT/issues/19195
If the thread has released the mutex but the thread has not terminated (which happens in the situation that would previously have overwritten a still active thread's state), then a warning is shown and the trigger is ignored.
### Testing procedure
This should work before and after:
* `make -C examples/suit_update BOARD=native all term`
* `aiocoap-client coap://'[fe80::3c63:beff:fe85:ca96%tapbr0]'/suit/trigger -m POST --payload 'coap://[2001:db8::]/foo'`
* In parallel, on the RIOT shell, run `suit fetch coap://[2001:db8::]/foo`
* After the first download fails, the second one starts right away ("suit_worker: update failed, hdr invalid" / "suit_worker: started").
Run again with the worker thread on low priority:
```patch
diff --git a/sys/suit/transport/worker.c b/sys/suit/transport/worker.c
index a54022fb28..e26701a64c 100644
--- a/sys/suit/transport/worker.c
+++ b/sys/suit/transport/worker.c
`@@` -70 +70 `@@`
-#define SUIT_COAP_WORKER_PRIO THREAD_PRIORITY_MAIN - 1
+#define SUIT_COAP_WORKER_PRIO THREAD_PRIORITY_MAIN + 1
```
Before, this runs the download once silently (no clue why it doesn't run it twice, but then again, I claim there's concurrent memory access from two thread, so who knows what happens). After, it runs a single download and shows an error message for the second one once the first is complete ("Ignoring SUIT trigger: worker is still busy.").
### Issues/PRs references
This may be made incrementally easier by https://github.com/RIOT-OS/RIOT/pull/19197 -- that PR as it is now would spare us the zombification (because returning would do that), and having a `wait` function would allow us to turn the new error case into a success.
19205: boards/common: add common timer config for GD32VF103 boards r=benpicco a=benpicco
19207: examples/gnrc_border_router: static: use router from advertisements by default r=benpicco a=benpicco
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
19202: cpu/gd32v: add periph_rtt support r=benpicco a=gschorcht
### Contribution description
This PR provides the `periph_rtt` support and is one of a bunch of PRs that complete the peripheral drivers for GD32VF103.
### Testing procedure
`tests/periph_rtt` should work and give the following results:
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.04-devel-199-g2d429-cpu/gd32v/periph_rtt)
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
This test will now display 'Hello' every 5 seconds
RTT now: 148
Setting initial alarm to now + 5 s (163988)
rtt_get_alarm() PASSED
Done setting up the RTT, wait for many Hellos
{ "threads": [{ "name": "idle", "stack_size": 256, "stack_used": 216 }]}
{ "threads": [{ "name": "main", "stack_size": 1280, "stack_used": 480 }]}
Hello
Hello
Hello
Hello
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19204: boards/sipeed-longan-nano: default to flashing via DFU r=gschorcht a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
19170: boards/sipeed-longan-nano: add definition for the Sipeed Longan Nano GD32VF103 board r=benpicco a=gschorcht
### Contribution description
This PR add the support for the [Sipeed Longan Nano](https://longan.sipeed.com/en) board, a GD32VF103 development board with the GigaDevice GD32VF103CBT8 RISC-V MCU. This includes moving the common board definitions for GDV32F103 boards from `boards/seeedstudio-gd32` to `boards/common/gd32v`.
**[Update]** At first glance, the existing peripheral definition for `seeedstudio-gd32` seems to fit exactly for `sipeed-longan-nano`. But at second glance it becomes clear that `seeedstudio-gd32` which is using the GD32VF103VBT6 instead of the GD32VF103CBT6 has more peripherals and much more peripheral pins are broken out. This allows a more extensive and flexible peripheral definition (more timers, more ADC pins, more UART interfaces, ...). So it doesn't seem to be a good idea to share the peripheral definitions between these boards.
This PR depends on PR #19166 and includes this PR for the moment.
### Testing procedure
t.b.d.
### Issues/PRs references
Depends on PR #19166
19190: pkg/wolfssl: Fix memory leaks in wolfSSL sock_tls r=benpicco a=Flole998
When sk->ssl is NULL it doesn't need to be free()d, otherwise it may be free()d
19191: Fix SX126X-STM32WL module in Kconfig r=MrKevinWeiss a=MrKevinWeiss
### Contribution description
Master is broken due to kconfig mismatch for the `nucleo-wl55jc`. The radio was just not declared.
This fixes the board and cleans up some of the SX126X kconfig.
### Testing procedure
Murdock should pass
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Flole998 <Flole998@users.noreply.github.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
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>
19166: boards/seeedstudio-gd32: complete and improve board definition r=kaspar030 a=gschorcht
### Contribution description
This PR completes and improves the board definition for the Seeedstudio GD32 RISC-V Dev board. It
- adds the user LED and Button definitions to `board.h` (bef4209109)
- adds the SAUL support for user LED and Button definitions (7a5b2f1fb43f5e28eec4f65c8e7367510be6eb80)
- changes the OpenOCD configuration (32c0c4b1b5b9705ffcd2bb02a1d868ad35ca3bbc)
- to be usable with Upstream OpenOCD release version 0.12.0
- to allow different FTDI configuration and other adapters
- adds a documentation with flashing guide, feature list, support status, pinout, schematic reference (9dcc83b8ceb8a9ce526f0a03053a242e866ebf4a)
These changes is the first PR for a number of follow-up PR I will provide in next days to extend the GD32VF103 support. I have already working
- `periph_adc` support,
- `periph_spi` support,
- `tinyusb_device` support,
and almost finished
- `periph_i2c` support (implemented and working with some errors),
- `pm_layered` support (implemented but not working correctly yet), and
- `periph_usbdev` support (implemented by extending `usbdev_synopsys_dwc2 driver but bot working yet).
I will try to implement
- `periph_gpio_irq` support,
- `periph_rtc` support, and
- `periph_rtt` support.
Since I'm using the Sispeed Longan Nano board for testing, I will add the board definition for this board. I will then move some board definitions to a common folder.
### Testing procedure
Green CI.
Documentation should be generated correctly.
Flashing the `seeedstudio-gd32` should still work.
`tests/leds` should work.
### Issues/PRs references
19171: tests/gnrc_rpl: Disable CI test for native r=benpicco a=maribu
### Contribution description
This disables the `tests/grnc_rpl` test run for `native`. This test is too flaky to be included in the CI.
### Testing procedure
Not needed
### Issues/PRs references
None
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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>
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>
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.
- 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.
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`).
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>
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
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.
The TMP006 driver has been renamed to TMP00x, as it (now) supports both
TMP006 and TMP007 infrared thermopile sensors. However, the board
configuration was never updated to match the new names. This fixes the
issue.
19014: boards/qn9080dk: add TTY_BOARD_FILTER r=kaspar030 a=maribu
### Contribution description
With `MOST_RECENT_PORT=1` the TTY interface of the most recently connected board with an embedded NXP debugger is selected. If only a single board with an embedded NXP debugger is selected, this will automatically connect to the correct board using:
```
make term MOST_RECENT_PORT=1
```
### Testing procedure
Run `make term MOST_RECENT_PORT=1` with a qn9080dk board and some non-NXP boards attached. It should reliably select the qn9080dk regardless of TTY names and order they were connected.
### Issues/PRs references
None
19094: dist/tools/doccheck: Reduce noise r=benpicco a=maribu
### Contribution description
This adds central documentation of driver initialization parameters in `driver/foo/include/foo_params.h` where missing for drivers used by the Hamilton board. In addition, the macros to overwrite the default parameters are no longer expected to be documented by adding generic exclude patterns. The reasoning is that having the macros documented once is sufficient.
### Testing procedure
Static tests should pass
### Issues/PRs references
Required to get https://github.com/RIOT-OS/RIOT/pull/19090 in
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
17919: board/microbit: increase testtimeout for emulated testing r=benpicco a=kfessel
### Contribution description
this increases the timeout for tests run by murdock on emulated microbit (accounting for startup of qemu)
### Testing procedure
murdock
### Issues/PRs references
#17894
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19037: sys/usb, pkg/tinyusb: move USB board reset from highlevel STDIO to CDC ACM r=dylad a=gschorcht
### Contribution description
The USB board reset function `usb_board_reset_coding_cb` can be used on any CDC-ACM interface, even if the CDC ACM interface is not used as high-level STDIO. Therefore, this PR provides the following changes:
- The call of the board reset function `usb_board_reset_coding_cb` from USBUS stack has been moved from the STDIO CDC ACM implementation to the CDC ACM implementation and is thus a feature of any USBUS CDC ACM interface which does not necessarily have to be used as highlevel STDIO.
- The call of the board reset function `usb_board_reset_coding_cb` from tinyUSB stack been moved from module `tinyusb_stdio_cdc_acm` to module `tinyusb_contrib` and is compiled in if the `tinyusb_class_cdc` module is used together the `tinyusb_device` module. Thus, it is now a feature of the tinyUSB CDC ACM interface, which does not necessarily have to be used as highlevel STDIO.
- The `usb_board_reset` module defines the `usb_board_reset_in_bootloader` function as a weak symbol to be used when reset in bootloader if no real implementation of this function is compiled in and the `riotboot_reset` module is not used. It only prints an error message that the reset in bootloader is not supported. This is necessary if the module `usb_board_reset` is used to be able to restart the board with an application via a USB CDC ACM interface, but the board's bootloader does not support the reset in bootloader feature.
- A test application has been added that either uses the highlevel STDIO `stdio_acm_cdc` or creates a CDC-ACM interface to enable board resets via USB. If the `usbus_dfu` module is used, it also initializes the DFU interface to be able to work together with the `riotboot_dfu` bootloader.
### Testing procedure
1. Use a board with a bootloader that supports the reset in bootloader via USB, but don't use the highlevel STDIO to check that it works with `usbus_cdc_acm`, for example:
```python
USEMODULE=stdio_uart BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
After reset in application with command
```python
stty -F /dev/ttyACM0 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with RIOT's test VID/PID:
```python
dmesg
[1745182.057403] usb 1-4.1.2: new full-speed USB device number 69 using xhci_hcd
[1745182.160386] usb 1-4.1.2: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
[1745182.160390] usb 1-4.1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[1745182.160392] usb 1-4.1.2: Product: arduino-mkr1000
[1745182.160393] usb 1-4.1.2: Manufacturer: RIOT-os.org
[1745182.160395] usb 1-4.1.2: SerialNumber: 6B6C2CA5229020D8
[1745182.170982] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
After reset in bootloader with command
```python
stty -F /dev/ttyACM0 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
command `dmesg` should give an output like the following with vendor VID/PID:
```python
[1746220.443792] usb 1-4.1.2: new full-speed USB device number 70 using xhci_hcd
[1746220.544705] usb 1-4.1.2: New USB device found, idVendor=2341, idProduct=024e, bcdDevice= 2.00
[1746220.544708] usb 1-4.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1746220.553471] cdc_acm 1-4.1.2:1.0: ttyACM0: USB ACM device
```
2. Test the same as in 1., but this time use the highlevel STDIO to check that there is no regression and it still works with `stdio_cdc_acm`, for example:
```python
BOARD=arduino-mkr1000 make -C tests/usb_board_reset flash
```
3. Use a board that supports `riotboot_dfu` but doesn't use the highlevel STDIO and flash the `riotboot_dfu` bootloader, for example:
```python
BOARD=stm32f429i-disc1 make -C bootloaders/riotboot_dfu flash term
```
Once the bootloader is flashed, command `dfu-util --list` should give something like the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="6591620BCB270283"
Found DFU: [1209:7d02] ver=0100, devnum=14, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="6591620BCB270283"
```
If the output gives only
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
an application is already running in DFU Runtime mode. Use `dfu-util -e` to restart it in bootloader DFU mode.
Then flash the test application, for example:
```python
FEATURES_REQUIRED=riotboot USEMODULE='usbus_dfu riotboot_reset' \
BOARD=stm32f429i-disc1 make -C tests/usbus_board_reset PROGRAMMER=dfu-util riotboot/flash-slot0
```
Once the test application is flashed, command `dfu-util --list` should give:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
Now, use command
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in application. Command `dfu-util --list` should give again the following:
```python
Found Runtime: [1209:7d00] ver=0100, devnum=123, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS bootloader", serial="6591620BCB270283"
```
That is, the application is running in DFU Runtime mode. Then use command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
to restart the board in bootloader DFU mode. Command `dfu-util --list` should now give the following:
```python
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=1, name="RIOT-OS Slot 1", serial="7D156425A950A8EB"
Found DFU: [1209:7d02] ver=0100, devnum=50, cfg=1, intf=0, path="1-2", alt=0, name="RIOT-OS Slot 0", serial="7D156425A950A8EB"
```
That is, the bootloader is in DFU mode and another application can be flash.
4. After a hard reset of the board under 3., try the commands `reboot` and `bootloader`.
5. To check the same for tinyUSB, use the existing tinyUSB application with a CDC ACM interface and add module `usb_board_reset`, for example:
```python
USEMODULE=usb_board_reset BOARD=stm32f429i-disc1 make -C tests/pkg_tinyusb_cdc_msc flash term
```
After flashing, it should be possible to restart the application with command:
```python
stty -F /dev/ttyACM1 raw ispeed 600 ospeed 600 cs8 -cstopb ignpar eol 255 eof 255
```
When using command
```python
stty -F /dev/ttyACM1 raw ispeed 1200 ospeed 1200 cs8 -cstopb ignpar eol 255 eof 255
```
the following error message should be shown in terminal
```python
[cdc-acm] reset in bootloader is not supported
```
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18756: drivers/usbdev_synopsys_dwc2: add EFM32 support r=chrysn a=gschorcht
### Contribution description
This PR provides the changes for the Synopsys USB OTG IP core DWC2 driver for EFM32 MCUs. It also provides the changes of the board definition for `stk3600` and `stk3700` for testing.
### Testing procedure
`tests/usbus_hid` should work on the EFM32 boards `stk3600` (EFM32LG family) and `stk3700` (EFM32GG family).
It is already tested for a `sltb009a` board (EFM32GG12 family).
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19023: pkg/tinyusb: fix Kconfig problems r=maribu a=gschorcht
### Contribution description
This PR tries to fix the [problems with `tinyUSB` in nightlies](https://ci.riot-os.org/details/d11b383ba0cd45048ed6f8d98abbc0de).
- The `tinyusb_device` feature had to be moved from `boards/common/arduino-zero` definition to the `boards/arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
- The `tinyusb_device` feature had to be removed from Kconfig of board `stm32f429i-disco` since it uses the `highlevel_stdio` feature via the `stdio_cdc_acm` module.
### Testing procedure
Green CI
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19012: boards/arduino-mega2560: add TTY_BOARD_FILTER r=gschorcht a=maribu
### Contribution description
This allows automatically selecting TTY actually belonging to an
Arduino Mega2560 if `MOST_RECENT_PORT=1` is set.
### Testing procedure
```
make BOARD=arduino-mega2560 MOST_RECENT_PORT=1 -C examples/default flash term
```
Should automatically select the TTY of the most recently connected Arduino Mega2560, even if a board of a different type is connect more recently.
### Issues/PRs references
- [x] depends on (and includes) https://github.com/RIOT-OS/RIOT/pull/19011
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This allows automatically selecting TTY actually belonging to an
Arduino Mega2560 if `MOST_RECENT_PORT=1` is set.
Note: Unless `ARDUINO_MEGA2560_COMPAT_WITH_CLONES` is set to `0`,
this will fall back to detecting any cheap USB UART bridge typically
found in Arduino Mega 2560 clones if no genuine Arduino Mega is found.
