Log_core test was failing due to test structure elements not being
correctly reset before the test.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The 'value' param in ACCESS_BY_PORT mode means the state of a port,
one bit represented one pin in param 'value'.
Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
This API shouldn't take a int type but instead it should take
u32_t. This argument has to be similar to irq_lock() and
irq_unlock().
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch removes the typecast (void*). This can be better
handled by typecasting to the actual typdef. This fixes the
misra rule of 11.6 for alert.
Part of GH-10042.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Python's open() by default using "system character encoding", which
may vary from system to system (e.g. LOCALE=C aka "ascii" on bare-OS
systems, something on Windows, etc.). But Zephyr files are utf-8, so
read them as such, by explicitly specifying encoding.
This is similar to changes earlier done to another script in 94620bd.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Check for NULL IPv6 addr values from net_if_ipv6_get_ll() in rpl.c
If NULL, print out an error statement stating that no proper IPv6
address was found
Coverity-CID: 188169
Fixes#10094.
Signed-off-by: Satya Bhattacharya <satyacube@gmail.com>
Improve the error feedback when calling bt_le_adv_start and inputting
too much data in the advertisement.
Error feedback before:
Bluetooth initialized
Advertising failed to start (err -22)
Error feedback after:
Bluetooth initialized
[bt] [ERR] set_ad: Advertising data does not fit in buffer
Advertising failed to start (err -22)
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Some new yaml bindings that got committed added back in the 'id:' field
which we have removed. Remove it from those dts binding files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add support for ST Micro Nucleo-64 board with the STM32F302R8
processor. nucleo_f429zi and nucleo_f334r8 were used as
references.
Signed-off-by: Galen Seitz <galens@seitzassoc.com>
Add pin muxing for STM32F302x8 by sharing most of the definitions
of the STM32F303xC. Add USART3 for both the 302x8 and the 303xC.
Add a PWM that is specific to the 302x8.
Signed-off-by: Galen Seitz <galens@seitzassoc.com>
This is a new test and we have riscv32 failing on that all of the
sudden. Disabling while we look into it and identify if that is a
testcase issue or not.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add console harness support for USB mass storage test.
Also, using overlay config for DISK_ACCESS configuration
and accessing the different config file with different
method.
Signed-off-by: Ajay Kishore <ajay.kishore@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introduces the location property and adds the ability to use values
generated by the device tree configuration.
Signed-off-by: Diego Sueiro <diego.sueiro@gmail.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Use user data to replace DMA's device pointer in
the callback function so that the user can retrieve
its context by that private data.
Signed-off-by: Jun Li <jun.r.li@intel.com>
The first argument in DMA callback can be set to
arbitrary user data instead of DMA device pointer
so the user can pass its private context
in the callback function.
Signed-off-by: Jun Li <jun.r.li@intel.com>
For the 'app' build scripts to be able to do post-processing on the
elf file they need to know what the target name for the elf file is.
In zephyr this name varies depending on whether one does a single or
multiple link, so we export a variable with the name.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
I committed a user error and edited a file named in the sphinx output
to correct an error. To my dismay later, I discovered my work had been
lost as that file is not versioned.
Warn the others.
Signed-off-by: Marti Bolivar <marti@foundries.io>
In a clean build, Ninja is creating copies of the extracted
documentation outputs regardless of whether they already exist or
not. I can't explain this behavior from the documentation of the build
command, but it's so, even if extract_content.py is patched to use
copyfile() instead of copy2() so that outputs (copied .rst files in
the build directory) have strictly newer mtimes than inputs (source
tree .rst files).
This extra copying doesn't happen for incremental builds, for some
reason.
To account for this behavior, add and use an extract_content.py option
that skips content extraction completely and leaves that all up to the
add_custom_command() which tracks each individual input->output build
command.
Reported-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Marti Bolivar <marti@foundries.io>
In tickless mode, not all elapsed ticks may have been announced yet,
so future z_time_slice() calls will include "extra" ticks that we have
to account for when setting up the slice count.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Our funny convention holds that passing ticks==1 to _add_timeout()
means "at the next tick". But that means that 1, 0, and all negative
numbers are expected to behave the same. In ticked mode, that's fine
because it will, after all, expire at the next tick.
But in tickless, the next announcement may be for several ticks, and
that zero will appear to expire "before" the next tick in the
consumption loop.
Make sure all "next tick" expirations look the same.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume that on idle the CPU would wake up on
the next tick boundary because of the timer interrupt. No such
interrupt arrives in tickless mode and it hangs forever.
A more whiteboxy test involving setting a clock timout will have to be
written for this feature if we want to keep it on tickless systems.
Alternatively we could move this test out of tests/kernel/context and
always disable tickless.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When fetching the next timeout to expire, the value is relative to the
last announced tick, so you subtract the timer-provided elapsed time
to get the true delta from "now". When adding a new timeout, you
*have* a value relative to now, so you compute the delta vs. the last
announced tick by adding the elapsed() time. Duh.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The theory behind this test seems to be that taking an IRQ lock should
prevent the advance of the kernel's tick counter. That works on
traditional timers only. In tickless mode the timer hardware/driver
is expected to be able to give us an answer for time independent of
interrupt delivery, so the test fails spuriously. The "bug" detected
is a feature of tickless!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was wrong in subtle ways. In tickless mode it's possible to get
an announcement for multiple ticks at a time and have multiple
callbacks to execute that were technically scheduled at different
times. We want to fix the current tick at the value represented by
the currently-executing callback's EXPIRATION (even if we missed it!),
so that any new timeouts it sets (c.f. a k_timer period) happen at the
right point, in phase with the expected series. In single-tick mode
the code ends up the same always, so the bug wasn't visible.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This wasn't explained correctly. The tick convention we use here
(owing to the way legacy code was written) is a little weird. Timeout
delays are passed in a "round down" sense, so that setting a timeout
in "one tick" means that the interrupt will arrive anywhere between
zero and one ticks in the future.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The previous comment correctly and carefully explained why the 64 bit
value in curr_tick doesn't require locking when reading only the low
32 bits.
It completely missed the fact that the calculation of elapsed time and
the read of curr_tick ABSOLUTELY DO require locking, because the
former is expressed in terms of the latter. This was always bug, even
in the old code, but never witnessed because we ran so little software
in tickless mode.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's possible to interrupt a thread that has already scheduled a
timeout. Really this is a race against the usage of
_add_thread_timeout() and needs some design work to provide proper
locking (which is a distinct requirement from the scheduler lock and
timeout lock!), as the users of that API are spread around the kernel.
But existing usage always schedules the timeouts first, so this is
safe.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The timeout APIs are properly synchronized now. This irq_lock() (and
the comment explaining it) isn't needed anymore.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These options are rapidly becoming a default configuration, which is
complicated by having them be hidden inside of a SYS_POWER_MANAGEMENT
variable that has to be enabled first. Put them at the top level of
the kernel config.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Clarify behavior of the ticks argument to z_clock_set_timeout() and
add an important note about expected behavior in SMP environments.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>