Skip to content

Conversation

besmarsh
Copy link
Contributor

@besmarsh besmarsh commented Oct 8, 2025

Commit 539928d introduced a special behaviour for Microchip QSPI flash memories into the STM32 QSPI flash driver, to handle the fact that these memories use the PP_1_1_4 opcode (32H) for the PP_1_4_4 operation (usually 38H).

The special behaviour is a bit backwards, as it results in a QSPI flash memory configured in 1-1-4 write mode using 4 address lines (1-4-4 operation). It should be the other way round, so that a QSPI flash memory configured in 1-4-4 mode uses 4 address lines (1-4-4 operation).

After these changes, the mode used matches the mode configured.

See commit message for more detailed explanation.

Before/After Comparison

Before:

Devicetree configuration requires writeoc = "PP_1_1_4"; for successful quad write, which then uses 1-4-4 mode.

Devicetree writeoc property Write opcode used Write mode used Behaviour
writeoc = "PP_1_1_4"; SPI_NOR_CMD_PP_1_1_4 1-4-4 Successful write in 1-4-4 mode
writeoc = "PP_1_4_4"; SPI_NOR_CMD_PP_1_4_4 1-4-4 Unsuccessful write
(Omitted) SPI_NOR_CMD_PP_1_4_4 1-4-4 Unsuccessful write

After:

Devicetree configuration requires writeoc = "PP_1_4_4"; (or property omitted, defaults to 1-4-4 mode for quad mode) for successful quad write, which then uses 1-4-4 mode.

Devicetree writeoc property Write opcode used Write mode used Behaviour
writeoc = "PP_1_1_4"; SPI_NOR_CMD_PP_1_1_4 1-1-4 Unsuccessful write
writeoc = "PP_1_4_4"; SPI_NOR_CMD_PP_1_1_4 1-4-4 Successful write in 1-4-4 mode
(Omitted) SPI_NOR_CMD_PP_1_1_4 1-4-4 Successful write in 1-4-4 mode

This PR also updates the Kconfig option description for CONFIG_USE_MICROCHIP_QSPI_FLASH_WITH_STM32 to remove references to the Global Block Protection Unlock instruction - this was added at the same time as the Microchip-specific special behaviour for the 1-1-4 / 1-4-4 opcode but is distinct from this and is not affected by CONFIG_USE_MICROCHIP_QSPI_FLASH_WITH_STM32.

@besmarsh besmarsh force-pushed the correct-mode-behaviour-for-microchip-qspi-flash-on-stm32 branch from c625a40 to d5d02c4 Compare October 8, 2025 16:24
Commit 539928d introduced a special behaviour for Microchip QSPI flash
memories into the STM32 QSPI flash driver, to handle the fact that these
memories use the PP_1_1_4 opcode (32H) for the PP_1_4_4 operation
(usually 38H).

The special Microchip-specific behaviour introduced in that commit sets
the address mode for a QSPI 1-1-4 write operation to 4 address lines,
rather than 1 address line, when the write command is configured as
SPI_NOR_CMD_PP_1_1_4. If the write command is configured as
SPI_NOR_CMD_PP_1_4_4, nothing is done and the operation will not succeed.

This behaviour is a bit backwards, as it results in a QSPI flash memory
configured in 1-1-4 write mode using 4 address lines (1-4-4 operation).
It should be the other way round, so that a QSPI flash memory configured
in 1-4-4 mode uses 4 address lines (1-4-4 operation).

This commit changes the Microchip-specific special behaviour to set the
opcode for the specified write mode, rather than using a different write
mode to that which is configured in order to use a valid opcode. This
means that a QSPI flash memory configured in 1-4-4 mode, or without the
writeoc DT property set (defaults to 1-4-4 for quad mode), will operate
in 1-4-4 mode. 1-1-4 mode is unsupported, as before.

Also update the Kconfig option description for
CONFIG_USE_MICROCHIP_QSPI_FLASH_WITH_STM32 to remove references to the
Global Block Protection Unlock instruction - this was added at the same
time as the Microchip-specific special behaviour for the 1-1-4 / 1-4-4
opcode but is distinct from this and is not affected by
CONFIG_USE_MICROCHIP_QSPI_FLASH_WITH_STM32.

Signed-off-by: Ben Marsh <[email protected]>
@besmarsh besmarsh force-pushed the correct-mode-behaviour-for-microchip-qspi-flash-on-stm32 branch from d5d02c4 to 474824f Compare October 8, 2025 16:30
Copy link

sonarqubecloud bot commented Oct 8, 2025

Copy link
Contributor

@FRASTM FRASTM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM,
please @aescolar review

@aescolar
Copy link
Member

LGTM, please @aescolar review

Did you mean @erwango ? :)

@FRASTM
Copy link
Contributor

FRASTM commented Oct 10, 2025

LGTM, please @aescolar review

Did you mean @erwango ? :)
I thought, It would be kind to have yours, too ;-)

@cfriedt cfriedt merged commit 2a0fb72 into zephyrproject-rtos:main Oct 13, 2025
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants