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.
