Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: pinctrl_nrf: Configure QSPI IO3 pin as output set high #71373

Merged
merged 1 commit into from Apr 17, 2024

Conversation

anangl
Copy link
Member

@anangl anangl commented Apr 11, 2024

... so that the pin is kept in a defined state when the IO3 line is not controlled by the QSPI peripheral (when the peripheral is disabled or disconnected from the pin).

The IO3 pin in Quad SPI flash chips usually has dual functionality - it is an I/O line when the chip is configured to work in Quad (4 I/O) mode and it is a HOLD# or RESET# line when the chip is configured to work in non-Quad (2 I/O) mode. In the latter case, it is important that the line is kept in the inactive (high) state, otherwise communication with the chip may be disrupted (and this actually happens when e.g. the spi_flash sample is used on a brand new nRF5340 or nRF52840 DK - the nrf_qspi_nor driver fails to initialize and the sample just ends up with the "mx25r6435f@0: device not ready" message).

This commit addresses the problem in the same way that it was done for the CSN line in commit 6d8172f.

... so that the pin is kept in a defined state when the IO3 line is
not controlled by the QSPI peripheral (when the peripheral is disabled
or disconnected from the pin).

The IO3 pin in Quad SPI flash chips usually has dual functionality -
it is an I/O line when the chip is configured to work in Quad (4 I/O)
mode and it is a HOLD# or RESET# line when the chip is configured to
work in non-Quad (2 I/O) mode. In the latter case, it is important that
the line is kept in the inactive (high) state, otherwise communication
with the chip may be disrupted (and this actually happens when e.g.
the spi_flash sample is used on a brand new nRF5340 or nRF52840 DK -
the nrf_qspi_nor driver fails to initialize and the sample just ends
up with the "mx25r6435f@0: device not ready" message).

This commit addresses the problem in the same way that it was done for
the CSN line in commit 6d8172f.

Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
@anangl anangl added the bug The issue is a bug, or the PR is fixing a bug label Apr 11, 2024
anangl added a commit to anangl/sdk-zephyr that referenced this pull request Apr 11, 2024
… set high

... so that the pin is kept in a defined state when the IO3 line is
not controlled by the QSPI peripheral (when the peripheral is disabled
or disconnected from the pin).

The IO3 pin in Quad SPI flash chips usually has dual functionality -
it is an I/O line when the chip is configured to work in Quad (4 I/O)
mode and it is a HOLD# or RESET# line when the chip is configured to
work in non-Quad (2 I/O) mode. In the latter case, it is important that
the line is kept in the inactive (high) state, otherwise communication
with the chip may be disrupted (and this actually happens when e.g.
the spi_flash sample is used on a brand new nRF5340 or nRF52840 DK -
the nrf_qspi_nor driver fails to initialize and the sample just ends
up with the "mx25r6435f@0: device not ready" message).

This commit addresses the problem in the same way that it was done for
the CSN line in commit 6d8172f.

Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Upstream PR: zephyrproject-rtos/zephyr#71373
anangl added a commit to anangl/sdk-zephyr that referenced this pull request Apr 11, 2024
… set high

... so that the pin is kept in a defined state when the IO3 line is
not controlled by the QSPI peripheral (when the peripheral is disabled
or disconnected from the pin).

The IO3 pin in Quad SPI flash chips usually has dual functionality -
it is an I/O line when the chip is configured to work in Quad (4 I/O)
mode and it is a HOLD# or RESET# line when the chip is configured to
work in non-Quad (2 I/O) mode. In the latter case, it is important that
the line is kept in the inactive (high) state, otherwise communication
with the chip may be disrupted (and this actually happens when e.g.
the spi_flash sample is used on a brand new nRF5340 or nRF52840 DK -
the nrf_qspi_nor driver fails to initialize and the sample just ends
up with the "mx25r6435f@0: device not ready" message).

This commit addresses the problem in the same way that it was done for
the CSN line in commit 6d8172f.

Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Upstream PR: zephyrproject-rtos/zephyr#71373
anangl added a commit to anangl/zephyr that referenced this pull request Apr 11, 2024
… set high

... so that the pin is kept in a defined state when the IO3 line is
not controlled by the QSPI peripheral (when the peripheral is disabled
or disconnected from the pin).

The IO3 pin in Quad SPI flash chips usually has dual functionality -
it is an I/O line when the chip is configured to work in Quad (4 I/O)
mode and it is a HOLD# or RESET# line when the chip is configured to
work in non-Quad (2 I/O) mode. In the latter case, it is important that
the line is kept in the inactive (high) state, otherwise communication
with the chip may be disrupted (and this actually happens when e.g.
the spi_flash sample is used on a brand new nRF5340 or nRF52840 DK -
the nrf_qspi_nor driver fails to initialize and the sample just ends
up with the "mx25r6435f@0: device not ready" message).

This commit addresses the problem in the same way that it was done for
the CSN line in commit 6d8172f.

Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Upstream PR: zephyrproject-rtos#71373
anangl added a commit to anangl/sdk-zephyr that referenced this pull request Apr 11, 2024
… set high

... so that the pin is kept in a defined state when the IO3 line is
not controlled by the QSPI peripheral (when the peripheral is disabled
or disconnected from the pin).

The IO3 pin in Quad SPI flash chips usually has dual functionality -
it is an I/O line when the chip is configured to work in Quad (4 I/O)
mode and it is a HOLD# or RESET# line when the chip is configured to
work in non-Quad (2 I/O) mode. In the latter case, it is important that
the line is kept in the inactive (high) state, otherwise communication
with the chip may be disrupted (and this actually happens when e.g.
the spi_flash sample is used on a brand new nRF5340 or nRF52840 DK -
the nrf_qspi_nor driver fails to initialize and the sample just ends
up with the "mx25r6435f@0: device not ready" message).

This commit addresses the problem in the same way that it was done for
the CSN line in commit 6d8172f.

Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Upstream PR: zephyrproject-rtos/zephyr#71373
@anangl anangl requested a review from de-nordic April 17, 2024 07:16
@aescolar aescolar merged commit 2f44266 into zephyrproject-rtos:main Apr 17, 2024
26 checks passed
@anangl anangl deleted the fix_qspi_io3_gpio_cfg branch April 17, 2024 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Pinctrl bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants