-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
base: master
Are you sure you want to change the base?
drivers/memory/spiflash.c: Write 2nd byte of SR as separate command. #11932
Conversation
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]>
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 |
The AT25SF321B is the one we're using that behaves like this. |
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. |
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: |
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.