According to ieee802154_radio_confirm_transmit docs, the parameter of
confirm_op for IEEE802154_HAL_OP_TRANSMIT is to be populated as an out
parameter -- but this implementation unconditionally left info
unpopulated. Thus, when run with LLVM, _fsm_state_tx_process_tx_done
looked into an uninitialized info and thus crashed into failing
assertions.
Closes: https://github.com/RIOT-OS/RIOT/issues/17591
Building `fuzzing/gcoap` with afl-gcc 11.2 gives
/home/benpicco/dev/RIOT/cpu/native/native_cpu.c: In function ‘thread_stack_init’:
/home/benpicco/dev/RIOT/cpu/native/native_cpu.c:120:11: error: variable ‘stk’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
120 | char *stk = NULL;
| ^~~
/home/benpicco/dev/RIOT/cpu/native/native_cpu.c:118:72: error: argument ‘stack_start’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
118 | char *thread_stack_init(thread_task_func_t task_func, void *arg, void *stack_start, int stacksize)
|
We can re-write the function to not use this temporary variable and the error goes away.
Since commit 3a11b1fbd2 (#16972)
building RIOT applications with `BOARD=hifive1` causes the following
linker error to be emitted on my system:
/opt/rv32imc/lib/gcc/riscv32-unknown-elf/10.2.0/../../../../riscv32-unknown-elf/bin/ld:riscv_base.ld:220: warning: memory region `rom' not declared
This is due to the fact that the RISC-V linker script doesn't have a rom
memory region. While many other ARM-based boards have a rom memory
region defined in the linker script, the corresponding region name in
the RISC-V linker script is flash and rom is not declared as a memory
region hence the warning.
I think this was accidentally overlooked in
3a11b1fbd2. It is fixed in this commit by
replacing the rom region with the flash region. The linker script
identifiers (e.g. _srom and _erom) are not renamed.
The toolchain provides POSIX type definitions for pthread which conflicts with that in RIOT. With the CFLAGS/CXXFLAGS skip the inclusion of the types shipped by the toolchain.
Module `esp_idf_nvs_flash` uses C++ code. Since `esp_idf_nvs_flash` module is always enabled on ESP8266, the permanent dependency on `cpp` is correct. But on ESP32, the `esp_idf_nvs_flash` module is only enabled if `esp_wifi_any` is used. Only in that case the compilation should depend on module `cpp`.
The vendor binary libraries of ESP-IDF are provided as a separate GIT repository. These libraries are defined as separate package for two reasons: 1. RIOT packages don't support to clone GIT repositories recursively; 2. ESP-IDF pulls a lot of other GIT repositories that are not needed when it is cloned recursively.
The vendor binary libraries of ESP-IDF are provided as a separate GIT repository. These libraries are defined as separate package for two reasons: 1. RIOT packages don't support to clone GIT repositories recursively; 2. ESP-IDF pulls a lot of other GIT repositories that are not needed when it is cloned recursively.
If the WiFi interface is enabled by module `esp_wifi_any`, binary SDK libraries use the RTT. Therefore, `ztimer` must not use `periph_rtt`as backend, if the WiFi interface is enabled by module `esp_wifi_any`.
`ztimer_core` functions have to reside in IRAM for timing reasons and to be available also when the IROM cache is disabled. Although the module is called `ztimer`, its object files are generated in directory `ztimer_core`.
Previously, a default value for ESP_WIFI_PASS was intentionally defined only if DOXYGEN was also defined, to allow ESP_WIFI_PASS to be left undefined for using APs without authentication. With PR #17415 the definition was changed to always define a default value for EPS_WIFI_PASS. This made it impossible to use APs without authentication. The commit reverts this change.
The former correction factors were determined by measuring the resulting clocks without a device connected to the bus.
However, when testing the changes for low CPU clock frequencies, it was figured out that the clocks not only depend on configured register values
_i2c_hw[dev].regs->scl_low_period.period
_i2c_hw[dev].regs->scl_high_period.period
but also on the bus capacity. Obviously, the register values are not absolute times in APB clock cycles, but rather times that start as soon as the corresponding level is reached. In this case, the higher the bus capacity, the longer the period would be.
This means that the clock speed cannot be precisely controlled via the correction factors anyway. For this reason, and because the I2C implementation in ESP-IDF also does not use correction factors, they were removed.
The semantics of defining an SSID prefix that overrides the already defined SSID exactly when and only when it is set, and then enabling dynamic SSID generation with that prefix, made handling the parameter definition unnecessarily difficult and hard to understand.
Defining a boolean option that enables dynamic SSID generation, which then simply reuses the defined SSID as a prefix, makes it much more understandable and easier to handle, especially with respect to Kconfig.
Modify the periph_temperature implementation to expose the full
resolution of the temperature sensor. The accuracy of the sensor will
likely be less than 0.25 °C, but typically temperature sensors have
a precision in the order of their resolution. Exposing the full
resolution can therefore be useful to monitor relative temperature
changes.
The sam0 rtt busy loops for 180us every time an alarm is set or
the counter is read, this propagates and leads to timing errors
on ztimer_msec that are higher than > +-1msec.
The same goes for fe310.
For RISC-V and Cortex-M-not-3, triples are known and have worked in some
configuration, but do not work at the moment and stay disabled until the
reference platforms (native, M3) have been established well.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
On the ESP32 it is often not possible with the I2C software implementation to communicate with an AIP31068 based LCD module. Therefore, the I2C hardware implementation is enabled when the AIP31068 driver is used, but it is more buggy than stable. The timing of the two implementations seems to be almost identical. The only difference is that the hardware implementation clears the bus before each access by sending 10 clock pulses on the SCL line while SDA is LOW. Using the same mechanism during I2C initialization for the software implementation solves the communication problem with the AIP31068.
The same software implementation works reliably with the AIP31068 on the ESP8266.
The peripheral register addresses are fixed, properly aligned addresses. Storing
them as uintptr_t makes live easier when casting them to helper structs, as no
intermediate cast to uintptr_t is needed to silence -Wcast-align.
With the change from using archive files to using object files in PR #14754, the module `esp_wifi_enterprise` was no longer compilable. The reason for this was that the file `bignum.c` was present in two different vendor sub-directories and created two identical object files, which then led to a symbol conflict when linking. This commit removes one of these identical files. The one that is used in all `esp_wifi` variants is kept, the one that is only used in `esp_wifi_enterprise` is dropped.
cpu/cortexm_common/thread_arch.c:262: error (comparePointers): Comparing pointers that point to different objects
cpu/cortexm_common/thread_arch.c:266: error (comparePointers): Subtracting pointers that point to different objects
cpu/esp_common/syscalls.c💯 error (memleak): Memory leak: mtx
cpu/esp_common/syscalls.c:131: error (memleak): Memory leak: rmtx
cpu/esp_common/syscalls.c:365: error (comparePointers): Subtracting pointers that point to different objects
cpu/esp_common/thread_arch.c:355: error (comparePointers): Comparing pointers that point to different objects
cpu/esp8266/startup.c:59: error (comparePointers): Subtracting pointers that point to different objects
Setting up a DMA transfer can take longer than sending out a buffer
byte by byte if the buffer is small.
DMA only shows advantages for large buffers, using it for every transfer
will cause a net slowdown.
Since we did not come up with a good way to determine the treshold based
on the SPI frequency, just use a fixed buffer for now so that DMA can be
used without slowing things down overall.
In Asynchronous Fractional baud rate mode, the baud rate can not be
greater than the source frequency divided by the oversampling (8, 16).
Currently we are always using 16x oversampling.
This makes it impossible to e.g. set a 2 MHz UART baud rate on the 16 MHz
`saml10-xpro`.
With this change, the oversampling is automatically reduced to 8x which
allows us to set 16 MHz / 8 -> 2 MHz baud rate.
Unaligned accesses on x86(_64) are allowed, but slow. However, some host systems
might not be that forgiving. Aligning the stack to sizeof(uintptr_t) should be
a pretty safe safety measure.
And with this done, all casts of the stack pointer that increase alignment
requirements are now intermediately casted to `uintptr_t` to silence
warnings from -Wcast-align - after all the stacks are now manually aligned.
Make sure in `_usbdev_new_ep()` that `usbdev_ep_t::buf` is always aligned to 4
bytes. With this in mind, add intermediate casts to `uintptr_t` before casting
`usbdev_ep_t::buf` to `uint32_t *` to silence `-Wcast-align`, as we now manually
enforced correct alignment.
The IRAM is much faster, while the IROM is much slower and can only be accessed via a cache, which is also sometimes disabled, e.g. by the WiFi module or when writing to the flash. Therefore, time-critical code as well as code that has to work even when the cache is disabled must be placed in the IRAM.
The functions of the `esp*/freetos` libraries must be placed in IRAM because they can be called when the IROM cache is disabled. While the functions implemented in `cpu/esp8266/freetos/*.c` are already placed in IRAM, the functions implemented in `cpu/esp_common/freetos/*.c` are not placed in IRAM. The reason for this is that the object files of these files are created in the `esp_freertos_common` directory, which is not included in the `esp.riot-os.ld` file because the library is named `esp_freertos_common`.
RIOT-OS uses part of Espressif ESP8266 RTOS SDK to build support for
this CPU. The SDK includes some vendor-provided closed source
pre-compiled libraries that we need to modify to adapt to RIOT-OS
usage. This library modifications was done once and uploaded to a fork
of the vendor repository and was provided as an environment variable.
This patch changes two things:
1. It installs the SDK as a RIOT PKG from the new pkg/esp8266_sdk
directory instead of requiring the user to download it separately.
2. It performs the library modifications (symbol renames) on the pkg
Makefile removing the need to use a fork with the modifications applied
and simplifying the SDK update and future modifications.
This change sets the SDK package version (git SHA) to the same one that
our fork was using as a parent in the vendor repository, meaning that
the output libraries are exactly the same as before.
Tested with
```
ESP8266_RTOS_SDK_DIR=/dev/null USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
and verified that the program works. The boot message now includes:
```
ESP8266-RTOS-SDK Version v3.1-51-g913a06a9
```
confirming the SDK version used.
`/dev/null` in the test is just to make sure that no evaluation of
`ESP8266_RTOS_SDK_DIR` in make is affected by the environment variable
value which would be set to the SDK for people who followed the set up
instructions before this change.
Tested the checkout size:
```bash
$ du -hs build/pkg/esp8266_sdk/
124M build/pkg/esp8266_sdk/
```
Checksumming flash is not supported on xtensa platform:
Warn : not implemented yet
make: *** [.../RIOT/examples/saul/../../Makefile.include:796: flash] Error 1
https://github.com/espressif/openocd-esp32 is needed.
Example config (when compiled from source):
export OPENOCD="~/esp/openocd-esp32/src/openocd -s ~/esp/openocd-esp32/tcl"