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>
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>
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
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`.
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>
The `tinyusb_device` feature introduced with PR #18689 has to be moved from `common/arduino-zero` definition to the `arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses `highlevel_stdio` feature via the `stdio_cdc_acm` module.
weact-f4xcx boards have only a single USB-C connector that is used for `highlevel_stdio` via USBUS CDC ACM so that it conflicts with tinyUSB for the moment.
The `channels` member should not be set to the number of hardware
channels *n*, but to *n* - 1 instead. The last channel is implicitly
used in `timer_read()`. Hence out of *n* hardware channels, only *n* - 1
are available to the application.
This fixes a bug introduced by 4d02e15247
which incorrectly set the channel number to *n* rather than to
*n* - 1.
- All nRF52 timers support 32 bit mode, so use that
- All nRF52 timers support at least 4 channels, the timers NRF_TIMER3
and NRF_TIMER4 even support 6 channels.
- Add a warning that `TIMER_DEV(1)` is used by the IEEE 802.15.4 driver
The peripheral configuration has been completely reworked to resolve
pin conflicts while provided as much of the peripherals as possible.
The changes include:
- Move `I2C_DEV(0)` from PB6/PB7 to PB8/PB9 to solve pin conflict with
`QDEC_DEV(2)`.
- Use pins PB0, PB1, PB4, and PB5 for PWM instead PA8, PA9, PA10, and
PA11
- PA9 and PA10 is in pin conflict with `UART_DEV(0)` which is used
for stdio with `stdio_uart`, PA8 was in conflict with
`QDEC_DEV(0)`, PA11 was in conflict with USB D-
- Use PB6, PB7 as `QDEC_DEV(0)` (previously `QDEC_DEV(2)`), as this is
the only completely conflict free setting
- Use PB4/PB5 instead of PA6/PA7 for QDEC_DEV(1)
- This fixes a pin conflict with `SPI_DEV(0)` MISO (and
`ADC_LINE(4)`)
- Only provide QDEC at PB4/PB5 when PWM is not used to avoid conflict
- Only provide QDEC at PA8/PA9 when UART is not used to avoid conflict
- Use SPI2 (PB15, PB14, PB13, PB12) as `SPI_DEV(0)` instead of SPI1,
use SPI1 (PA7, PA6, PA5, PA4) as `SPI_DEV(1)`
- Only provide `SPI_DEV(1)` if the ADC is not in used to resolve a
pin conflict
- Move PB0 and PB1 at the end of the ADC lines (previously
`ADC_LINE(6)` and `ADC_LINE(7)`, now `ADC_LINE(8)` and `ADC_LINE(9)`)
- Only provide them when PWM is not in use (to resolve pin conflict
with PWM)
- Also do not provide them for the Blackpill boards, which are
missing pins PB0 and PB1 on the headers
To make life of users easier, a Pinout diagram with the new
configuration was added.
The `fs` in the file name means that on-chip FS PHY is configured for USB OTG HS. The file is renamed to `cfg_usb_otg_hs_phy_fs.h`
- to clarify that USB OTG HS is just configured with PHY FS and not HS and FS,
- to allow a configuration of USB OTG FS and HS in one file called `cfg_usb_otg_hs_fs.h` or whatever, and
- to allow a configuration of USB OTG HS with ULPI PHY in a file called `cfg_usb_otg_hs_phy_ulpi.h`.
f
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
The inverted and non-inverted `LED<num>_ON` and `LED<num>_OFF` macros
are swapped. This didn't reveal in testing as the
`LED<num>_IS_INVERTED` macros where not properly evaluated, due to a
typo in the check. This fixes both.
Using `UART_DEV(0)` (UASRT1) for stdio allows to use the same TTL
adapter that is used for programming via `stm32flash` to be used for
serial, without re-wiring after flashing.
Let boards only define the port and pin number of each LEDs. The common
definitions in `stm32_leds.h` will provide `LED<x>_ON`, `LED<x>_OFF`,
`LED<x>_TOGGLE`, `LED<x>_PIN`, `LED<x>_MASK` and `LED<x>_PORT`.
In addition to code de-duplication, this also makes it easier to use
LEDs in GPIO LL, which can be beneficial for super low overhead
debugging output - e.g. when a bug is timing sensitive and `DEBUG()`
would spent to much time for stdio to reproduce a bug.
Only default to uniflash as default programmer if UNIFLASH_PATH is
set. If this isn't the case, `make flash` fails complaining about
missing `UNIFLASH_PATH` anyway.
