Zephyr supports ADCs with 16-bit resolution, but the ADC sample
displayed readings for such incorrectly due to too-small datatype
This commit fixes the ADC sample for ADCs with 16-bit resolution
Signed-off-by: Ben Marsh <ben.marsh@helvar.com>
Drop the non existing option PINMUX_XEC, this has been removed in
d76f4f2c8a drivers: pinmux: mchp_xec: drop driver
And is currently causing build errors.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This will make it more convenient to use it from multiple different
places, which we will have a need for in the future.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We need to have an _include_path attribute to pretty-print
this object from within pdb, for some reason. Add it.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
There's no need for _parse_node() to return the Node instance that is
its sole argument. The only user of the return value is a dead store.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This helper lets you place a node (really the entire subtree rooted at
that node) elsewhere in the devicetree. This will be useful when
adding system devicetree support, when we'll want to be able to, for
example, move the CPU cluster node selected by the current execution
domain to /cpus.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Introduce a context manager that will save some typing
when dealing with expected exceptions.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The image header is compatible for zImage(32) protocol.
Offset Value Description
0x24 0x016F2818 Magic number to identify ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
As Zephyr can be built with a fixed load address, Xen/Uboot can read
the image header and decide where to copy the Zephyr image.
Also, it is to be noted that for AArch32 A/R, the vector table should
be aligned to 0x20 address. Refer ARM DDI 0487I.a ID081822, G8-9815,
G8.2.168, VBAR, Vector Base Address Register :-
Bits[4:0] = RES0.
For AArch32 M (Refer DDI0553B.v ID16122022, D1.2.269, VTOR, Vector Table
Offset Register), Bits [6:0] = RES0.
As zImage header occupies 0x30 bytes, thus it is necessary to align
the vector table base address to 0x80 (which satisfies both VBAR and
VTOR requirements).
Also, it is to be noted that not all the AArch32 M class have VTOR, thus
ARM_ZIMAGE_HEADER header depends on
CPU_AARCH32_CORTEX_R || CPU_AARCH32_CORTEX_A || CPU_CORTEX_M_HAS_VTOR.
The reason being the processors which does not have VBAR or VTOR, needs
to have exception vector table at a fixed address in the beginning of
ROM (Refer the comment in arch/arm/core/aarch32/cortex_m/CMakeLists.txt)
. They cannot support any headers.
Also, the first instruction in zImage header is to branch to the kernel
start address. This is to support booting in situations where the zImage
header need not be parsed.
In case of Arm v8M, the first two entries in the reset vector should be
"Initial value for the main stack pointer on reset" and "Start address
for the reset handler" (Refer Armv8M DDI0553B.vID16122022, B3.30,
Vector tables).
In case of Armv7M (ARM DDI 0403E. ID021621, B1.5.3 The vector table),
the first entry is "SP_main. This is the reset value of the Main stack
pointer.".
Thus when v7M or v8M starts from reset, it expects to see these values
at the default reset vector location.
See the following text from Armv7M (ARM DDI 0403E. ID021621, B1-526)
"On powerup or reset, the processor uses the entry at offset 0 as the
initial value for SP_main..."
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
This commit finish to fix the bug describe by 85e2a0679a68f02f7ef.
With the previous correction, the uptime read could be in the past:
if the counter rewinds just after testing ARRM flag, we had lost
some counts.
Signed-off-by: Julien D'Ascenzio <julien.dascenzio@paratronic.fr>
Change the dtsi order for the stm32L4plus serie,
starting with stm32l4p5-stm32l4q5 and stm32l4r5-stm32l4s5
Significant changes are on the SRAM size, the sdmmc2
and separated RTC-bbram registers.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The SRAM1(total 192 KBytes) plus SRAM2: (total 64 KBytes)
plus SRAM3(total 512 KBytes) is available from 0x20000000 to
0x200BFFFF.
The SRAM size is only 768KB at address 0x20000000
The 16KB SRAM4 is located at address 0x28000000 so that no ram
is present from 0x200c0000 to 0x28000000.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Improve comments, rearrange variable definitions to better match the
control flow of the module, and avoid nesting by adding a return()
statement.
No functional changes expected.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Devicetree pinout was written according to datasheet,
but RX and TX were crossed because labels in the datasheet
are written from debug interface point of view.
However, it seems that flow control pins were not crossed.
Fixes#54768
Signed-off-by: Seppo Takalo <seppo.takalo@nordicsemi.no>
The Kconfig symbol CONFIG_SPI_FLASH_AT45 is selected by default if a
compatible device is enabled.
Remove obsolete config entry.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
The Kconfig symbol for CONFIG_SPI_NOR is selected by default if a
compatible device is enabled.
Remove obsolete board config files.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Move to using 'select SPI' instead of 'depends on SPI'
(see commit df81fef for more details)
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Percentage calculation was off due to a recent fix in counting and lines
were not breaking correctly on errors.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Since there is no way for the client to read or get notified about
the state, we insert a delay between each operation to allow the
server to handle the alerts before getting a new alert request.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Fix the order of setting the alert level before the callback.
Without this fix, the alert level would be incorrect if
the upper layers ever tried to perform any other IAS operations
in the callback.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Add the BD8LB600FS to the build all tests,
as well as add another specific test for just
this chip which also demonstrates the
usage.
Signed-off-by: Benedikt Schmidt <benedikt.schmidt@embedded-solutions.at>
The original implementation of the GEM's device tree binding
implied that:
1) on the UltraScale+, the MDC clock divider is applied to
the LPD_LSBUS_CLK. According to the most recent documentation,
this is not the case, instead, the MDC divider is applied to
the IOU_SWITCH_CLK.
2) any MDC divider greater than 32 is reserved to the Zynq-7000
(in the driver itself, accessibility of the larger dividers was
also #ifdef'd), as the Zynq's MDC clock source, the cpu_1x
clock, can have significantly higher frequencies than the
UltraScale's LPD_LSBUS clock.
The respective documentation in the device tree binding header
file is hereby fixed.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@weidmueller.com>
The interrupt status of the GPIO was not cleared when a new
interrupt configuration was set. This prevents the driver from
passsing all the gpio tests.
Fixes#54833
Signed-off-by: Lucas Tamborrino <lucas.tamborrino@espressif.com>
Change the samples/boards/stm32/backup_sram to run on the
nucleo_u575 or stm32u585 disco kit where the backup sram is enabled
Press the reset button to see that the content of the backUp SRAM
is not altered.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the BackUp RAM to the nucleo_u575zi_q platform.
Change the filename for the .rst to index.rst like other platforms
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the stm32U5 serie for the support of the STM32_BACKUP_SRAM
The PWR peripheral is enabled by the soc/arm/st_stm32/stm32u5/soc.c
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Remove `#include "utils/code_utils.h"` and macros connected with it.
File was incorrectly included in `diag.c` as it is OpenThread's header
used for examples only.
Signed-off-by: Maciej Baczmanski <maciej.baczmanski@nordicsemi.no>
