If the sys_rand32_get() returns large value, then we might
decrement the clock which is not intended in this test.
Fixes#8657
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Do not provide info message if node type, title, version,
node description is overwritten.
This is the expected behaviour.
Fixes#8360
Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
This commit refactors internal functions in arm_mpu.c to use
bitsets and functions taken directly from ARM CMSIS instead of
hardcoded arithmetic literals. In several internal functions
some part of the implementation is abstracted further in inline
functions or convenience macros, to facilitate extending the
arm_mpu.c for ARMv8-M. In addition, the commit adds minor
improvements in internal function documentation.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit abstracts the attribution generation for an MPU
region, determined based on a supplied configuration and the
given size, from the actual implementation, which is placed
in a separate inline function. This allows to have multiple
implementations of attribution generation for different ARM
MPU drivers.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit refactors the _region_init(..) internal MPU driver
function so it gets the region index and a struct arm_mpu_region
as aruments. The latter holds the MPU region configuration that
is to be applied to the region determined by the index argument.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit enforces conditional compilation of mpu_regions.c
in nrf52/CMakeLists.txt depending on whether ARM_MPU_NRF52X
K-option is defined.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This update to the latest master of mcumgr fixes a memory corruption in
the image management and updates the readme.
Fixes#7924
Origin: mcumgr
License: Apache 2.0
URL: https://github.com/apache/mynewt-mcumgr
commit: a837a731b94927c6198e39744cd6d979be23942a
Purpose: Fix memory corruption
Maintained-by: External
Signed-off-by: Johannes Hutter <johannes@proglove.de>
This patch adds I2C Slave support conforming to the syscalls and funcs,
only for the STM32 V2 I2C Driver for the moment.
It is capable of handling multi-master bus setups.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Wagenknecht <wagenknecht@clage.de>
Add a new test to make I2C transfers between an I2C controller and
an I2C slave driver, either by:
- Using a virtual I2C driver
- Using a physical link and 2 physical controllers
The Physical test uses :
- Two EEPROM Slave drivers each connected to one I2C controller
- Both I2C controllers also act as master and take turns writing
to the opposite EEPROM Slave.
All of this connected physically on the board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Wagenknecht <wagenknecht@clage.de>
Add a new EEPROM simulated driver with all it's build infrastructure.
The EEPROM can be loaded/poked from applications by getting its funcs.
It is multi-instance capable, right now 2 instances are supported by
enabling them in KConfig.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Wagenknecht <wagenknecht@clage.de>
This patchs adds new I2C Syscalls for :
- I2C controllers slave support
- I2C Slave drivers support
I2C Controllers slave support adds 2 new ops to :
- register new slave driver
- unregister slave driver
Slave funcs consists on all the I2C phases :
- read or write request once address matches
- read or write done once the byte has been received/sent
- stop when the trasmit stops
I2C Slave drivers syscall are also added to make new
"I2C Slave" drivers to :
- register them to their I2C controller
- unregister them to their I2C controller
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This patch restructures stm32_i2c_v2 drivers Interrupts:
- NACK failures trigger an I2C event interrupt, so move
handling of NACK failure from error isr to event isr.
- Extract logic of interrupt handling to static functions. Use
isr functions (event & error OR combined) to call these. This
reduces duplication between error isr and combined isr.
- Restructure the error interrupt handling, so that it has no effect
when no errors occured and thus can be called by combined isr.
- Change interrupt logic from if/else to pure ifs for each flag.
This reduces code paths and leads to one call of the isr handling
multiple interrupt conditions, if there's more than one I2C
interrupt flags set.
This is the way it's done e.g. in linux kernels (since 4.14)
drivers/i2c/busses/i2c-stm32f7.c
Signed-off-by: Daniel Wagenknecht <wagenknecht@clage.de>
In preparation to implementing slave and multi-master
capabilities for STM32 I2C V2 driver move the checks,
whether all messages of a transfer are valid, before
starting the transaction.
This prevents having to abort a transmission, that is
already partly transmitted.
Signed-off-by: Daniel Wagenknecht <wagenknecht@clage.de>
All the STM32F7 SoCs have a TRNG. Adding support for it is just a matter
of tweaking the #ifdef and including the right file from HAL.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
An empty packet on 2M phy is one more byte compared to 1M phy because
of the preamble.
The empty packet is then 11 bytes, which takes 44 us to transmit.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
This commit moves the _ms_to_ticks() and __ticks_to_ms() functions
close to each other in order to improve code readability.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
The kernel incorrectly assumed, that system timer frequency is always
divisible without remainder by couple "natural" tick rates (like 100).
As result on some SoCs, time calculations was not correct, producing
strange effects (invalid sleep times, incorrect k_uptime_get() etc.).
This commit enables accurate, but costly (using 64-bit math) tick <-> ms
conversion if the selected tick interval is not exact due to hardware
limitations.
Also, this commit fixes tests in which removed _ms_per_tick were used.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
This commit removes fixed list of "good" sys_clock_ticks_per_sec values
which usage results in integer _ms_per_tick value.
Instead of using the list, simply check if MSEC_PER_SEC could be divided
without remainder by sys_clock_ticks_per_sec.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
This commit moves all implementations of the _ms_to_ticks() into
single file. Also, the function is now inline even if
_NEED_PRECISE_TICK_MS_CONVERSION is defined.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
This commit moves the macro definitions and convenience wrappers
for ARM MPU that are specific to ARMv6-m, and ARMv7-m to an
arch-specific MPU header file. It leaves only the generic
content in arm_mpu.h, i.e. the content that is supposed to
be common for ARMv8-M MPU.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Duplicate the ARM MPU-related registers' definitions
specifically for Beetle SOC which is not compliant with
ARM CMSIS and does not include the ARM CMSIS headers.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit modifies the interal macro defitions for MPU region
attributes in arm_mpu.h to use bitset flags directly from CMSIS.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit removes the redundant HAL definition for the ARM
Cortex-M MPU registers, and modifies the ARM MPU driver
implementation to directly use the provided HAL from CMSIS.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The entry point can and therefore should be set by linker
scripts. Whenever possible one should express things in the source
language, be it .c or .ld, and not in code generators or in the build
system.
This patch removes the flag -eCONFIG_KERNEL_ENTRY from the linker's
command line and replaces it with the linker script command
ENTRY(CONFIG_KERNEL_ENTRY)
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Piggyback a missing 'source "drivers/gpio/Kconfig.imx"'. This file
wasn't included anywhere previously.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
