- 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>
This implements a driver for the pin multiplexer as present in the ESP32
SoCs.
All APIs are supported.
Jira: ZEP-2297
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
According to the "ESP32 Technical Reference Manual", the ESP32 SoC
series supports up to 6 functions per GPIO pin. Add PINMUX_FUNC_E and
PINMUX_FUNC_F.
Jira: ZEP-2297
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
- board name olimex_stm32_p405
- CPU STM32F405RGT6 Cortex M4
- LED/BUTTON support
- Console on USART2 with 8n1 115200 baud
Signed-off-by: Erwin Rol <erwin@erwinrol.com>
This patch adjusts the ARM MPU implementation to be compliant to the
recent changes that introduced the opaque kernel data types.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This patch always defines the ARCH_THREAD_STACK_XXX macros/functions
regardless of the MPU_STACK_GUARD usage. Only use MPU_STACK_GUARD when
determining the minimum stack alignment.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Following test changes, log info have changes and previous log info
with stack guard present shows an mpu error not caused by a stack
overflow caught by mpu stack guard feature.
Signed-off-by: Michel Jaouen <michel.jaouen@st.com>
This test launches several threads. Only last thread will overflow the
stack and an mpu exception will occur. The other threads are regulary
suspended, this triggers access to kthread structure. This tests is
failed on st and nxp platform, if 32 bytes alignement is not set.
Signed-off-by: Michel Jaouen <michel.jaouen@st.com>
The mimimum mpu size is 32 bytes, but requires mpu base address to be
aligned on 32 bytes to work. Define architecture thread macro when
MPU_STACK_GUARD config to allocate stack with 32 more bytes.
Signed-off-by: Michel Jaouen <michel.jaouen@st.com>
The alignment went off because of the move to use internal fixed-size
integer types (instead of standard int types).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
It used to be that there was a fairly empty "Bluetooth Drivers" menu
entry in the drivers menu. This entry was present even though there
was no drivers/bluetooth code being compiled in.
With this patch "Bluetooth Drivers" will no longer be present when
BT_CONTROLLER is enabled.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The CONFIG_BT_WAIT_NOP define is used only by
zephyr/subsys/bluetooth/host/hci_core.c.
It is also the only config in drivers/bluetooth that is in use when
BT_CONTROLLER is enabled. Moving it into the bluetooth subsystem
allows us to restructure the drivers/kconfig code such that the entire
Bluetooth driver menu option is omitted when the BT_CONTROLLER is
enabled.
Moving it will also mean that all configs in drivers/bluetooth will
now be related to configuring the source code in drivers/bluetooth.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
In the stm32_gpio_flags_to_conf function the configuration
values of the GPIO pin are shifted two times. One in the
stm32-pinctrlf1 header and one in the function. This patch
removes one of those shifts.
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
shell_exec expects a string that is null-terminated but if line passed
to strncpy is equal or bigger than the buffer it will not produce a
null-terminated command.
Jira: ZEP-2474
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The value of the PTE (starting_pte_num) was not
calulated correctly. If size of the buffer exceeded 4KB,
the buffer validation API was failing.
JIRA: ZEP-2489
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Added function helps setting the longest possible rx and tx buffers for
single SPI transfer. Each of these buffers is a continuous memory
region. It is useful for example when peripheral supports easyDMA.
Signed-off-by: Michał Kruszewski <michal.kruszewski@nordicsemi.no>
