The device PM subsystem _depends_ on device, not vice-versa. Devices
only hold a reference to struct pm_device now, and initialize this
reference with the value provided in Z_DEVICE_DEFINE. This requirement
can be solved with a forward struct declaration, meaning there is no
need to include device PM headers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Program flow will behave incorrectly (memory and instruction fetches
return invalid data) if Flexspi is accessed by the Flexspi driver while
being used as XIP memory by the Cortex M7.
Set logging to disabled by when XIP mode is used in the memc and
flexspi drivers, and warn the user if they attempt to enable it.
Fixes#40133
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Port some drivers to the recently introduced macros to showcase its
usage and be able to do some initial testing (nRF52840).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit fixes dual bank flash handling on stm32g0 targets.
In contrast to other Series (G4, L5) the flash page size does not change
in single bank configuration (2KiB in both configurations).
nSWAP_BANK:
While the reference manual(RM) only documents:
"This bit selects the bank that is the subject of empty check upon boot"
as expected, this behaves similar to BFB2 on G4 and SWAP_BANK on L5.
It has been observed that this bit swaps the address mapping of bank1
and bank2, regardless of DUAL_BANK bit being set or not.
As documented in the RM the nSWAP_BANK bit is ignored when the BOOT_LOOK
bit is set. This applies to the empty check as well as the address
mapping.
On this Series FLASH_CR_BKER must be set in single-bank as well as
dual-bank configuration for erase operations on bank2 regardless of
the swap status.
On a G0B1RE (dev-id: 0x467) I could not observe a difference between
DUAL_BANK flash option bit set and not.
It this may be different on 256KiB Flash targets.
The HAL indicates that "FLASH_SALES_TYPE_0" only uses a single bank if
OB_DUAL_BANK_VALUE is not set, but as I don't know which SoC this is
and I can't test the behaviour and the driver does not take this into
account.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
This commit makes no functional changes, it only refactors the
driver such that dual bank flash handling can be easily added.
Instead of using HAL macros directly in the code, new macros
with STM32G0 prefix are defined.
The erase_page function gets passed the offset instead of the page,
and the FLASH CR reg is written once with all erase parameters.
flash_stm32_wait_flash_idle is already called before each
write to CR, consequently it is also made sure CFGBSY flag
is not set.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Some series (namely g0, u5, wb, wl, ?) use CFGBSY to indicate
that FLASH_CR is not ready to be modfied.
This commit adds this flag additionally to other the flash busy flags,
in flash_stm32_wait_flash_idle such that the driver waits before
trying to modify PG, PNB[6:0], PER, and MER bits in FLASH_CR.
Additionally, dual bank variants of STM32G0 have a seperarate BSY2 flag
for flash bank two.
Until now this was not yet checked in flash_stm32_wait_flash_idle.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
In STM32G0 HAL FLASH_FLAG_xxx defines don't follow the pattern of
other Series to simply redefine the FLASH_SR_xxx Msk.
Instead an ID for the SR reg and the position of the Error flag
are defined.
As a result error checking in flash_stm32_check_status was not working
until this fix on stm32g0 series.
In order to avoid complexity in the driver, the ifdef-ery of the flags
was moved to the header file.
Other series except g0 use FLASH_FLAG_xxx defines, because those
are valid for both cores in dual core(wl) and in secure/non-secure
targets(l5,u5).
FLASH_STM32_SR_ERRORS mask is introduced to check for any active error
in the SR.
The flags for SIZERR, MISERR, FASTERR are newly introduced.
the latter two are only required once fast programming is used,
which is not yet the case for any series.
The FLASH_SR_OPTVERR flag (option validity flag) is also present
in the SR, but is not added.
Also ecc errors are generally not checked, but these are in a different
register.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
An attempt to simplify the ifdef-ery around FLASH_SR is made.
Define Registers and flags in the header file instead of including
several individual operations in the driver.
FLASH_FLAG_BSY is not only defined for STM32L5, but also other series.
Therefore use this flag instead of FLASH_SR_BSY.
Only the g0 series definition is not valid in our context,
therefore use FLASH_SR_BSY1 instead.
No functional changes, only refactoring.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
The commit removes an error check from the erase loop and instead
add breaks in places where errors that would break an execution of
the loop occur.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
Deinitialize the nrfx_qspi driver for periods when the device
is suspended. For flash chips with "has-dpd" property set, when
suspending/resuming the device, issue also the enter/exit Deep
Power-down Mode command, respectively.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Use the read-only device config structure (so far used only for storing
the flash chip size and its JEDEC ID) to store the nrfx_qspi driver
configuration (it is not modified after initialization, so there is no
need to keep it in RAM) and fill it with settings read from devicetree,
processing them all at compile time (e.g. use the DT_STRING_UPPER_TOKEN
macro instead of switch-case blocks for getting values of "readoc" and
"writeoc" properties).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The commit removes redundant flash_id argument that the function
can obtain itself from dev.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The PM callback is no longer referenced as "pm_control" but
"pm_action_cb", so reflect this new naming on the callbacks.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This enables accessing the hyperflash through the flash api.
Added a feature to memc_mcux_flexspi that waits for flexspi bus to be
quiet.
Signed-off-by: Nicolai Glud <nicolai.glud@prevas.dk>
The ticker `ticks_drift` is propagated via the ticker
elapsed callback, in order to provide necessary information
to correctly calculate total elapsed durations by states and
roles that use ticker extensions to mitigate scheduling
collisions by drifting within a permitted window.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
The additional depends on SOC_FAMILY_SAM was redundant.
Add sam4l_ek to dfu sample exclude since it was failing on
arduino_due.
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
The Kconfig refactor that replaces some single-symbol 'if's with
'depends on' added a second entry. That entry allows flash driver
be selected for SoC's without support. This fixes the 'depends on'
entry to allows only SAME/V SoCs.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
So fare flash simulator had been forced to use the statistic
subsystem.
This patch introduces CONFIG_FLASH_SIMULATOR_STATS which allow to select
whether the statistic is involved in flash_simulator operations.
This patch allows to reduce flash footprint when the statistic is
not required.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
For getting the address of the RAM region in the application we need to
extend the api for the flash_simulator.
This path introduce flash_simulator_get_memory() call which allow to
do so.
Signed-off-by: Sigvart Hovland <sigvart.m@gmail.com>
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
For some reason, XCC fails to build complaining segfault
during CGPREP phase. Adding an assignment to a volatile
return value seems to fix this. This provides an easily
revertable commit to workaround the issue.
Fixes#37734
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The max-erase-time property was introduced for the STM32 flash driver,
but it was inserted as an optional property in the generic
soc-nv-flash binding which is used by other SoCs.
Make it a required property in a new st,stm32-nv-flash binding
instead, since it is at present a vendor specific property.
Update the DTS files accordingly. Keep the existing "soc-nv-flash"
value in the compatible list in each case, so that DT_HAS_COMPAT(...
soc_nv_flash) tests on these nodes will still succeed, but put it
after a newly added "st,stm32-nv-flash" compatible, so that the
SoC-specific binding will be used as it is discovered first by the DT
tooling.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The delay will ensure last byte has been latched in before
This also change the method of reading status register from re-send
read status command on each read to read status register continuously.
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
According to Atmel SAM datasheet when writing data to the latch buffer
"32-bit words must be written continuously, in either ascending or
descending order. Writing the latch buffer in a random order is not
permitted." To enforce the requirement we need to call a memory barrier
instruction after copying every word of data to the latch buffer. In
the absensce of __DSB() call the ARM processor is free to change order
of AHB transfers. This has caused the driver to occasionally corrupt
data programmed in the flash.
Fixes#37515
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
This commit adds flash driver in non-secure mode for stm32l5x
series with icache enabled. This commit also adds a flash
programming error status check applicable for all platforms
except stm32f1 series.
Signed-off-by: Krishna Mohan Dani <krishnamohan.d@hcl.com>
Instead of passing target states, use actions for device PM control.
Actions represent better the meaning of the callback argument.
Furthermore, they are more future proof as they can be suitable for
other PM actions that have no direct mapping to a state. If we compare
with Linux, we could have a multi-stage suspend/resume. Such scenario
would not have a good mapping when using target states.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
According to the documentation the OFF state has to be used when the
devices is fully turned off, ie, power removed. Most drivers were using
a sort of fall-through for all non-active states, leading to behaviors
not following the specifications.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Return -ENOTSUP if the requested state is not supported
- Remove redundant "noop style" functions.
- Use switch everywhere to handle requested state (not necessary in all
drivers, but better take off with consistency in place after current
changes).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The verb tense for the suspended state was not consistent with other
states. The likely reason: state was being used as a command/action.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The difference between low power and suspend states is a thin blur line
that is is not clear and most drivers have used indistinctly. This patch
converges to the usage of the suspend state for low power, since
contrary to the low power state, it is used by both system and runtime
device PM. The low power state is still kept, but its future is unclear
and needs some discussion.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM control function will only be called if the requested
state is different from the current one. A significant amount of drivers
were checking for state changes, now unnecessary. This patch removes all
this redundant logic.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since the state is no longer modified by the device PM callback, just
use the state value.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The callback is now invoked to set the device PM state in all cases, so
the usage of ctrl_command is redundant.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM subsystem already holds the device state, so there is no
need to keep duplicates inside the device. The pm_device_state_get has
been refactored to just return the device state. Note that this is still
not safe, but the same applied to the previous implementation. This
problem will be addressed later.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Michael Hope