When `OPENOCD_DEBUG_ADAPTER` was set to `stlink`, no `openocd.cfg`
was needed for most STM32 boards. (But one could still be provided if
special handling was needed.) However, for any other debug adapter this
was not the case.
This moves the handling for when no custom `openocd.cfg` is provided from
the `stlink.inc.mk` to `openocd.inc.mk`, so that most boards now work
out of the box with other debuggers.
Co-authored-by: crasbe <crasbe@gmail.com>
This avoids inconsistent output when external code gets linked in that
directly links against newlib's assert implementation (e.g. binary blobs
or packages that do not add `core/lib/include` to the include paths).
This also greatly benefits wrapping printf, as newlib's `__assert_func()`
directly links to internal printf functions of newlib.
Co-authored-by: crasbe <crasbe@gmail.com>
This makes use of the new bug modeling to declare all platforms that
can use newlib and have no reentrancy hooks as affected by the
non-thread-safe stdio bug. (Which is every platform but ESP* and AVR,
the former because the reentrancy hooks are provided, the latter because
we do not and never will support newlib on them.)
Building on that, the mpaland-printf package is used when newlib is
used and the bug is present. This way we can rely on the stdio being
thread-safe on every platform and not causing random crashes at run
time.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
If we only have access the the public key, we don't want it to be
accidentally overwritten by the build system.
Intrudce a new `SUIT_GEN_PUBKEY` that defaults to 1, but can be set
to 0 to disable auto-generating the public key from the private key
(and generating a new private/public key pair if the private key does
not exist).
The cleanup includes the following changes:
- The `esptool.py` is no longer installed as a RIOT package, but as a pure Python package, as published by Espressif. The installation takes place in a virtual Python environment in the `dist/tools/esptools/venv` directory.
- The installation of the `esptool.py` is now version-sensitive.
- The `esptool.py` from the Python package is always used.
- The option for users to use a custom `esptool.py` has been removed because newer versions of `esptool.py` use renamed options that are not compatible with older versions of `esptool.py`. Using a custom `esptool.py` therefore makes no sense.
It makes no sense to have a separate `esp_ble_$(CPU_FAM)` feature for each ESP32x variant. The ESP32x has either a BLE controller or not. Therefore, a single common `esp_ble` feature is sufficient.
`esptool.py` is now used as a package within a virtual Python environment. Since `esptool.py` is used for compilation on the one hand and for flashing on the other, `esptool.py` is installed in two separate virtual Python environments, one for compilation and one for flashing only. This is required
1. to be able to flash a precompiled application only without compiling the package and
2. to be able to compile an application in RIOT Docker and flash it on the host system.
This adds a default `TTY_BOARD_FILTER` for use with the Tigard debugger,
so that when the programmer is a Tigard that tigard is also used by
default for the serial connection.
In addition, this allows selecting the TTY via the programmer serial
number.
Co-authored-by: crasbe <crasbe@gmail.com>
Add a uard around macro BTN0_PIN definition to allow the user to redefine
it in order to use the SPI module.
Add a guard around SAUL parameters that use BTN0_PIN to avoid error when
it is redefined.
The Adafruit Clue and Itsybitsy nRF52 also use the Adafruit nRF52
Bootloader which has a common module that can be used.
Especially the Itsybitsy nRF52 (mis)uses the nrfutil programmer
target and has a lot of redundant code.
Furthermore, the Double Tap Magic Value used by both boards
is incorrect for using the USB Bootloader.
