When dual-flash mode is enabled, two identical flash memories are
connected to the QUADSPI peripheral, each having its own set of
registers. This means that when reading or writing a flash register,
this has to be made for both flash memories.
For example, when reading a status register (1 byte), the QUADSPI
peripheral must be configured to read two bytes of data, which
correspond respectively to the value of the register in the first and
second flash memory. Same thing when writing.
Before this commit, when dual-flash mode was enabled, only the register
of the first flash memory was considered, which means the second flash
memory could be incorrectly configured and that any write/erase
operation could be considered as completed too early, if the operation
takes more time to complete for the second flash memory.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
The 'qspi_read_status_register' routine implements the reading of a
flash memory's status register. This routine is used anytime reading a
status register is needed, except in 'qspi_wait_until_ready'. This
commit moves the read routine to be able to use it in
'qspi_wait_until_ready'. The 'qspi_write_status_register' is also moved
to keep it close to the read routine.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
In multiple places, "#if DT_PROP(DT_NODELABEL(quadspi), dual_flash) &&
defined(QUADSPI_CR_DFM)" was used to guard sections specific to
the dual-flash feature. This is quite long and "#ifdef
STM32_QSPI_DOUBLE_FLASH" is now used instead.
Note the presence of QUADSPI_CR_DFM is no more checked. This is not
considered as an issue since when QUADSPI_CR_DFM is not available, the
QSPI hardware doesn't support dual-flash mode so this mode must not be
enabled in the devicetree. With that change, enabling dual-flash mode
when not available causes a compile-time error.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
Add a flash driver that is used to perform flash operations on a flash
chip that is connected to an Andes QSPI controller and is used for XIP
mode.
The driver is as small as possible, because necessary code has to be
placed in RAM. It is not possible to fetch code from flash while
performing erase/write operations.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Turn MCX series into families.
Reasoning:
1. The MCX SOCs are quite different from each other and having them all
under one family in the HWMv2 hierarchy is fruitless because there
are so many differences that it is confusing to try to introduce
family-level code and configs since they would each only apply to a
subset of the series. There is almost nothing that can be shared
between all of them. Which is why there are comments in the MCX
family files saying not to put anything in them. This is a technical
waste.
2. Therefore, turning all of them into families is almost 0 effort and
makes sense. It will allow these different types of MCX to be
further subdivided into series in the future as the MCX portfolio
expands and such division will be necessary as new SOCs within each
letter family are released.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Add a new flash for toggling runtime SFDP data fetching, and use static
devicetree properties by default. Clean up various minor items from review.
Signed-off-by: Pete Johanson <pete.johanson@analog.com>
Properly configure the MAX32 SPIXF peripheral to use the SPIXF controller
for transparent memory mapped reads, and enable the SPIXF main controller
and use it for writes.
Add support for testing XIP support to the nocopy sample, which requires
flashing with OpenOCD with MAX32690 QSPI flash support.
Signed-off-by: Pete Johanson <pete.johanson@analog.com>
The flash_stm32_xspi driver should not initialize the xspi,
if this one is being use to execute in Place : the init is skipped.
This mode is identified with the CONFIG_STM32_APP_IN_EXT_FLASH.
Checking the memory mapped mode bit is possible when the xspi
peripheral clock is not off (stm32h5 has no clock_control_get_status API)
Signed-off-by: Francois Ramu <francois.ramu@st.com>
It is not possible to build anymore in that mode, so we do not
need to support it in this driver cmake files.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
The reset commands were sent only in SPI mode, causing the device not to
be properly reset when in QPI mode. On the STM32H747I-DISCO boards, this
was causing the driver initialization to fail due to a bad SFDP magic
after flashing the external memory using STM32CubeProgrammer since the
external loader is configuring the flash memory in QPI mode.
The commands are sent in QPI mode first, then in SPI mode:
- If the flash memory was in QPI mode, the two first reset commands are
processed and after reset, the flash memory is in SPI mode and
correctly handles the SPI mode reset commands.
- If the flash memory was in SPI mode, for each QPI command the chip
select signal will be released before the flash memory had the
opportunity to receive a whole command (1 byte), so the partially
received commands will be ignored and won't cause any harm. Then, the
chip is reset by the commands sent in SPI mode.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
When the QSPI is used in dual flash mode, e.g. on the STM32H747I-DISCO
board, only the first flash memory was reset and configured in 4-byte
addressing mode. This was in particular causing data to be incorrectly
read from the second flash memory and only even bytes were valid during
a read.
The dual flash mode was only enabled after reading the SFDP table since
it is desired to read the table of only one flash memory, not both.
This commit changes the driver to only disable the dual mode temporarily
while reading the SFDP table, ensuring all other commands and in
particular configuration commands are sent to both flash memories.
Signed-off-by: Thomas Altenbach <altenbach.thomas@gmail.com>
CS hold time parameter is not correct which may cause bus fault
randomly.
System hang during status register reading after flash progromming which
is caused by parameter accessing in XIP mode.
Add dummy delay for READ command according the flash datasheet which is
required for SDR mode.
Use FlexSPI internal divider for clock updating instead of register in
CCM to avoid potential risk caused by flash access during clock updating
procedure.
Signed-off-by: Raymond Lei <raymond.lei@nxp.com>
MT35 flashes could run in octal mode, Now the driver doesn't support
octal mode, add octal mode support for MT35 flashes.
Signed-off-by: Qiang Zhao <qiang.zhao@nxp.com>
Use LOG_ERR() instead of LOG_DBG() in flash_fill() when this function
fails to perform the write operation, so that the failure is better
visible and its cause is easier to identify.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The STM32WBA Flash Manager driver is failing to erase a sector, instead of
erasing one sector, two sectors are erased.
Fix it by correctly calculating the number of sectors to erase
Signed-off-by: Eric Mechin <eric.mechin@st.com>
This commit changes the implementation to distinguish between is25lpXXX
and is25lpXXXd. Using RDERP as in the original solution didn't work for
is25wpXXX chips and would cause a halt. This new implementation reads
the AutoBoot register instead, which is not present in is25lpXXX but
present in is25lpXXXd, is25wpXXX and is25wpXXXd.
Tested on:
- mimxrt1020-evk
- mimxrt1170-evk rev. A
- custom board with mimxrt1170 and is25lp128d
Signed-off-by: John Barbero Unenge <git@lsrkttn.com>
New property of the st,stm32-qspi-nor compatible gives
the external NOR flash in bits.
The property of the st,stm32-qspi compatible gives
the external NOR flash base address
Signed-off-by: Francois Ramu <francois.ramu@st.com>
New property of the st,stm32-ospi-nor compatible gives
the external NOR flash in bits.
The property of the st,stm32-ospi compatible gives
the external NOR flash base address
Signed-off-by: Francois Ramu <francois.ramu@st.com>
When the quad-enable-requirements property is set to "NONE" or is not
present, no Quad Enable operation should be performed.
This fixes an issue with the mx25uw6345g flash chip that is present
on the nRF54h20 DK and supports the Single I/O mode, but cannot be
used in that mode.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Fix timeout error that can occur in rare case.
When the thread writing to flash is pre-emptive it can be scheduled
out after reading the status register, but before checking if timeout
has expired. In this case it will report timeout without re-checking
the status register.
When writing a lot to flash, for example a firmware update process
then this situation is very likely to occur.
Signed-off-by: Joakim Andersson <joerchan@gmail.com>
Some external flash modules have extra commands to support, for example,
reading/writing an OTP zone. Given that the commands are highly specific
and difficult to generalize, we add two ex ops that can be used to
transmit a custom command (in the form of a full QSPI_CommandTypeDef) and
then read or write a user-provided buffer.
Signed-off-by: Federico Di Gregorio <fog@dndg.it>
This device driver supports ISSI is25w/lx032/64 series flash.
Only extended SPI mode(1s-1s-1s, 1s-8s-8s, 1s-1s-8s) is implemented.
Signed-off-by: Swift Tian <swift.tian@ambiq.com>
is_area_readable is used for SOCS other than LPC55XXX chips, not just
chips other than LPC55S36. Change the condition which elides this code
to avoid a GCC 14.3 warning.
Signed-off-by: Keith Packard <keithp@keithp.com>
Introduce the stm32u3 serie to the the existing flash driver
It is based on the stm32l5 model.
Signed-off-by: Khaoula Bidani <khaoula.bidani-ext@st.com>
Add reference counting in nrf_qspi_nor_xip_enable() so that XIP is
kept enabled as long as there is at least one user that needs it
(boot time enabling done with CONFIG_NORDIC_QSPI_NOR_XIP also counts).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Specific flash driver is used for stm32wbax when ble is
enabled. A simple typo error was fixed to properly build
all the samples where flash and ble are enabled,
such as the peripheral one.
Signed-off-by: Alessandro Manganaro <alessandro.manganaro@st.com>
Fix the flash size to 64KB for the stm32H7RS series.
Restore the get_size API function for that series.
This is a specificity of this stm32 mcu (RefMan RM0477).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Support OSPI flash driver on EK-RA8M1 and EK-RA8D1 with ospi_b
and S28HL512T flash.
Signed-off-by: Tri Nguyen <tri.nguyen.wj@bp.renesas.com>
Signed-off-by: Thao Luong <thao.luong.uw@renesas.com>
The LPC55XXX SoC series requires the use of a HAL function to read
from uninitialized flash without triggering a hardfault. This
broadens an existing #ifdef clause so that it is triggered for all
chips in the series instead of only the LPC55S36.
Signed-off-by: Wilkins White <ww@novadynamics.com>
Parameter checking of flash read API expects checking for len == 0
before checking dest buffer validation.
Fixes#87021
Signed-off-by: David Leach <david.leach@nxp.com>
Add Set_WP function to set SPI flash WP line to low
Add Get_WP function to obtain status of the SPI flash WP line
Signed-off-by: Benson Huang <benson7633769@gmail.com>
Commit 0e41b07309 ("drivers : flash:
update way to get flash size") changed the way to get flash size from
the LL_FLASH_GetSize() HAL function to the current DT_REG_SIZE() macro.
However, they are not equivalent:
- With LL_FLASH_GetSize(), REAL_FLASH_SIZE_KB returned the *total* size
of the Flash memory, reading it from a ROM register of the CPU. For
example, it was 2048 (2MB) for a STM32H747xI.
- The current DT_REG_SIZE() applies to a flash *bank*, therefore it only
returns half of the total Flash size on dual bank devices.
This mismatch causes issues with the DISCONTINUOUS_BANKS logic below,
incorrectly matching partitions close to the end of the first bank as
appearing to span both and triggering the "range overlaps discontinuity"
check later.
Fix it by doubling the size when appropriate, in the same way it is
already done for the M4 core.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
The stm32H7RS serie has no DelayBlock Bypass control in its DCR1 register.
For other stm32 devices with DelayBlock bypass control, set the value
directly in the structure.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the support of the stm32h7rs serie to the
drivers/flash/flash_stm32_xspi driver.
The stm32h7rs has no delayblock
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the clock domain configuration for the xspi nodes
Where the DTS defines main clock and peripheral clock sel
plus a XSPIM clock
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add new device tree property specifying the number of
dummy-cycles required when reading the JEDEC ID.
The Arduino Opta has an at25sf128a with JEDEC ID 1F 89 01.
The PR below adds support for this, but the id read is 01 1F 89.
Changing DummyCycles to 16 causes the correct value to be read.
https://github.com/zephyrproject-rtos/zephyr/pull/89539
Signed-off-by: Mark O'Donovan <shiftee@posteo.net>
On some series, use of Delay Block could be possible on OSPI device but
not on HSPI one (which uses this drivers).
As a quick fix check the presence of XSPI Delay Block by-pass
configuration bit instead of the Delay Block presence.
Note: This fix works because we don't have cases today where this driver
is used for OSPI and HSPI instances with mixed DLYB compatibility.
This may have to be reviewed one day and may require a more complex fix
with instantiable configuration, but this day may never come as well.
Signed-off-by: Erwan Gouriou <erwan.gouriou@st.com>
Due to source data pointer having no alignment constraint,
extra care needs to be taken when reading source data
as dword
Signed-off-by: Yonas Alizadeh <yonas.alizadeh@alfalaval.com>
Most SPI NOR flash devices support a "fast read" command which uses
dummy bits between the address and the start of the data transfer. In
many cases, the maximum SPI clock speed of the device is lower for the
regular read command due to the limited time between the address and
data phases, so using the fast read command will remove this restriction
and allow for faster transfers.
Add a device tree flag to indicate that fast reads should be used for
the device.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Some Micron (and possibly other) SPI NOR devices implement a flag status
register which provides more information on the success/failure of erase
and program operations. In addition to better error checking, some of
these devices actually don't function properly if the flag status
register is not read after a program operation (subsequent reads will
only return 0xFF bytes).
Add a device tree parameter to indicate that the flag status register is
supported. When specified, the flag status register will be used for
ready/error checks rather than the standard status register.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
This driver was providing SPI buffers for both TX and RX on the data
payload portion of read transfers, even though the TX buffer is not
meaningful in these cases. As well as being less efficient, this also
caused likely uninitialized data to be transferred to the device, which
is possibly problematic.
Update to not include the TX buffer for the read data payload SPI
transfer, so that the SPI driver can generate dummy TX data internally.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
