`CONFIG_BOARD_HAS_HXTAL` is used to indicate that the board has an HXTAL connected. If the HXTAL is present, it is used as PLL clock source. But if the HXTAL is not present, the half IRC8M clock should be used as PLL clock source and must not be disabled at the end of clock settings. Using IRC8M clock as PLL clock source also requires another PLL multiplication factor.
`CLOCK_HXTAL` is a value and not a flag, so that shifting to the left changes anything in the register but does not set the PLLSEL bit. `RCU_CFG0_PLLSEL_Msk` has to be used instead to set the PLLSEL bit.
Setting the `RCU_CTL` register just to the IRC8M bit also removes the IRC8M calibration and trim adjust value in this register. Therefore IRC8M calibration and trim adjust value have to be preserved and the IRC8M has to be set.
19106: core/lib: Add macros/utils.h header r=aabadie a=maribu
### Contribution description
The macros CONCAT(), MIN(), and MAX() are defined over and over again in RIOT's code base. This de-duplicates the code by moving the macros to a common place.
### Testing procedure
Generated binaries don't change, as this only a de-duplication of macros that doesn't change their definition.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
18752: nanocoap_sock: deprecate nanocoap_get() r=benpicco a=benpicco
19100: cpu/esp_common: allow configuration of UART0 r=benpicco a=gschorcht
### Contribution description
This PR
- fixes the issue for ESP32 SoCs that UART0 signals can't be routed to arbitrary GPIOs and
- allows the configuration of the UART device used by the bootloader.
The UART interface and its configuration used by the STDIO are defined in RIOT using the define `STDIO_UART_DEV` and the configuration of the corresponding UART device in `periph_conf.h`.
However, the bootloader compiled directly in ESP-IDF uses its own definitions `CONFIG_ESP_CONSOLE_UART_*` for the UART configuration. To be able to use a consistent UART configuration in RIOT and the bootloader, e.g. to see the output of the 2nd stage bootloader, these `CONFIG_ESP_CONSOLE_UART_*` can be defined via a set of KConfig variables in RIOT (not yet implemented in Kconfig):
- `CONSOLE_CONFIG_UART_NUM` defines the UART device to be used by the bootloader and by `STDIO_UART_DEV`
- `CONSOLE_CONFIG_UART_RX` and `CONSOLE_CONFIG_UART_TX` define the GPIOs to be used by the bootloader and should be the GPIOs as defined in `periph_conf.h` for the corresponding UART device.
### Testing procedure
Any ESP32 node should still work with `stdio_uart` and the default configuration. To test an alternative configuration, use
```
CFLAGS='-DUART1_TXD=5 -DUART1_RXD=4 -DCONFIG_CONSOLE_UART_NUM=1 -DCONFIG_CONSOLE_UART_TX=5 -DCONFIG_CONSOLE_UART_RX=4' USEMODULE=esp_log_startup BOARD=esp32-wroom-32 make -C tests/shell flash
```
The bootloader output and the STDIO should be routed to UART1 at GPIO4 and GPIO5.
### Issues/PRs references
Prerequisite for PR ##18863
19104: tests/periph_uart: only exclude STDIO_UART_DEV if stdio_uart is used 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: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
The UART interface and its configuration as used by the STDIO is defined in RIOT using `STDIO_UART_DEV` and the UART configuration in `periph_conf.h`.
However, the bootloader compiled directly in ESP-IDF uses its own definitions `CONFIG_ESP_CONSOLE_UART_*` for the UART configuration. To be able to use a consistent UART configuration in RIOT and the bootloader, e.g. to see the output of the 2nd stage bootloader, these `CONFIG_ESP_CONSOLE_UART_*` can be defined via a set of KConfig variables `CONSOLE_CONFIG_UART_*`. Here the variable `CONSOLE_CONFIG_UART_NUM` is then also used as `STDIO_UART_DEV` and the variables `CONSOLE_CONFIG_UART_RX` and `CONSOLE_CONFIG_UART_TX` of the configuration in `periph_conf.h` should be used accordingly.
f
18869: cpu/sam0_common/periph: Fix compilation with LLVM r=benpicco a=Teufelchen1
Related to #18851
This fixes an unused function error when compiling the gnrc_networking_mac example using LLVM as toolchain.
The fix works by only including the function when it is actually needed.
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
19031: cpu/stm32/periph_timer: implement timer_set() r=benpicco a=maribu
### Contribution description
The fallback implementation of timer_set() in `drivers/periph_common` is known to fail on short relative sets. This adds a robust implementation.
### Testing procedure
Run `tests/periph_timer_short_relative_set` at least a few dozen times (or use https://github.com/RIOT-OS/RIOT/pull/19030 to have a few dozen repetitions of the test case in a single run of the test application). It should now succeed.
### Issues/PRs references
None
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This fixes test failures in tests/periph_timer_short_relative_set.
Note: This differs a bit from the implementation in e.g. nRF5x or STM32
in that it always briefly pauses the timer. The issue is that when
running the timer can take a few ticks to actually react to the new
compare target. So even if the previously written target is still in
the future, the timer may not fire anyway. Pausing the timer while
setting and setting the target at least one higher than the current
count reliably triggers the IRQ.
19074: cpu/esp8266: build the SDK bootloader from source r=benpicco a=gschorcht
### Contribution description
This PR is a takeover of PR #17043, which is rebased to the current master and includes some corrections that became necessary after rebasing.
**Copied from description of PR #17043:**
We had four versions of pre-built bootloaders for the esp8266 with different settings of logging and color logging. These bootloaders were manually built from the SDK and shipped with RIOT-OS source code. However there are more settings that affect the bootloader build that are relevant to the app or final board that uses this bootloader. In particular, flash size and flash speed is important for the bootloader to be able to load an app from a large partition table at the fastest speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the bootloader. The boot ROM will normally start at a baud rate of 74880 (depending on the crystal installed), so it might make sense to keep the UART output at the same speed so we can debug boot modes and bootloader with the same terminal.
This patch builds the `bootloader.bin` file from the ESP8266 SDK source code. The code is built as a module (`esp8266_bootloader`) which at the moment doesn't generate any object code for the application and only produces a `bootloader.bin` file set to the `BOOTLOADER_BIN` make variable for the `esptool.inc.mk` to flash.
The code needs to be compiled and linked with custom rules defined in the module's Makefile since the `bootloader.bin` is its own separate application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the `$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier for applications or board to provide their own bootloader binary if needed.
As a result of building the bootloader from source we fixed the issue of having a large partition table.
### Testing procedure
Use following command to flash the application with STDIO UART baudrate of 115200 baud.
```
BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
Connect with a terminal programm of your choice (unfortunatly `picocom` and `socat` don't support a baudrate close to 74880), for example:
```
python -m serial.tools.miniterm /dev/ttyUSB0 74880
```
On reset, the `esp8266-esp-12x` node shows the ROM bootloader log output
```
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 6152, room 16
tail 8
chksum 0x6f
load 0x3ffe8008, len 24, room 0
tail 8
chksum 0x86
load 0x3ffe8020, len 3408, room 0
tail 0
chksum 0x79
```
as well as the second-stage bootloader built by this PR (`ESP-IDF v3.1-51-g913a06a9ac3`) at 74880 baudrate.
```
I (42) boot: ESP-IDF v3.1-51-g913a06a9ac3 2nd stage bootloader
I (42) boot: compile time 11:25:03
I (42) boot: SPI Speed : 26.7MHz
...
I (151) boot: Loaded app from partition at offset 0x10000
```
The application output is seen as garbage since the `esp8266-esp-12x` uses 115200 as baurate by default.
To see all output at a baudrate of 74880 baud, you can use the following command:
```
CFLAGS='-DSTDIO_UART_BAUDRATE=74880' BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
If the application is built without options, the ROOM bootloader output will be 74880 baud and the second stage bootloader and application output will be 115200 baud.
### Issues/PRs references
Fixes issue #16402
Co-authored-by: iosabi <iosabi@protonmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19078: cpu/esp32: define FLASHFILE_POS r=benpicco a=gschorcht
### Contribution description
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
This PR is a prerequisite for the `periph_flashpage` implementation PR #19079.
### Testing procedure
Flashing a ESP32x SoC should work with `FLASHFILE_POS=0x20000`, for example:
```
USEMODULE=esp_log_startup FLASHFILE_POS=0x20000 BOARD=esp32-wroom-32 make -j8 -C tests/shell flash
```
The bootloader output should give `00020000` as offset for the `factory` partition
```
I (75) boot: Partition Table:
I (78) boot: ## Label Usage Type ST Offset Length
I (84) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (91) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (97) boot: 2 factory factory app 00 00 00020000 000199b0
I (104) boot: End of partition table
```
and
```
I (125) esp_image: segment 0: paddr=00020020 vaddr=3f400020 size=02140h ( 8512) map
```
during the load of the image.
### Issues/PRs references
Prerequisite for PR #19079
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
19077: cpu/esp32: configurable linker scripts r=benpicco a=gschorcht
### Contribution description
This PR provides configurable linker scripts for ESP32x SoCs.
Using the vendor `memory.ld.in` file and a `sections.ld.in` file instead of the static versions of these files, from which the actual used `memory.ld` and `sections.ld` are generated using the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to define a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Note for the review: The `memory.ld.in` files are now simply copies of the manufacturer's `memory.ld.in` files. However, it is not possible to use the vendor's `memory.ld.in` files directly, because they have to be extended further on, e.g. for the `periph_flashpage` implementation.
This PR is prerequisite for the `periph_flashpage` support in PR #19079.
### Testing procedure
Green CI.
### Issues/PRs references
Prerequisite for PR #19079
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Using `sectoins.ld.in` instead of a static `sections.ld`, from which the actual used `sections.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom section layout.
Using the vendor `memory.ld.in` instead of a static `memory.ld`, from which the actual used `memory.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
19064: native: Remove code used for __MACH__ target r=benpicco a=Teufelchen1
### Contribution description
This PR removes code that was used to support macOS as native target.
macOS / `__MACH__` is no longer supported by RIOT on master.
### Testing procedure
If murdock is happy, that should be enough.
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
We had four versions of pre-built bootloaders for the esp8266 with
different settings of logging and color logging. These bootloaders were
manually built from the SDK and shipped with RIOT-OS source code.
However there are more settings that affect the bootloader build that
are relevant to the app or final board that uses this bootloader. In
particular, flash size and flash speed is important for the bootloader
to be able to load an app from a large partition table at the fastest
speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the
bootloader. The boot ROM will normally start at a baud rate of 74880
(depending on the crystal installed), so it might make sense to keep
the UART output at the same speed so we can debug boot modes and
bootloader with the same terminal.
This patch builds the bootloader.bin file from the ESP8266 SDK source
code. The code is built as a module (esp8266_bootloader) which at the
moment doesn't generate any object code for the application and only
produces a bootloader.bin file set to the BOOTLOADER_BIN make variable
for the esptool.inc.mk to flash.
The code needs to be compiled and linked with custom rules defined in
the module's Makefile since the bootloader.bin is its own separate
application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the
`$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier
for applications or board to provide their own bootloader binary if
needed.
As a result of building the bootloader from source we fixed the issue of
having a large partition table. Fixes#16402.
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>
`addi` with 20 bit immediate does not have a compressed representation,
so using `jalr` with immediate offset uncompressed is smaller than using
`addi`+`c.jr`
`cpu/cortexm_common/include/cpu.h` has to be included in `cpu/efm32/periph_cpu.h` so that `PROVIDES_PM_SET_LOWEST` is defined if only `periph_cpu.h` is included. Otherwise `pm_set_lowest` is defined multiple times if the `pm_layered` module is not used. `PROVIDES_PM_OFF` has to be defined in case `pm_layered` is not used, e.g. in riotboot.
Previously, the callback was incorrectly passed a channel of zero as
argument regardless of the channel that triggered the IRQ. This fixes
the issue and also uses `bitarithm_test_and_clear()` to only iterate
over the channels that actually have an IRQ flag set, rather than
all channels.
The linter was unhappy that `unsinged long` and `uint32_t` were used
inconsistency (in the `timer_init()` declaration, implementation, as
well as in the `DEBUG()` format specifiers).
Allow two threads to share the same timer - provided they use distinct
sets of timer channels - without occasionally corrupting registers or
state flags.
rtc_set_alarm() / rtt_set_alarm() are heavily used by ztimer during ISR. This will reduce time spent during ISR drastically. We trust that the peripheral is able to propagate the alarm asynchronously.
These models have 256 kByte RAM, but the upper 64 kByte are used as CCM data RAM accessible at 0x1000:0000. The access to 0x2003:xxxx leads to a hard fault.
Due to the RIOT_EPOCH of 2020 this overflow will happen in year 2084. It would be scary if IoT devices are still around then.
We can save RAM and ROM. Furthermore, this overflow handling should block BACKUP power mode in order to keep track of the reference year.
There are STM32 families where all models use only the Synopsys DWC2 USB OTG core while others completely use only the USB Device FS core. For these families then either the driver `drivers/usbdev_synopsys_dwc2` or the driver `cpu/stm32/periph/usbdev` is used depending on the respective family. However, the STM32 families F1 and L4 use both cores. The correct driver must therefore be selected depending on the CPU line or CPU model.
This splits up the clock configs.
It allows CPU_FAM based file sourcing and also common CPU_FAMs.
The dependancies are also included in wildcards would be used for the CPU_FAM macro.
This should be much more readable.
This also takes into account the HSE speeds in order to match the make/header resolution.
Some hidden symbols were added to make sorting many CPU_SERIES dependencies easier.
Make sure the STATUS register has been synced between the different clock domains.
Especially the LETIMER needs some time to update the STATUS register after it has been enabled. If the LETIMER is started and stopped with just a short delay, pm_layered gets confused because the timer seems to be inactive ...
This allows boards to define different crystal frequencies. The correct frequency is required by the system-related methods to ensure proper function of the underlying emlib.
As implmented, dma_resume assumed that transfers widths were 1 byte and
that the memory address incrmenting was always on and periphial address
incrementing always off. This resulted in memory corruption anytime
these assumptions were not true and a dma was resumed. The DMA module
allows intitiating transfers that did not meet these assumption.
This patch adds proper handling inside dma_resume to safely resume any
transfer. Clearifications and errors are added/fixed in the module's
header file. Also, a few constants are removed from the gobal namespace.
As it was, the calculation of DMA2's IRQ number was inccrorect for some
STM families. The implmentation alocates streams numbers 0 to 7 for the
first DMA controller and 8 and up for the second DMA controller. This
offset of +8 was not accounted for when IRQ's of the second DMA
controller was calculated. This patch corrects this.
Use `DWC2_USB_OTG_FS_TOTAL_FIFO_SIZE` instead of `USB_OTG_FS_TOTAL_FIFO_SIZE` since the latter is only defined in the vendor headers for STM32 MCUs. The STM32-specific problem that `USB_OTG_FS_TOTAL_FIFO_SIZE` is not defined in the vendor headers for all STM32 families has therefore been moved from the driver to the STM32-specific USB device header.
The `usbdev_synopsys_dwc2 driver` requires the `ztimer_msec` module and is therefore responsible for pulling it in. Therefore, the dependency on `ztimer_msec` can be removed here.
`thread_stack_init()` didn't correctly set up the stack alignment.
This fixes the issue and brings the function closer to the Cortex M
version, laying the groundwork for future code duplication.
This fixes https://github.com/RIOT-OS/RIOT/issues/11885
There are two schemes for accessing the packet buffer area (PMA) from the CPU:
- 2 x 16 bit/word access scheme where two 16-bit half-words per word can be accessed. With this scheme the access can be half-word aligned and the PMA address offset corresponds therefore to the local USB IP address. The size of the PMA SRAM is usually 1024 byte.
- 1 x 16 bit/word access scheme where one 16-bit half word per word can be accessed. With this scheme the access can only be word-aligned and the PMA address offset to a half-word is therefore twice the local USB IP address. The size of the PMA SRAM is usually 512 byte.
Which access scheme is used depends on the STM32 model.
The addressing of the Packet buffer Memory Area (PMA) is done locally in the USB IP core in half-words with 16-bit. The `_ep_in_buf` and `_ep_out_buf` arrays which hold these USB IP local addresses in the PMA for initialized EPs therefore always use `uint16_t`.
If the MCU does not have an internal D+ pullup and there is no dedicated GPIO to simulate a USB disconnect, the D+ GPIO is temporarily configured as an output and pushed down to simulate a disconnect/connect cycle to allow the host to recognize the device. However, this requires an external pullup on D+ signal to work
If `RCC_CFGR_USBPRE` is defined, the USB device FS clock of 48 MHz is derived from the PLL clock. In this case the PLL clock must be configured and must be either 48 MHz or 72 MHz. If the PLL clock is 72 MHz it is pre-divided by 1.5, the PLL clock of 48 MHz is used directly.
The definition in `pkg/esp32_sdk/Makefile.include` was evaluated by
`make` after the include paths were already set, resulting in
`ESP32_SDK_DIR` being empty in
INCLUDES += -I$(ESP32_SDK_DIR)/components
[...]
This in turn resulted in
cc1: error: /components: No such file or directory [-Werror=missing-include-dirs]
[...]
The parameters for parity and stop bits was confused, resulting in
the following compilation error with GCC 12.2.0:
/home/maribu/Repos/software/RIOT/cpu/esp_common/periph/uart.c: In function '_uart_config':
/home/maribu/Repos/software/RIOT/cpu/esp_common/periph/uart.c:394:61: error: implicit conversion from 'uart_stop_bits_t' to 'uart_parity_t' -Werror=enum-conversion]
394 | if (_uart_set_mode(uart, _uarts[uart].data, _uarts[uart].stop,
| ~~~~~~~~~~~~^~~~~
/home/maribu/Repos/software/RIOT/cpu/esp_common/periph/uart.c:395:42: error: implicit conversion from 'uart_parity_t' to 'uart_stop_bits_t' -Werror=enum-conversion]
395 | _uarts[uart].parity) != UART_OK) {
| ~~~~~~~~~~~~^~~~~~~
cc1: all warnings being treated as errors
This swaps the parameters.
For a number of STM32 MCUs with the USB-FS device interface the signals USB_DP and USB_DM are not defined as GPIO alternative function but as additional function. Additional functions are directly selected/enabled through peripheral registers hand have not to be configured. In this case, the configuration defines GIO_AF_UNDEF as alternative function.
This file is an excerpt of STM32 header file `stm32/smsis/f7/include/stm32f767xx.h` since the ESP32x SoCs use the same Synopsys DWC2 IP core as USB peripherals.
Since `esp_can.h` is included by main `cpu/esp32/include/periph_cpu.h` after the include of the specific `periph_cpu_$(CPU_FAM)`, it is not necessary to include `esp_can.h` in each specific `periph_cpu_$(CPU_FAM)`.
Makefiles don't do comments, so these were forwarded into the variable.
*Most* users would expand the arguments to a shell where it'd be
ignored, but not all of them.
Contributes-To: https://github.com/RIOT-OS/RIOT/pull/18489
(This is also where the one version that is added here was removed).
Due to the lack of new official avr-libc releases (which includes the
vendor header files needed to support different version of MCUs),
support for new MCUs was lacking. Distributions such as Debian addressed
this by extending the upstream code with vendor header files directly
obtained from Atmel / Microchip, but without paying attention to
details. As such, a naming inconsistency (ASIZE vs ASPACE) between
officially supported MCUs and new MCUs was introduced.
Now that avr-libc 2.1.0 is officially released, hardware support for new
MCUs is provided by upstream out of the box and only ASIZE is used as
name. This commit adds a bit of glue code to create aliases for ASIZE on
older avr-libc versions where needed. This fixes compilation with the
new avr-libc release and results in more consistent code.
- 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
Add tracing support via GPIOs to trace the basic state of the Ethernet
peripheral. The following signals are provided:
- One GPIO pin is toggled on entry of the Ethernet ISR
- On TX start an GPIO is set, on TX completion it is cleared
- On RX complete an GPIO is set, once this is passed to the upper layer
the GPIO is cleared again
In order to reduce the overhead, GPIO LL is used. By default the
on-board LEDs are used as tracing GPIOs. This makes it easy to debug
when the state machine gets stuck without the need to attach a scope or
logic analyzer.
If module `core_mutex_priority_inheritance` is enabled, the scheduling has to be active to lock/unlock the mutex/rmutex used by FreeRTOS semaphores. If scheduling is not active FreeRTOS semaphore function always succeed.
For ESP32x, the operations on recursive locking variables have to be guarded by disabling interrupts to prevent unintended context switches. For ESP8266, interrupts must not be disabled, otherwise the intended context switch doesn't work when trying to lock a rmutex that is already locked by another thread.
Dynamic allocation and initialization of the mutex used by a newlib locking variable must not be interrupted. Since a thread context switch can occur on exit from an ISR, the allocation and initialization of the mutex must be guarded by disabling interrupts. The same must be done for the release of such a locking variable.
With the improvements of the locking mechanism, thread safety of malloc/realloc/calloc/free is guaranteed. Module malloc_thread_safe is not needed any longer.
When FreeRTOS semaphores, as required by ESP-IDF, are used together with `gnrc_netif`, RIOT may crash if `STATUS_RECEIVE_BLOCKED` is used as a blocking mechanism in the FreeRTOS adaptation layer. The reason for this is that `gnrc_netif` uses thread flags since PR #16748. If the `gnrc_netif` thread is blocked because of a FreeRTOS semaphore, and is thus in `STATUS_RECEIVE_BLOCKED` state, the `_msg_send` function will cause a crash because it then assumes that `target->wait_data` contains a pointer to a message of type `msg_t`, but by using thread flags it contains the flag mask. This situation can happen if the ESP hardware is used while another thread is sending something timer controlled to the `gnrc_netif` thread.
To solve this problem `STATUS_MUTEX_LOCKED` is used instead of `STATUS_RECEIVE_BLOCKED` and `STATUS_SEND_BLOCKED`
To reduce the required RAM in default configuration, the BLE interface is used as netdev_default instead of ESP-NOW. Further network interfaces can be enabled with the modules `esp_now`, `esp_wifi` or `esp_eth`.
When using Bluetooth LE, the former UART interrupt number 5 is occupied by the ESP32 Bluetooth Controller. Therefore, another interrupt number has to be used for UART.
The package uses the nRFx SDK package `nrfx`. In addition, the `mynewt-nimble` repository contains some files (`porting/nimble/src/hal_timer.c` and `porting/npl/riot/src/nrf5x_isr.c`) that are compilable only for nRF MCUs. To allow the compilation for other platforms, the use of the `nrfx` package and the compilation of these files are now dependent on the use of any nRF5x MCU.
