Implement the 4.2 event LE Directed Advertising Report, used for
scanners in a privacy-enabled controller to report directed advertising
events whose TargetA cannot be resolved by the local controller.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Add implementation to support PHY update procedure with
packet transmit time restrictions.
This fixes:
TP/CON/SLA/BV-49-C [Initiating PHY Update Procedure Packet
Time Restrictions]
TP/CON/SLA/BV-50-C [Responding to PHY Update Procedure
Packet Time Restrictions]
TP/CON/SLA/BV-52-C [Initiating PHY Update Procedure Packet
Time Restrictions, No Change]
TP/CON/SLA/BV-53-C [Responding to PHY Update Procedure
Packet Time Restrictions, No Change]
TP/CON/MAS/BV-49-C [Initiating PHY Update Procedure Packet
Time Restrictions]
TP/CON/MAS/BV-50-C [Responding to PHY Update Procedure
Packet Time Restrictions]
conformance tests in LL.TS.5.0.0.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
When you build application for em starterkit 2.3 em7d, it will
report error during build since it is not supported currently.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
em starterkit has two versions, 2.2 and 2.3.
Change soc.h to support both versions,
main changes are the interrupt connections.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
Since em starterkit has different firmware versions(2.2 and 2.3),
but the EM7D of 2.3 has new secureshield feature, which is not supported
in Zephyr, but EM7D of 2.2 is a normal EM core, which can be supported,
so we add support for 2.2 EM7D.
Signed-off-by: Huaqi Fang <huaqi.fang@synopsys.com>
Tests if preemptive threads are picked up as per priority.
This creates 10 threads with priority in increasing order
from 1 to N and each thread prints an Alphabet.
This test fails when threads are picked up out of order.
Jira: ZEP-2370
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
This creates 10 threads with equal priority and tests predictibility
of picking all threads in round robin fashion. Test fails when any
thread consumes more time than time slice allocated to it or threads
are not scheduled in round robin fashion.
Jira: ZEP-2371
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
This patch convert net test cases to use ztest framework APIs
which makes output unified to other test cases.
Signed-off-by: Punit Vara <punit.vara@intel.com>
This patch convert net test cases to use ztest framework APIs
which makes output unified to other test cases.
Signed-off-by: Punit Vara <punit.vara@intel.com>
- replaced test points with ztest APIs wherever possible
- replaced CONFIG_MAIN_STACK_SIZE with CONFIG_ZTEST_STACKSIZE
in config file, reduced size to 1024
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- replaced test points with ztest APIs wherever possible
- replaced CONFIG_MAIN_STACK_SIZE with CONFIG_ZTEST_STACKSIZE
in config file
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- replaced test points with ztest APIs wherever possible
- added CONFIG_ZTEST_STACKSIZE=320
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- replaced test points with ztest APIs wherever possible
- replaced CONFIG_MAIN_STACK_SIZE with CONFIG_ZTEST_STACKSIZE
in config file, reduced size to 896
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- replaced test points with ztest APIs wherever possible
- replaced CONFIG_MAIN_STACK_SIZE with CONFIG_ZTEST_STACKSIZE
in config file
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- replaced test points with ztest APIs wherever possible
- replaced CONFIG_MAIN_STACK_SIZE with CONFIG_ZTEST_STACKSIZE
in config file, reduced the size by half
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- replaced test points with ztest APIs wherever possible
- replaced CONFIG_MAIN_STACK_SIZE with CONFIG_ZTEST_STACKSIZE
in config file, reduced size by half
JIRA: ZEP-2249
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
The ESP-WROOM-32 board exits the bootloader at 40 MHz, not 160 MHz as
suggested by documentation. The CCOUNT special register works as
advertised, but not at the expected rate. This was verified by
timestamping (at the host) the output of a dependency-free loop that
looks like:
int key = irq_lock();
while(1) {
u32_t i, count;
volatile int dummy;
for(i = 0; i < 5000000; i++) {
dummy++;
}
__asm__ volatile ("rsr.ccount %0" : "=a"(count));
printk("%d\n", count);
}
The SoC has a fairly robust set of possible CPU clocking modes, but we
don't have a driver for that yet. Until we do, set the single
configured CPU frequency to the one we get at runtime.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
An abnormal crash was encountered in ARMv6-M SoCs that don't have flash
starting at 0. With Zephyr OS the reason for this crash is that, on
ARMv6-M the system requires an exception vector table at the 0 address.
We implement the relocate_vector_table function to move the vector table
code to address 0 on systems which don't have the start of code already
at 0.
[kumar.gala: reworderd commit message, tweaked how we check if we need
to copy vector table]
Signed-off-by: Xiaorui Hu <xiaorui.hu@linaro.org>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The hexiwear_k64 board can drive the leds with a pwm, so update the
rgb_led sample to work with this board.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The hexiwear_k64 board can drive the leds with a pwm, so update the
fade_led sample to work with this board.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The hexiwear_k64 board can drive the leds with a pwm, so update the
blink_led sample to work with this board. Reduces the maximum blinking
frequency from 500 Hz to 64 Hz because your eye can't distinguish these
higher frequencies (the led appears solidly on). Increases the minimum
blinking frequency from 0.5 Hz to 1 Hz because the mcux pwm driver can't
handle frequencies less than 1 Hz.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Now that we have an mcux shim driver, remove the old k64-specific
driver. Also remove include/drivers/k20_sim.h, since the old
k64-specific driver was the only thing left using it.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Switches the default pwm driver from the k64-specific driver to the
mcux shim, which can be used on other SoCs with the ftm peripheral.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
If the ftm driver is enabled, use an instance routed to the Arduino
header and configure the pinmux accordingly. Unlike the hexiwear_k64,
the pins routed to the RGB led cannot be muxed as ftm channels.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
If the ftm driver is enabled, use the instance routed to the RGB led and
configure the pinmuxes as ftm channels instead of gpios.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Adds a shim layer around the mcux ftm driver to adapt it to the Zephyr
pwm interface.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Adds common and Kinetis-specific pwm device tree properties, and updates
the k64 SoC and board dts files to include all four pwm nodes.
Jira: ZEP-2025
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
This cleans up the exception handling by removing the table declaration
from xtensa_intr_asm.S, and removing the unused
_xt_set_exception_handler() function.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The Xtensa port was the only one remaining to be converted to the new
way of connecting interrupts in Zephyr. Some things are still
unconverted, mainly the exception table, and this will be performed
another time.
Of note: _irq_priority_set() isn't called on _ARCH_IRQ_CONNECT(), since
IRQs can't change priority on Xtensa: while the architecture has the
concept of interrupt priority levels, each line has a fixed level and
can't be changed.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Dynamic IRQ allocation has been yanked from Zephyr a few releases ago,
so there's no point in keeping these options available.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The random number generator from ESP32 uses noise from Wi-Fi and
Bluetooth radios. If these are off, a pseudo-random number is
generated instead; this is currently the case, but even though it's a
black box, it's arguably better than returning a timestamp as a
pseudo-random number generator.
According to the ESP32 Technical Reference manual, the RNG passed the
Dieharder Random Number Test suite (version 3.31.1)[1], but nothing has
been said about the quality of the PRNG.
The RNG register is read directly; no effort is made to use its
contents to feed an entropy pool in a way that's similar to /dev/random
on POSIX systems, as no such subsystem exists on Zephyr at the moment.
[1] http://webhome.phy.duke.edu/~rgb/General/dieharder.php
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Zephyr's watchdog API is badly designed in the sense that it's a 1:1
abstraction on top of whatever Quark D2000 expects for its watchdog,
instead of expecting a generic timeout value.
This implementation tries as much as possible to calculate the watchdog
timeout in a way that's compatible with a Quark D2000 running at 32MHz;
a comment in adjust_timeout() explains this in more detail.
Jira: ZEP-2296
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This provides basic GPIO support, with interrupts, and the ability to
read and write to ports on a pin-by-pin basis.
Jira: ZEP-2286
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
