zephyrproject-rtos/zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.

The Zephyr Project is a scalable real-time operating system (RTOS) supporting multiple hardware architectures, optimized for resource constrained devices, and built with security in mind.

The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained systems: from simple embedded environmental sensors and LED wearables to sophisticated smart watches and IoT wireless gateways.

The Zephyr kernel supports multiple architectures, including ARM (Cortex-A, Cortex-R, Cortex-M), Intel x86, ARC, Nios II, Tensilica Xtensa, and RISC-V, SPARC, MIPS, and a large number of supported boards.

Getting Started

Welcome to Zephyr! See the Introduction to Zephyr for a high-level overview, and the documentation's Getting Started Guide to start developing.

Community Support

Community support is provided via mailing lists and Discord; see the Resources below for details.

Resources

Here's a quick summary of resources to help you find your way around:

Getting Started

📖 Zephyr Documentation
🚀 Getting Started Guide
🙋🏽 Tips when asking for help
💻 Code samples

Code and Development

🌐 Source Code Repository
📦 Releases
🤝 Contribution Guide

Community and Support

💬 Discord Server for real-time community discussions
📧 User mailing list ([email protected])
📧 Developer mailing list ([email protected])
📬 Other project mailing lists
📚 Project Wiki

Issue Tracking and Security

🐛 GitHub Issues
🔒 Security documentation
🛡️ Security Advisories Repository
⚠️ Report security vulnerabilities at [email protected]

Additional Resources

🌐 Zephyr Project Website
📺 Zephyr Tech Talks

zephyr's Issues

Use tinycrypt for random number generation

Reported by Javier B Perez:

It should be possible to use tinycrypt API instead of HCI for random number generation. This should be faster and also trace logs from pairing won't be spammed with extra HCI commands.

(Imported from Jira ZEP-11)

Arduino 101 ADC first read will always return 2048

Reported by Javier B Perez:

Configuration

arc
Arduino 101
nano

Bug detailed description

Use API adc_read(), it will always return 0x800 when calling it first time

Testcase to Reproduce

Test case is attached

Steps to Reproduce

1. Connect A0 to ground with resistor 1.5k
2. make BOARD=arduino_101 APP=test_adc APP_ARC=test_adc_arc flash
3. Check adc read result

Expected Result

It should return value around 0 since it's connected to ground

Actual Result

The first read will always be 2048
ipm_console0: '[test_adc_read_1_entry_33v] start'
pinmux switch a0 from func a to func b
ipm_console0: 'adc read: 2048 0'
ipm_console0: 'adc read: 0 0'
ipm_console0: 'result: PASS'
ipm_console0: '[test_adc_read_1_entry_33v] end'

User Impact

(Imported from Jira ZEP-4)

Create a generic 802.15.4 driver API

Reported by Javier B Perez:

This should try to provide a public API for any kind of 802.15.4 hardware.

(Imported from Jira ZEP-12)

BT 4.2 Pair with BlueZ using LE SC

Reported by Javier B Perez:

See with btmon that pairing is done using LE SC

(Imported from Jira ZEP-23)

Automated testing script / framework for IP stack

Reported by Javier B Perez:

We need a way to verify the correctness of the IP stack. One way to do this is to have a sanity check script that runs two qemus that transfer data between them and verifying that there are no errors during data transfer.

(Imported from Jira ZEP-37)

Low duty cycle direct BLE advertising

Reported by Javier B Perez:

Low duty cycle direct LE advertising

(Imported from Jira ZEP-28)

Enable SSP events

Reported by Javier B Perez:

Enable SSP events

(Imported from Jira ZEP-47)

Link Key request/reply handling

Reported by Javier B Perez:

Link Key request/reply handling

(Imported from Jira ZEP-42)

Handle PIN request

Reported by Javier B Perez:

Handle Security Mode 3 (security on link),
Handle track PIN length,
Handle PIN request / reply

(Imported from Jira ZEP-45)

Bluetooth LE link-layer topology

Reported by Javier B Perez:

NB: This is hw-dependent feature

(Imported from Jira ZEP-26)

Create a generic SPI driver API

Reported by Javier B Perez:

Such API will permit to use SPI controllers - if provided by the CPU/BSP - to access any type of SPI slaves.

This API should:

• setup the common parameters to deal with slaves (bits per work, frequency, SPI mode...)
• provide synchronous receive and send functions (interrupt based, there won't be any non-interrupt based implementation)

This is a necessary part to enable 802.15.4 hardware.

(Imported from Jira ZEP-18)

define API for interrupt controllers

Reported by Hirally Santiago:

We would like at least a baseline set of interrupt handling function prototypes in a common header that will be used by drivers to manage interrupts. The implementation of these APIs can be done in arch-specific code or code for the selected interrupt controller. This should greatly help porting drivers among platforms and ensure that subtle differences in interrupt handling APIs are known. This will also allow us to not directly call APIs directly in interrupt controller code; for example much x86 core code assumes an APIC and support for Quark D2000 MVIC had to be hacked in by conforming to the APIC driver's interface.

Acceptance Criteria:

1. IRQ APIs, as much as possible, consolidated into a common header
2. All references to specific interrupt controllers removed from arch/ code
3. All code supporting specific interrupt controllers (NVIC, etc) moved to drivers/interrupt_controller

(Imported from Jira ZEP-48)

E2E tests for connection

Reported by Javier B Perez:

Verify with the ubt-tester tool that it is possible to establish successful connection from a virtual test peer to the implementation

(Imported from Jira ZEP-31)

Bluetooth LE data length extension

Reported by Javier B Perez:

LE data length extension

(Imported from Jira ZEP-29)

Enable COM3/4 on generic_pc target

Reported by Javier B Perez:

Currently generic_pc provides only COM1 (console) and COM2 (BT UART). BT tester application requires another COM for simple UART.

(Imported from Jira ZEP-9)

Bluetooth: End to end testing for non-interactive pairing

Reported by Javier B Perez:

E2E testing for non-interactive pairing

(Imported from Jira ZEP-20)

Implement the SPI driver for Quark SE CPU

Reported by Javier B Perez:

Once the generic SPI driver API is done, implement such API support for Quark SE CPU.
(802.15.4 is not going to be ported on Galileo, unless someone really wants to. Let's focus on Quark SE devboard which has a CC2520 chip hard-wired in it)

Note:

• There are 2 SPI controllers in quark SE, masters only.
• Let's focus on the mmapped controller first

This is a necessary part to reach 802.15.4 hardware support

(Imported from Jira ZEP-17)

3-Wire UART (H:5) support

Reported by Javier B Perez:

HCI driver for 3-Wire UART (H:5) controllers.

(Imported from Jira ZEP-15)

Update DTLS to use tinycrypt

Reported by Javier B Perez:

from tinydtls, remove own encryption and replace with the calls to tinycrypt

(Imported from Jira ZEP-32)

Support TI CC2550 SPI based 802.15.4 chip

Reported by Javier B Perez:

This will be the primary 802.15.4 hardware to be supported.

• It is an SPI driven chip
• contiki support exists, so it might be possible to back-port some or most of the driver logic from there

(Imported from Jira ZEP-16)

Bluetooth LE dual mode topology

Reported by Javier B Perez:

LE dual mode topology

(Imported from Jira ZEP-27)

Arduino 101 GPIO_INT_LEVEL not working as expected

Reported by Javier B Perez:

Configuration

x86
Arduino 101
micro, nano

Bug detailed description

(Brief description in one sentence.
Detailed description follows.)

Testcase to Reproduce

Steps to Reproduce

1.Download attached test case
2. make BOARD=arduino_101 APP=test_gpio_pin_io2_callback_level_active_high flash
3. connect IO2 to 3.3V

Expected Result

it should continuouly report "callback triggered: xxx"

Actual Result

It only report once

User Impact

(Imported from Jira ZEP-7)

802.15.4 end to end test

Reported by Javier B Perez:

802.15.4 end to end test

(Imported from Jira ZEP-24)

Enable SSP mode

Reported by Javier B Perez:

Enable SSP mode

(Imported from Jira ZEP-46)

Demonstrate IP/6LoWPAN/15.4 stack running on reference hardware

Reported by Javier B Perez:

Reference hardware = either
Galileo2 with the TI2520 connected to SPI
OR
Arduino101 with TI2520

(Imported from Jira ZEP-25)

Service Discovery Protocol server (SDP)

Reported by Javier B Perez:

Design and implementation of Service Discovery Protocol server

(Imported from Jira ZEP-36)

Enable Pair context

Reported by Javier B Perez:

Enable Pair context

(Imported from Jira ZEP-40)

Refactor accessibilty of security handlers

Reported by Javier B Perez:

Encryption Changed Event handler,
BR/EDR security level update,
Pause/Resume Encryption,
Encryption Key refresh

(Imported from Jira ZEP-41)

Arduino 101 AIO not working as expected

Reported by Javier B Perez:

Configuration

x86
Arduino 101
micro, nano

Bug detailed description

AIO not working as expected, no callback is triggered

Testcase to Reproduce

attached

Steps to Reproduce

1. Connect A0 to ground with resistor 1.5k
2. make BOARD=arduino_101 APP=dw_aio_comparator_test flash
3. Wait when DUT says "waiting for event", disconnect A0 from ground

Expected Result

callback should be triggered

Actual Result

no callback triggered

User Impact

AIO is not working

(Imported from Jira ZEP-6)

LE L2CAP connection-oriented channels

Reported by Javier B Perez:

Add support to LE Credit Based connections

(Imported from Jira ZEP-22)

Link Key notification handling

Reported by Javier B Perez:

Link Key notification handling

(Imported from Jira ZEP-43)

SPI write API fail to return

Reported by Javier B Perez:

Configuration

x86,
Arduino 101 ,
micro,

Bug detailed description

SPI write fail to return.

Testcase to Reproduce

Download attach tar ball.
test_spi_master_write_1_to_arduino_spi

Steps to Reproduce

1.Download attachment and uncompress it.
2.Connect Arduino 101 SPI with Arduino DUE SPI.
3. flash Arduino DUE program(in tar ball Arduino folder.).
4. flash test_spi_master_write_1_to_arduino_spi to Arduino 101
5. open one serial console (screen /dev/ttyACM0) (dev ID may be different)
6. input "spi_read 10 1" to the Arduino serial console.

Expected Result

Arduino SPI write API return after write data to slave.

Actual Result

Arduino SPI write API fail to return.

User Impact

Softer ware hang after call spi_write API.

(Imported from Jira ZEP-5)

BT 4.2 Controller-based link-layer privacy

Reported by Javier B Perez:

Using btmon see that controller-based (link layer) privacy is used

(Imported from Jira ZEP-21)

LE privacy 1.2

Reported by Javier B Perez:

Support for local privacy

(Imported from Jira ZEP-30)

@Lakemont failed to receive profiler events, with printk @Arc after fiber_start

Reported by Javier B Perez:

Configuration

x86, arc
Arduino 101
micro, nano

Bug detailed description

To reproduce this issue, both @lakemont and @arc need to be flashed respectively with specified test app. @lakemont the profiler test case is flashed, while @arc a specific "hello" app is flashed.
What we observed is, the "printk" invoked after a "fiber start" @arc, finally leads to profiler case failed @lakemont.

        task_fiber_start(...);
        printk("main: Hello World!\n");

NOTE: commenting out "task_fiber_start" from @arc, the case passed @lakemont.
NOTE: removing a few chars from the printing message @arc, the case passed @lakemont
Surprising, please take a loot at what happens behind.

Testcase to Reproduce

Attached the test case to reproduce

Steps to Reproduce

1. cd zephyr
2. source zephyr-env.sh
3. download and untar attached test cases "test_profiler.tgz"
   forto-collab$ tar -zxvf test_profiler.tgz
4. cd test_profile_context_switch_event
   make pristine;make BOARD=arduino_101
   zflash -b arduino_101 outdir/lakemont.bin
5. cd ../test_hello_arc
   make pristine;make
   zflash -c -b arduino_101 outdir/arc.bin
   reported the latest zflash repo is broken. You probably need fetch an older revision.
6. verify from UART output @lakemont profile test stuck at waiting for events.

Expected Result

tc_start()
Register and wait event ...
start work task
...
PROJECT EXECUTION SUCCESSFUL

Actual Result

tc_start()
Register and wait event ...
start work task

User Impact

This issue tells printk in specific usage @arc affecting profiler events @lakemont. It may suggest something unexpected related to dual CPU collaboration. (this's one of next focus in QA testing, extending to ARC, then dual CPU collaboration testing)

(Imported from Jira ZEP-10)

HCI init for BR/EDR

Reported by Javier B Perez:

HCI init for BR/EDR

(Imported from Jira ZEP-35)

BLE: Provide more sample applications

Reported by Javier B Perez:

We need better coverage for growing number of Kconfig options.

(Imported from Jira ZEP-14)

software hang at printk with "CONFIG_STACK_CANARIES=y"

Reported by Javier B Perez:

Configuration

x86
arduino_101
micro

Bug detailed description

Run sample test code "zephyr/tests/kernel/test_stackprot/microkernel" @Arduino_101 board, software hang at printk.
NOTE1: If disable "CONFIG_STACK_CANARIES=y", issue is not observed.
NOTE2: The issue is not observed with qemu_x86, even with "CONFIG_STACK_CANARIES=y"

Testcase to Reproduce

sample test code "zephyr/tests/kernel/test_stackprot/microkernel"

Steps to Reproduce

1. cd zephyr
2. source zephyr-env.sh
3. cd tests/kernel/test_stackprot/microkernel
4. make pristine;make BOARD=arduino_101 flash
5. verify from UART output nothing.

(gdb) b RegressionTask 
Breakpoint 1 at 0x400332af: file /home/sharron/workspace/views/iot/forto-collab/samples/microkernel/test/test_stackprot/src/stackprot.c, line 145. 
(gdb) c 
Continuing. 
target running 
target is still running! 
hit hardware breakpoint (hwreg=0) at 0x400332af 

Breakpoint 1, RegressionTask () 
at /home/sharron/workspace/views/iot/forto-collab/samples/microkernel/test/test_stackprot/src/stackprot.c:145 
145 { 
(gdb) c 

software hang here. Press ctrl+c to stop, and check from gdb:

^C 
Program received signal SIGINT, Interrupt. 
_vprintk (ap=0xa800a000 <__REGRESSIONTASK_stack+2024> "\353\067\003@\020\240", 
fmt=0x40033816 "%s\n") 
at /home/sharron/workspace/views/iot/forto-collab/misc/printk.c:79 
79 while (*fmt) { 
(gdb) l 
74 { 
75 int might_format = 0; /* 1 if encountered a '%' */ 
76 
77 /* fmt has already been adjusted if needed */ 
78 
79 while (*fmt) { 
80 if (!might_format) { 
81 if (*fmt != '%') { 
82 _char_out((int)*fmt); 
83 } else { 
(gdb) p *fmt 
$1 = 37 '%' 
(gdb) bt 
Python Exception <type 'exceptions.ImportError'> No module named gdb.frames: 
<span>#</span>0 _vprintk ( 
ap=0xa800a000 <__REGRESSIONTASK_stack+2024> "\353\067\003@\020\240", 
fmt=0x40033816 "%s\n") 
at /home/sharron/workspace/views/iot/forto-collab/misc/printk.c:79 
<span>#</span>1 printk (fmt=0x0) 
at /home/sharron/workspace/views/iot/forto-collab/misc/printk.c:165 
<span>#</span>2 0x400332af in AlternateTask () 
at /home/sharron/workspace/views/iot/forto-collab/samples/microkernel/test/test_stackprot/src/stackprot.c:126 
<span>#</span>3 0xa800a004 in __REGRESSIONTASK_stack () 
<span>#</span>4 0x400332c1 in RegressionTask () 
at /home/sharron/workspace/views/iot/forto-collab/samples/microkernel/test/test_stackprot/src/stackprot.c:146 
<span>#</span>5 0x400337eb in ?? () 
Backtrace stopped: previous frame inner to this frame (corrupt stack?) 
(gdb) 

Expected Result

UART output:
PROJECT EXECUTION SUCCESSFUL

Actual Result

UART output nothing, software hang at printk.

User Impact

When app call printk with stack protection enabled, software hang.

(Imported from Jira ZEP-3)

Enable User/App context during pairing

Reported by Javier B Perez:

Enable User/App context during pairing

(Imported from Jira ZEP-39)

SPI read API fail to return

Reported by Javier B Perez:

Configuration

x86
Arduino 101
micro

Bug detailed description

SPI read API fail to return

Testcase to Reproduce

Download attachment tar ball.
test_spi_master_read_1_byte_from_arduino_spi

Steps to Reproduce

1.Download attachment and uncompress it.
2.Connect Arduino 101 SPI with Arduino DUE SPI.
3. flash Arduino DUE program(in tar ball Arduino folder.).
4. flash test_spi_master_read_1_byte_from_arduino_spi to Arduino 101
5. open one serial console (screen /dev/ttyACM0) (dev ID may be different)
6. input "spi_write 10 3 1" to the Arduino serial console.observed/captured

Expected Result

SPI read API return after read data from slave

Actual Result

SPI read API fail to return after read data from slave

User Impact

Softerware hang after call spi_write API.

(Imported from Jira ZEP-2)

IPSP node support

Reported by Javier B Perez:

IPSP leaf node support

(Imported from Jira ZEP-19)

low level memory I/O routines

Reported by Javier B Perez:

Add a generic API for low level memory I/O routines.

• these should under sys_ namespace
• should be re-definable

Current approach:

sys_inX()/sys_outX() where X is the size of the memory chunk in bits:
sys_in8, sys_out8, sys_in16, sys_out16, sys_in32, sys_out32

(Imported from Jira ZEP-13)

Add CoAP support to IP stack

Reported by Javier B Perez:

Port coap-er support from netcontiki stack to Zephyr IP stack.

(Imported from Jira ZEP-38)

Handle incoming (as acceptor) pairing / bonding

Reported by Javier B Perez:

Handle incoming (as acceptor) pairing / bonding

(Imported from Jira ZEP-34)

footprint benchmarks are not enabled on all arches

Reported by Hirally Santiago:

We don't do footprint checks on a lot of arches:
footprint-reg and footprint-max are only run on x86, they are not run at all on ARC and ARM
foorprint-min is skipped on Galileo
footprint-max is skipped on Minute IA
This is unacceptable. We need effective footprint metrics for all boards, all arches. If there is arch-specific code in the footprint tests they need to be revised.

(Imported from Jira ZEP-51)

create QEMU target which builds with IAMCU

Reported by Hirally Santiago:

We could catch a lot of IAMCU calling convention issues if we had an emulated target that built with this compiler.

Add a new board type qemu_x86_iamcu which identical to the standard x86 QEMU configuration, but builds with IAMCU abi.

Add this to sanitycheck such that we run test cases on this target when 'sanitycheck --all' is invoked.

(Imported from Jira ZEP-50)

x86: unify separate SysV and IAMCU code

Reported by Hirally Santiago:

We have parallel implementations of some interrupt and swap code in arch/x86/core/i386_sysV_abi and iamcu_abi.

The iamcu versions are written in C and are easier to understand/maintain. It would be nice if we can use the C version in both ABIs, and not have to maintain two different implementations; once execution flow transitions from assembly to C domain they should be the same.

However, at the end of the day what we would like to have is just one implementation (either C or ASM) that is #ifdefed instead of 2 completely parallel implementations.

(Imported from Jira ZEP-49)

Refactor keys handling

Reported by Javier B Perez:

Add interfaces to finding / creating BR/EDR link keys in keys in-memory storage

(Imported from Jira ZEP-44)

Task does not run after device_sync_call_complete() from a driver

Reported by Javier B Perez:

Configuration

any quark_se based board

Bug detailed description

A task calls any synchronous driver call (in our case spi, but it could happen elsewhere).

• the inner driver call runs a device_sync_call_wait() and thus task is waiting for the synchronous call to return
• once completed the isr in the driver calls device_sync_call_complete(), releasing the lock from original call thus the former device_sync_call_wait() returns, and then the task can run further.

===> The task hangs on the call though device_sync_call_complete() has been called.

Note: this NEVER happen when the caller context is a fiber! (thus this never happens in nanokernel obviously)

Testcase to Reproduce

See attached app

Steps to Reproduce

1. compile and flash the test_sync app
2. run the target
3. see the output

Expected Result

It should print:
Transceiving
Transceive complete
Result fine

Actual Result

It hangs on "Transceiving"

User Impact

Any synchronous calls cannot be made from a task, this is a big issue!

(Imported from Jira ZEP-1)

Implement Environmental Sensing Profile sample app

Reported by Javier B Perez:

Prepare sample application that implements environmental sensing profile

(Imported from Jira ZEP-33)