Command "waitms 50" on ChromeBook EC console, then it will crash EC.
Because arch_busy_wait() is re-entried by two different tasks,
the second calling will reset the timer and may cause the first
calling to fail to reach the waiting destination
(if the first calling's wait time is longer enough).
Verified by follow test pattern:
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_api
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_error_case
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_monotonic
west build -p auto -b it8xxx2_evb tests/kernel/timer/starve
west build -p auto -b it8xxx2_evb tests/kernel/context
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Add overlay property node and configs to support tests/subsys/fs/ext2,
tests/fs/fat_fs_api and tests/subsys/sd on RA8 boards
Signed-off-by: Quy Tran <quy.tran.pz@renesas.com>
These are never meant to be run, so make sure it's explicitly specified
through the build_only property.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Add Silabs boards to the newly added test cases which exercise the
CONFIG_BUILD_ONLY_NO_BLOBS configuration option. Also fix the namespace to
be "peripheral" for the peripheral sample app.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Add empty function stubs to support building with the newly introduced
CONFIG_BUILD_ONLY_NO_BLOBS option.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Build is failing due to wrong calls to appcpu
stall and clock gating. This fixes it
by using proper registers.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Updating release notes to include the recently added Adafruit QT Py
ESP32-S3 both with and without its PSRAM version.
Signed-off-by: Ian Wakely <raveious.irw@gmail.com>
The address passed in to the function was incorrect causing
failures when porting to RT1180.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Check that the GATT settings added when bonding to a peer and
subscribing to a CCC are correctly deleted when calling `bt_unpair`.
Testing hooks have been added in the Bluetooth settings abstraction
layer to know which key are being added/deleted.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
`bt_gatt_clear_cf` was calling `bt_settings_delete_ccc` instead of
`bt_settings_delete_cf`. This was causing some settings to be left over.
Fix the issue by using the correct function.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
For waking up the poll() use eventfd() instead of socketpair()
so we save some buffer space and one file descriptor.
Signed-off-by: Seppo Takalo <seppo.takalo@nordicsemi.no>
For the lists of properties passed as a pointer to the get_props and
set_props functions, there is no reason to not make the pointer const as
the called functions will not and should not alter the pointed-to data.
In practice, not having the pointers const can cause compilation errors
if trying to pass in a const array of properties.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@escolifesciences.com>
The fuel_gauge_get_props and fuel_gauge_set_prop functions were missing
casts for the device struct which causes compiler warnings when using
the -fpermissive compiler flag.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@escolifesciences.com>
In the fuel_gauge_get_props and fuel_gauge_set_props functions, an array
len is passed as a size_t but compared against an int, which leads to
C++ compiler warnings when using -Werror=sign-compare. The fix is to use
a size_t for the loop counter.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@escolifesciences.com>
Use uint64_t instead of uint32_t for the FLASH_STM32_EX_OP_SECTOR_WP
extended operation.
Some chips have two banks, more than 16 sectors each e.g. stm32h7a3xx
chips, so more than 32 bits are required.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The `lock` arg is used multiple times in the function, making the
`ARG_UNUSED(lock);` redundant, remove it.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
Expand test_sink_encrypted_incorrect_code to retry the sync with
the correct broadcast code after failing the initial sync
with the incorrect broadcast code.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In smaller projects and organizations, forking Zephyr is usually
a tenable solution for development continuity, in the case that
bug-fixes or enhancements need to be applied to Zephyr to
unblock development.
In larger organizations, perhaps in the absence of healthy patch
management, technical debt management, and open-source policies,
forking and in-tree changes can quickly get out of hand.
In other organizations, it may simply be preferable to have a
zero-forking / upstream-first policy.
Regardless of the reason, this change adds a `west patch`
command that enables users to manage patches locally in their
modules, under version control, with complete transparence.
The format of the YAML file (detailed in a previous comit)
includes fields for filename, checksum, author, email, dates,
along with pr and issue links. There are fields indicating
whether the patch is upstreamble or whether it has been merged
upstream already. There is a custom field that is not validated
and can be used for any purpose.
Workflows can be created to notify maintainers when a merged
patch may be discarded after a version or a commit bump.
In Zephyr modules, the file resides conventionally under
`zephyr/patches.yml`, and patch files reside under
`zephyr/patches/`.
Sample usage applying patches (the `-v` argument for additional
detail):
```shell
west -v patch apply
reading patch file zephyr/run-tests-with-rtt-console.patch
checking patch integrity... OK
patching zephyr... OK
reading patch file zephyr/twister-rtt-support.patch
checking patch integrity... OK
patching zephyr... OK
reading patch file zephyr/multiple_icntl.patch
checking patch integrity... OK
patching zephyr... OK
reading patch file zephyr/move-bss-to-end.patch
checking patch integrity... OK
patching zephyr... OK
4 patches applied successfully \o/
```
Cleaning previously applied patches
```shell
west patch clean
```
After manually corrupting a patch file (the `-r` option will
automatically roll-back all changes if one patch fails)
```shell
west -v patch apply -r
reading patch file zephyr/run-tests-with-rtt-console.patch
checking patch integrity... OK
patching zephyr... OK
reading patch file zephyr/twister-rtt-support.patch
checking patch integrity... OK
patching zephyr... OK
reading patch file zephyr/multiple_icntl.patch
checking patch integrity... OK
patching zephyr... OK
reading patch file zephyr/move-bss-to-end.patch
checking patch integrity... FAIL
ERROR: sha256 mismatch for zephyr/move-bss-to-end.patch:
expect: 00e42e5d89f68f8b07e355821cfcf492faa2f96b506bbe87a9b35a823fd719cb
actual: b9900e0c9472a0aaae975370b478bb26945c068497fa63ff409b21d677e5b89f
Cleaning zephyr
FATAL ERROR: failed to apply patch zephyr/move-bss-to-end.patch
```
Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
Setting a deadline is not a schedule point. This makes it a
perfect place to verify the behavior of the new k_reschedule()
routine at both thread and ISR level.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
The routine k_reschedule() allows an application to manually force
a schedule point. Although similar to k_yield(), it has different
properties. The most significant difference is that k_yield() if
invoked from a cooperative thread will voluntarily give up execution
control to the next thread of equal or higher priority while
k_reschedule() will not.
Applications that play with EDF deadlines via k_thread_deadline_set()
may need to use k_reschedule() to force a reschedule.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
For the shell RFCOMM case, these is a stack overflow problem when do
disconnect, so need to increase the CONFIG_BT_RFCOMM_DLC_STACK_SIZE.
Set CONFIG_BT_RFCOMM_DLC_STACK_SIZE default 512.
Signed-off-by: Make Shi <make.shi@nxp.com>
Fixed bug calculating offset of registers after unused space in the ADC
register space for the SZ package parts.
Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
The RP2350's PWM peripheral is largely unchanged from the RP2040's, but
the higher clock frequency means the long blink delay must be lower.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Increase test coverage for Raspberry Pi's SoCs. Use the `socs` folder
rather than `boards` to enable these tests to run on any boards with the
same SoCs.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Avoid referring to Pico 2 (the name of a board). In this context,
RPI_PICO is used to refer to the (Zephyr) `SOC_FAMILY` rather than the
Pico 1 board. This clarifies common numerical values between the RP2040
and RP2350 SoC series, and enables existing DTS files to be used with
RP2350-based boards with fewer changes.
Remove the use of Zehpyr's `CONFIG_` macros from the device tree files,
and replace them with `SOC_SERIES`-specific files. Update the driver
implementation to conditionally include the correct file. Update
documentation and samples to match.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Add initial support for the RP2350's DMA peripheral, allow tests
under drivers/dma/loop_transfer to run on on the Raspberry Pi Pico 2,
and update the board's documentation.
Signed-off-by: Manuel Aebischer <manuel.aebischer@belden.com>
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Add initial support for the RP2350's PIO peripherals, extend the
existing example under samples/boards/raspberrypi/rpi_pico/uart_pio to
demonstrate this on the Raspberry Pi Pico 2, and update the board's
documentation.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Signed-off-by: Manuel Aebischer <manuel.aebischer@belden.com>
Extend gpio_api_1pin so that tests can require a test fixture to provide
an external pulldown resistor to the board under test. Use the new
test-gpio-external-pulldown device tree binding to define where that
GPIO is, and, finally, add a device tree overlay for the Raspberry Pi
Pico 2 board that defines where the pulldown provided by the fixture
will be.
Tested locally using `--fixture gpio_external_pull_down` when running
Twister on the command line, or by creating and using a Hardware Map
file, in combination with a modified Pico 2.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Add OpenOCD debugger support.
For now we will need Raspberry Pi'a forked version of OpenOCD from
https://github.com/raspberrypi/openocd .
The default adapter speed is set to match Raspberry Pi's documentation.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
For these tests' needs, the RP2350 on the Pico 2 is compatible with the
RP2040 on the Pico 1. #include the latter's overlay in preference to
duplicating the content.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The Raspberry Pi Pico 2's device is compatible with the existing Pico 1.
The build system requires a `<board>.overlay` file, but these use the
pre-processing to #include the sibling rpi_pico.overlay files rather
than duplicating the contents as an attempt to keep things DRY.
Tested locally.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Add UF2 Family ID for Raspberry Pi 2350 and build
UF2 image by default for Pico 2 board
Signed-off-by: Ryan Grachek <grachek@gmail.com>
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The Raspberry Pi Pico 2 is Raspberry Pi's first board fitted with their
RP2350A SoC.
This adds a minimal board definition, sufficient to build and run
`samples/hello_world` and `samples/basic/blinky` on the board. Images
can be run on the target using OpenOCD. Raspberry Pi's `picotool` can
create a UF2 binary, which ensures that errata RP2350-E10 is avoided
e.g.
```
> picotool uf2 convert build\rpi_pico2\hello_world\zephyr\zephyr.elf \
build\rpi_pico2\hello_world\zephyr\zephyr.uf2 \
--family rp2350-arm-s --abs-block`
```
Raspberry Pi Pico 2 is a low-cost, high-performance microcontroller
board with flexible digital interfaces. Key features include:
- RP2350A microcontroller chip designed by Raspberry Pi in the United
Kingdom
- Dual Cortex-M33 or Hazard3 processors at up to 150MHz
- 520KB of SRAM, and 4MB of on-board flash memory
- USB 1.1 with device and host support
- Low-power sleep and dormant modes
- Drag-and-drop programming using mass storage over USB
- 26x multi-function GPIO pins including 3 that can be used for ADC
- 2x SPI, 2x I2C, 2x UART, 3x 12-bit 500ksps Analogue to Digital
Converter (ADC), 24x controllable PWM channels
- 2x Timer with 4 alarms, 1x AON Timer
- Temperature sensor
- 3x Programmable IO (PIO) blocks, 12 state machines total for custom
peripheral support
- Flexible, user-programmable high-speed IO
- Can emulate interfaces such as SD Card and VGA
The Raspberry Pi Pico 2 comes as a castellated module which allows
soldering direct to carrier boards.
Only enable timer 0 for now. Timer 1 won't work correctly until the
rpi_pico HAL has picked up the fix for `hardware_alarm_irq_handler`. See
https://github.com/raspberrypi/pico-sdk/pull/1949 .
Added some documentation for the board itself (mostly aiming to refer to
canonical sources of information rather duplicate). Add entries in the
release notes where applicable.
boards/raspberrypi/rpi_pico2/doc/img/rpi_pico2.webp is a cropped and
compressed version of https://www.raspberrypi.com/documentation/microcontrollers/images/pico-2.png
which is released under the CC-BY-SA-4.0 license. See https://github.com/raspberrypi/documentation/blob/develop/LICENSE.md
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
On RP2350, the alt function value can be up to 0x1F, so store as 5 bits.
Signed-off-by: Peter Johanson <peter@peterjohanson.com>
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
A significant amount of the pin muxing is duplicated between the RP2040,
the RP2350A, and RP2350B. Reflect this in the file structure, with a
`-common` suffix used to to indicate this.
Macros are defined in ascending order of the function index in the
relevant table in the datasheet. SoC/SoC-series specific macros are
defined in their respective tables. Functions that are not currently
used (e.g. the new HSTX) are intentionally not defined here as they do
not (currently) have any use in the Zephyr tree (i.e. there's no drivers
that make use of this functionality).
clang-format has been run over the existing definitions to reduce the
noise generated by CI. These are cosmetic changes; I've tried to retain
attribution to the relevant authors where applicable.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The RP2350 SoC series contain two timer peripherals. Extend the driver
to support using the second timer (`TIMER1`).
N.b. this requires a fix from the Pico SDK to be patched into
hal_rpi_pico. See https://github.com/raspberrypi/pico-sdk/pull/1949 .
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The watchdog register configuration of RP2350 differs from that
of RP2040, so we make fit that.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Unlike the RP2040, the RP2350 has multiple tick generators that need to
be started. Start TIMER0 and TIMER1 tick generators during
clock_control_init.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Extend the existing driver to add some initial support for the new SoC,
whilst maintaining compatibility with the RP2040.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
RP2350 is Raspberry Pi's newest SoC. From the datasheet:
"RP2350 is a new family of microcontrollers from Raspberry Pi that
offers significant enhancements over RP2040. Key features include:
• Dual Cortex-M33 or Hazard3 processors at 150 MHz
• 520 kB on-chip SRAM, in 10 independent banks
• 8 kB of one-time-programmable storage (OTP)
• Up to 16 MB of external QSPI flash/PSRAM via dedicated QSPI bus
...
"
This commit introduces some changes to support the existing RP2040 and
what is describe by Raspberry Pi as the "RP2350 family". Currently there
are 4 published products in the family: RP2350A, RP2350B, RP2354A, and
RP2354A. Within Zephyr's taxonomy, split the configuration as follows:
Family: Raspberry Pi Pico. This contains all RP2XXX SoCs,
SoC Series: RP2040 and RP2350.
SoC: RP2040 and, for now, just the RP2350A, which is present on the Pico
2, where the A suffix indicates QFN-60 package type. This structure is
reflected in `soc/raspberrypi/soc.yml`, and somewhat assumes that there
won't be a RP2050, for example, as a RP2040 with more RAM.
This is foundation work ahead of introducing support for Raspberry Pi's
Pico 2 board, which is fitted with a RP2350A and 4MB of flash.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
