Thanks to visit codestin.com
Credit goes to github.com

Skip to content

drivers/memory/spiflash.c: Write 2nd byte of SR as separate command. #11932

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

victorallume
Copy link
Contributor

The existing spiflash driver writes both bytes of SR as a single command.
Some flash chips don't support multi-byte writes such as this, and have a
seperate command to write SR byte 1 and SR byte 2 (referred to in the code
as CR). This used in the spiflash initialisation to enable quad mode. The
quad enable bit is in the second SR byte. This change still issues the
multi-byte command, then issues a single byte command for just the second
SR byte. For chips that only support one of the commands, the unsupported
command should be ignored silently. For chips that support both types of
command, the SR will be written twice.

This depends on #11931 for
the stm32 port to allow single-byte spi commands.

The existing qspi for stm32 implementation can only send a spi command with
exactly 0 or 2 data bytes. Certain spiflash chips (e.g. AT25SF321B) have
commands that only take a single data byte, and will ignore the command if
more than that is sent. This allows sending a command with a single data
byte. Would be nicer to have a general function to send `n` bytes, but
there probably aren't many commands that require this.

Signed-off-by: Victor Rajewski <[email protected]>
The existing spiflash driver writes both bytes of SR as a single command.
Some flash chips don't support multi-byte writes such as this, and have a
seperate command to write SR byte 1 and SR byte 2 (referred to in the code
as CR). This used in the spiflash initialisation to enable quad mode. The
quad enable bit is in the second SR byte. This change still issues the
multi-byte command, then issues a single byte command for just the second
SR byte. For chips that only support one of the commands, the unsupported
command should be ignored silently. For chips that support both types of
command, the SR will be written twice.

This depends on micropython#11931 for
the stm32 port to allow single-byte spi commands.

Signed-off-by: Victor Rajewski <[email protected]>
@dpgeorge
Copy link
Member

Can you give an example of a SPI flash chip that requires this change (maybe a GD25Q64C)?

Also, this change/feature would need to be configured either dynamically (a variable) or statically (#define macro). Could possible use data from drivers/memory/external_flash_device.h.

@victorallume
Copy link
Contributor Author

The AT25SF321B is the one we're using that behaves like this.

@victorallume
Copy link
Contributor Author

Overall, it would be better to have spiflash configurable like the samd port has 2b5a5a0#diff-b85028709958e90cd49f944b51f5adea618cc64b068900dafce924f89eb4cbf5 ; this PR is just a stopgap to get this working, but the stm port would need a bit more work to make it configurable.

@oliver-joos
Copy link
Contributor

oliver-joos commented Aug 29, 2023

I have another example.

We have a custom board with ISSI IS25LP256D SPI flash. Its QE bit (Quad Enable) is bit 6 of a 1-byte status register. Here is our well-tested patch for ISSI flash: db57018 (including ugly hardcoded ISSI detection)

This PR does both 1- and 2-byte access, clever! But this does not work for ISSI flash because it needs a 1-byte-access to first byte using CMD_WRSR (not to the second with CMD_WRCR). I think we need a more general solution like a weak function or a macro to define the code that sets the QE bit.

MbedOS has code to support 4 variants of QE bits:
https://github.com/ARMmbed/mbed-os/blob/32d70027a599fe67f94b8c14e0d17a71eea11f7b/components/storage/blockdevice/COMPONENT_QSPIF/QSPIFBlockDevice.cpp#L689

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.

3 participants