Enable DMA peripheral support on MAX32655EVKIT and FHTR boards.
Co-Authored-By: Sadik Ozer <sadik.ozer@analog.com>
Signed-off-by: Jason Murphy <jason.murphy@analog.com>
Revise data type declarations to avoid implicit/explicit casts:
- Changed `unsigned char` to `uint8_t` for `zeros` array
to match with `longest`.
- Declared variables `i`, `j`, and `pos` as `int` to use the same type.
- Cast `value` to `uint16_t` instead of `uint32_t` since
`value` is `uint16_t`.
- Moved `bh` and `bl` declarations to narrow the scope of variables.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Simplify high and low byte conversion by removing redundant checks,
since `net_byte_to_hex` already takes care of zero padding.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Replace the loop with direct high and low nibble extraction,
and ensure the padding and zero suppression logic is simplified.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
number of counters have changed in gcc 14 by commit
08a5233180
Specifically, a new counter was added in gcc/gcov-counter.def:
```
/* Conditions. The counter is interpreted as a bit-set. */
DEF_GCOV_COUNTER(GCOV_COUNTER_CONDS, "conditions", _ior)
```
which in turn updates the value of GCOV_COUNTERS that is defined in
gcov-io.h like this:
```
enum {
GCOV_COUNTERS
};
```
Signed-off-by: Roman Studenikin <srv@meta.com>
If only 2 page frames are queued and code executing in one frame is
making an access to memory in the second frame then the access will trap
and k_mem_paging_eviction_accessed() will be called to move that frame
to the end of the queue ... marking the new head frame unaccessible.
But that newly unaccessible frame contains the code that has yet to be
resumed to perform its memory access. Since it is now unaccessible, a
trap is triggered, the frame is moved to the end of the queue and the
new head frame (the one we trapped for initially) is marked unaccessible.
Execution is resumed with the memory access which is unaccessible again
and the cycle repeats infinitely.
Fix this by not marking the new head unaccessible if there is only one
queued frame left in the queue.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
RRAMC peripheral is a secure-only peripheral, and the application
cannot use it directly. While building an application with TF-M
enabled and SOC_FLASH_NRF_RRAM the NRFX_RRAMC selection must
be forbidden.
Signed-off-by: Arkadiusz Balys <arkadiusz.balys@nordicsemi.no>
Do not depend on platforms that need a HAL. This should speed things up
and should resolve issues where runner did not have enough space to deal
with all HALs.
t
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add support for testing IPC between cpuapp<>cpuflpr. Some adjustments
have been done to be able to support two different remote targets for
the nrf54h20dk cpuapp.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
While executing from MRAM will likely never happen in practice for the
FLPR core, add such variant for testing.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
This is required since NRF_FUN_POS (pinctrl) has changed its position
from 17 to 18 (a value hardcoded in the nrf-regtool as well).
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
On new SoCs, certain pins need to enable the clock setting on the pin
for it to work properly. For now, this has been handled internally in
the pinctrl driver, however, it appears to be an instance-specific
property (e.g. UARTE/SPIM instances in the fast domain do not require
such setting). Move the configuration of this settings to DT, the best
place where to have instance-specific hardware settings.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Some UARTE instances may be clocked at higher speeds than 16MHz, so the
baudrate setting needs to be scaled accordingly. This patch parses the
`clocks` property and obtains the clock-frequency property of the
associated clock, assuming it is a fixed-clock. We should ideally have a
proper clock control subsystem where frequency can be queried using an
API, but we're far from there.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
HSFLL120 is a clock used by fast peripherals, and it is controlled by
the system controller. From an application perspective, it is a fixed
clock. Note that it has multiple outputs (clk_main @ 320MHz, and
clk_main2|4 which provide the main clock divided by 2 and 4,
respectivelu). Only the main frequency is represented for now.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
