There is a flaw with I2C communication to peripherals behind the shub
that causes sporadic failures. Especially calls to configure a device
after the lsm6dso initialization is finished, e.g. to set the ODR, can
fail to work correctly.
Access to shub peripheral registers is done by putting the parameters of
the operation into SLV0 and then waiting for the lsm6dso to perform the
xfer on the shub I2C bus. The lsm6dso does this in sync with the
accelerometer update rate. Once the shub is enabled, it peforms the
xfer repeatedly as the accelermeter is sampled.
The wait has a problem: It might detect that a previous shub xfer has
finished, which was done before SLV0 was programmed with new parameters.
The shub status register is read-to-clear. This isn't in the data sheet
or app note, but it is. By reading the status before enabling the
sensor and after programming SLV0, we can be sure when it becomes set it
has finished the current operation and not a previous one.
Also set the write-once flag before shub init. This causes the shub to
only perform I2C writes once instead of continuously. This was set at
the end of init, so any writes done during it would repeat until the
shub was disabled.
Put a timeout in the code that polls for the sensor hub op complete. It
could possibly poll forever. More importantly, if there is no device
connected to the sensor hub, the lsm6dso does not timeout on the
operation for ~13 seconds. Since the shub init does a probe for devices
on startup, this will happen if shub support is enabled but a lsm6dso
has no sensor hub devices. There could be multiple devices, some with
additional sensors and some without. Initialization of the devices
without additional sensors takes tens of seconds without this timeout
being added.
Add a 300 µs wait after disabling the sensor hub. This is necessary
according to the ST app note AN5192 §7.2.1.
Read the shub status from the main bank register instead of the shub
bank register. This avoids an extra bank switch before and after each
status poll. Actually two bank switches on each side, since the lsm6dso
driver switched banks and then the ST HAL function to get the status
register switches again.
The wait for the shub I2C transaction to finish is not needed when the
shub is enabled at the end of init. We aren't starting a new I2C write
or reading the result of a read.
Signed-off-by: Trent Piepho <trent.piepho@igorinstitute.com>
The lsm6dso initialization will fail if the device is not already set to
the user register bank. All the registers used will be the wrong ones
from whatever bank it is in, e.g. sensor hub bank. This includes the
registers to reset the device!
The bank will default to the user bank on reset, but the chip has no
hardware reset line. On a reboot it will be in whatever bank it was
last in. If the sensor hub is enabled, it will switch banks on every
sample, so it's entirely possible to reset or reboot when it happens
to be set to the sensor hub bank, which will cause the driver to
fail to initialize. It will not work again until the lsm6dso is power
cycled.
Signed-off-by: Trent Piepho <trent.piepho@igorinstitute.com>
Per an ST app note, the sensor hub I2C controller should be disabled
before doing a software reset. Possibly, this is because the sensor hub
could be in the middle of the an I2C transaction to a sensor when it is
reset. Disabling it and then waiting makes sure it has quiesced before
resetting.
Signed-off-by: Trent Piepho <trent.piepho@igorinstitute.com>
The initialization code would configure the lsm6dso interrupt, then
configure the rest of the chip. The chip init includes a reset that
would undo the register setting done during interrupt configuration.
It's also not a good idea to enable the interrupt on the SoC when the
lsm6dso has not yet been reset or configured. It might be generating
interrupts.
The lsm6dso has no hardware reset line, so it will not be reset on
reboot unless a power cycle is involved.
Signed-off-by: Trent Piepho <trent.piepho@igorinstitute.com>
The parameter doc string for hda was incorrect as the parameters
had been updated to take the IP base address, block size, and stream id
instead. Updates all doc string comments to account for the change.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The DMA API contract specifies that start/stop may be called multiple
times. Prior to adding power management this was perfectly fine as it was.
In adding power management, there are additional side effects that can
cause issues. Instead check the state of the channel prior to start/stop
and do nothing if already in the desired state.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Ensures that the documented behavior of the API is met by implementations
through testing. By calling stop on a stopped channel the expectation is no
error occurs and is checked.
Calling start after a channel has been started is difficult to test for
as there is transfer timing involved. A once shot transfer may have
completed and the channel transition to an inactive state by itself by
the time the second start call is performed. This isn't supported by at
least gpdma today and isn't documented behaviorally so should not be
tested.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The DMA API expects drivers in effect to maintain their own internal
state of channels. A channel that is already started may have dma_start
called on it again without effect. A channel that is already stopped may
have dma_stop called on it without effect.
In essence, start and stop are expected to act like events a DMA channels
finite state machine reacts to and if the state is already at the desired
one then nothing is to be done and no error has occurred.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Currently, the s32z270dc2_r52 board only supports running on RAM,
so samples or tests watchdogs that perform SoC reset will not produce
results. Set the build only for these samples and tests until the
reset SoC function is supported.
Signed-off-by: Quang Bui Trong <quang.buitrong@nxp.com>
`<fcntl.h>`, `<net/if.h>`, and `<netinet/tcp.h>` were missing
`extern "C" { .. }"` which is required to avoid C++ name
mangling.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Add a trivial suite that simply ensures headers exist and that
they supply standard symbols and constants.
These tests are intended to be ordered exactly as the respective
feature appears in the respective specification at
https://pubs.opengroup.org/onlinepubs/9699919799
Over time, as POSIX support improves, we can enable additional
checks.
If `CONFIG_POSIX_API=n`, then we simply ensure that the header
can be included, that constants and structures exist, including
the existence of required fields in each structure.
We check that a constant exist, by comparing its value against
an arbitrary number. If the constant does not exist, it would
of course be a compile error.
```
zassert_not_equal(-1, POLLIN);
```
We check that a structure contains required fields by
comparing the field offset with an arbitrary number. If
the field does not exist, of course, there would be a
compile error.
```
zassert_not_equal(-1, offsetof(struct pollfd, fd));
```
For non-scalar constants, we simply attempt to assign
a value to the specific type:
```
struct in6_addr any6 = IN6ADDR_ANY_INIT;
```
If `CONFIG_POSIX_API=y`, then we additionally check that required
functions are non-NULL (limited to what is currently supported in
Zephyr).
```
zassert_not_null(pthread_create);
```
Note: functional verification tests should be done outside of this
test suite.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The POSIX spec requires that `SO_LINGER`, `SO_RCVLOWAT`,
and `SO_SNDLOWAT`, and `SOMAXCONN` are defined in
`<sys/socket.h>`. However, most of the existing socket
options and related constants are defined in
`<zephyr/net/socket.h>`.
For now, we'll co-locate them. It would be
good to properly namespace things.
Additionally, a no-op for setsockopt for `SO_LINGER` to
make things Just Work (TM) for now.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `<netdb.h>` header typically defines `NI_MAXSERV` as a
reasonable default buffer size to use in applications that
use `getnameinfo()` to query a service name.
Most GNU and BSD systems define it by default so provide
it as a convenience so applications and 3rd-party libraries
do not encounter a compile error.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The spec requires `<sys/socket.h>` to declare
struct linger. Define it so that applications
and libraries do not get compile errors when
building against Zephyr.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `FIONREAD` ioctl is usually used to query how many bytes
are available to read immediately from a specific file
descriptor. It's quite useful.
Define it here so that it can be used by applications.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Constants like `EAI_SYSTEM` should be defined in `<netdb.h>`
according to the spec.
In Zephyr, they should be defined via appropriately
namespaced z-variants (currently `DNS_EAI_SYSTEM` and so on).
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The spec requires that `in_addr_t` and `in_port_t` are both
defined when `<arpa/inet.h>` is included.
They were added to `<netinet/in.h>` in the previous commit.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `<sys/ioctl.h>` header never actually declared
the `ioctl(2)` function prototype, so this fixes that.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The networking subsystem defines a rather large amount of POSIX
prototypes. However, it's done in a somewhat subversive way via
```
CONFIG_NET_SOCKETS_POSIX_NAMES
```
This option should be removed (or moved to POSIX) and the
networking implementations should be properly namespaced.
With that, the POSIX interface for network-related functions
can simply be a thin wrapper around the z-namespaced variants,
where applicable, or proper POSIX functions should actually
be moved to `lib/posix`.
This will also require a better solution to testing network
functionality on `native_posix` though. The ability to run
those tests and the supposed incompatibility between
`CONFIG_ARCH_POSIX` and `CONFIG_POSIX_API` was the main
motivation for adding `CONFIG_NET_SOCKETS_POSIX_NAMES`.
Eventually, with proper namespacing, these preprocessor
guards against redefining the same symbols can be
removed.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Although the eventfd API is not (yet) a part of POSIX,
it's pretty well ubiquitous on POSIX systems now.
Enable it by default when `CONFIG_POSIX_API=y`.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The `getopt()` function is part of POSIX and should be
available when applications choose to enable general POSIX
API support.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
With the `<zephyr/posix/...> prefix, it became
exponentially more difficult to integrate 3rd-party
libraries that depend on the POSIX API.
Standard POSIX headers should be available in standard
include paths - and that should most certainly the case
when `CONFIG_POSIX_API=y`.
With this change:
* When `CONFIG_POSIX_API=y`
- applications have explicitly chosen to use
POSIX APIs.
- all standard POSIX includes are in the default
include path.
* When `CONFIG_POSIX_API=n`
- applications *may* include POSIX headers
explicitly with the namespaced prefix
- e.g. `#include <zephyr/posix/unistd.h>`
- individual Kconfig options can be used to
enable POSIX features selectively, such as
`getopt` or `eventfd`.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
When transceiver is overload on reception a frame can be stored on
the internal buffer without processing a frame start interrupt. The
frame will complete and system will received a interrupt and signal
receiver thread with an isr_status equal to 0x2c.
The current implementation process one flag at time and it may hang
when status is 0x2c. This issue can be reproduced using two nodes
where one perform a regular TX broadcast and tThe other one should
be wait for frames. The receptor should run on debug mode and system
should be started normally. The problem happens when pressing CTRL+C
on the debugger, which will cause system to stop. However, the
transceiver still can receive one last frame. After a few transmission
user can continue application and a isr_status of 0x2c will be visible
if CONFIG_IEEE802154_DRIVER_LOG_DEBUG is enabled.
This fixes the current issue by processing all RF2XX_TRX_END events.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Since SHIELD_DIRS gets added to DTS_ROOT in dts.cmake, any shield
directories are also places where we look for bindings by default.
This feature is not used in upstream Zephyr, but it is supported,
so document it.
Suggested-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
We have established a convention that the zephyr, prefix in property
names indicates some sort of zephyr-specific extension to a common
binding, or a zephyr-specific driver configuration knob. We also have
established a convention that compatibles which begin with "zephyr,"
are specific to our operating system. Document these facts.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Splitting up the 'general rules' section into subsections makes it
possible to link directly to a particular rule. This is useful when
pointing out an issue during code review, sharing with another
colleague, etc. Adding a local table of contents makes the page
skimmable (it's buried too deeply in the toctree to have sections
listed in the HTML sidebar).
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Now that this information is in a separate page instead of buried at
the bottom of the DT bindings documentation, it's more convenient to
split it up into subsections for readability.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
There's been some confusion about what we mean by hardware
description. We're really talking about the user-facing inputs that
need to be configured per SoC, application, etc. It's fine to do
things like use ifdeffery on a CMSIS header in an aarch32 support file
to decide if the current target has some feature, for instance -- that
sort of thing doesn't *have* to come from DT.
At the same time, we don't want to encourage vendor-specific hardware
configuration languages from creeping into upstream zephyr, so keep
the language strong in an effort to avoid that misinterpretation.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Phandles, specifier spaces, and cell names are simultaneously
extremely common and woefully underdocumented. Address that by:
- reworking our existing documentation on these subjects in
bindings-syntax.rst, fixing missing information in the
property syntax template as well
- adding a standalone guide which describes how all the pieces
fit together, providing a bridge for the gap between
DTS/bindings and C APIs
My goal is not to eventually make this a comprehensive place
where *all* specifier spaces are documented. It would be better (more
scalable, more discoverable) to improve the individual API pages to
cover the devicetree-related conventions that apply in each case.
That's a problem for someone else and another day, but we do need a
few concrete references in the DTS guides to keep the motivation
clear.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The devicetree introduction page is too big. Split it up to improve
readability and restore maintainability. Add more section headers and
do some other rearranging now that it's more convenient to do so.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Generic improvements:
- clean up some language that needs adjusting
- rename some section headers and reorder some content to
improve readability
- add a table of contents to ease search
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The bindings.rst page has gotten too big. Split it up into
sub-documents to improve readability and restore maintainability.
As part of this effort, move the /zephyr,user node documentation into
its own page in the guide. This page has proven extremely difficult
for users to spot in my experience, and it's meant as a convenience,
so let's make the documentation more convenient as well.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Use the macro as defined by the
include/zephyr/dt-bindings/dma/stm32_dma.h to configure the
dma channel.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Use the macro as defined by the
include/zephyr/dt-bindings/dma/stm32_dma.h to configure the
dma channel.
Use the STM32_DMA_PERIPH_TX or STM32_DMA_PERIPH_RX value.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Defines DMA macro to help channel configuration and feature for the stm32
devices. Add one default value for most of the usecases
of peripheral DMA settings.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
