S25FL128L Quad I/O Fast Read Problem on Dataline 4

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi there,

erasing, writing and reading with Quad Out Fast Read 0x6B (1-1-4) is working fine. But I have a strange Problem with the Cmd 0xEB (Quad I/O Read with 1-4-4). With the 0xEB the DQ3 Line is doing nothing.

I have a small Test-Routine which is erasing the Flash, writing 0xFF, 0xFE, 0xFD, .., 0x00 into it and than I read the Data back. So in Reading the Data you should get a specific toggling, visible in first of following Captures which is from 0x6B:

pastedImage_2.png

The second Capture is from 0xEB and there the DQ3 Line is not toggling (only at ModeCycle-Phase with a 0xA0). The LogicAnlayzer interpreads this as 2 Clocks DummyCycles and following 2 Clocks 0x88 is the real DummyPhase of 2 Cycles (40 MHz QSPI-Clock).

pastedImage_4.png

I'm using a STM32L4 with related HAL.

Here is the Snippet of Command-Init:

SPI_CommandTypeDef sCommand = {0};

if(!isQuadModeActive)

  res = QSPI_QuadMode();

sCommand.Instruction = eQSPI_CMD_QUAD_INOUT_FAST_READ;

sCommand.Address = address;

sCommand.AlternateBytes = 0xA0;

sCommand.AddressSize = QSPI_ADDRESS_24_BITS;

sCommand.AlternateBytesSize = QSPI_ALTERNATE_BYTES_8_BITS;

sCommand.DummyCycles = QSPI_DUMMY_CLOCK_CYCLES_CYPRESS_QREAD_45_MHZ;

sCommand.InstructionMode = QSPI_INSTRUCTION_1_LINE;

sCommand.AddressMode = QSPI_ADDRESS_4_LINES;

sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_4_LINES;

sCommand.DataMode = QSPI_DATA_4_LINES;

sCommand.NbData = QSPI_PAGE_SIZE;

sCommand.DdrMode = QSPI_DDR_MODE_DISABLE;

sCommand.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY;

sCommand.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;

/*

// above settings doesn't work, but following Alternative is working fine:

sCommand.Instruction = eQSPI_CMD_QUAD_OUT_FAST_READ;

sCommand.AddressMode = QSPI_ADDRESS_1_LINE;

sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;

*/

Maybe somebody has a Hint for me?

0 Likes
1 Solution
Anonymous
Not applicable

Hi,

I solved the Problem on Monday ... It was related to 2 Things:

#1 The most importent was, that my QSPI-Chip from Cypress was somehow faulty. It can really not answer (anymore) to the Cmd 0xEB. Maybe this was related to the by Mistake set BP-Bits. I tested same Driver (with a bit Abstraction) on Micron-Chips and it worked. Than I tested it on another custom-PCB with Cypress-Chip and the 0xEB was answered too. But only on first Request.

#2 For the second (and following) Requests I additionally needed to fix a bit the Handling of the STM32-HAL-Driver to avoid resending the 0xEB-Cmd if previous 0xEB contains the 0xA0 Mode Byte (alias Alternative Byte for STM).

Anyway thanks for Patience and giving Hints!

View solution in original post

0 Likes
8 Replies
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi,

Can you double check the CR1V value? Is the Quad Bit (Bit 1) set to 1?

Thanks,

Zhi

0 Likes
Anonymous
Not applicable

For Testing I added a read of CR1V before every PageRead.

If I read the Flash with 0x6B I get back 0x2A = 0b00101010 every Time. By Mistake I had probably set the middle BP-Bit in non-volatile. But my Tests are operating only on the first Kilobytes, so this should not be a Problem. I still can erase the Flash and write different Content to it.

If I read the Flash with 0xEB I get back 0x2A = 0b00101010 only before first Read. This read seems to trigger something strange in the Chip so that I get the Answers only on 3 Lines. And than all later reads of CR1V returns 0x3F until next Reset.

Anyway, the Quad Bit is there. Otherwise also the 0x6B wouldn't work.

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi,

I don't quite understand what you meant. 0x6B and 0xEB are read commands for reading the memory array. Reading CR1V should be done by 0x35 command. Can you issue 0x35 command and let me the value the device returns? You can just read one byte.

Thanks,

Zhi

0 Likes
Anonymous
Not applicable

Ok, again in other words:

- from Cmd 0x35 I get 0b00101010

- after reading with a 0x6B a following 0x35 gives also the 0b00101010

- after reading with a 0xEB a following 0x35 gives a 0b00111111 - the 0xEB-Cmd somehow confuses my QSPI-Chip

And I still have this Problem. The QSPI-Flash is answering on 0x6B with correct 4 Lines but on 0xEB only on 3 Lines. Reading the whole Flash with 0x6B is not a Problem.

As far as I understand, there are only some Differences for the 0xEB-Cmd: the MCU must be setup to send the Address + Mode-Bits + DummyClockCycles on 4 Lines. And I think, that I do this right, because the QSPI-Flash is answering although with not using the 4. Line ...

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi,

You indicated reading with 0x6B had no problem, then you mentioned:

- after reading with a 0x6B a following 0x35 gives also the 0b00101010

This sounds like a problem to me. 0x6B, Quad Output Read command, should not return the value of CR1V.

Can you send a waveform for this particular case to describe what you mean?

Your understanding of the 0xEB command is correct. I don't know why IO3 does not move at this time.

Thanks,

Zhi

0 Likes
Anonymous
Not applicable

I meant that I called the 0x35 after a 0x6B. In your first Response you asked me to "Double-Check" the CR1V and I did this also in a Loop after reading Memory-Pages. The 0x6B itself gives right Results.

I think, if there is a Configuration-Problem, this maybe comes from the Phase of sending Address + Mode-Bits + DummyClockCycles? This Phase is for both Commands in the Screenshots of initial Post.

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi,

Are you using the 0xEB command to read right after using 0x6B command to read? Just to make sure the data in the flash were not changed in between these two reads.

Your waveforms look OK to me. The only difference between the 0x6B and 0xEB command is the mode cycle. Are you sure the host will release IO3, i.e. tristate it, after sending the mode command?

Thanks,

Zhi

0 Likes
Anonymous
Not applicable

Hi,

I solved the Problem on Monday ... It was related to 2 Things:

#1 The most importent was, that my QSPI-Chip from Cypress was somehow faulty. It can really not answer (anymore) to the Cmd 0xEB. Maybe this was related to the by Mistake set BP-Bits. I tested same Driver (with a bit Abstraction) on Micron-Chips and it worked. Than I tested it on another custom-PCB with Cypress-Chip and the 0xEB was answered too. But only on first Request.

#2 For the second (and following) Requests I additionally needed to fix a bit the Handling of the STM32-HAL-Driver to avoid resending the 0xEB-Cmd if previous 0xEB contains the 0xA0 Mode Byte (alias Alternative Byte for STM).

Anyway thanks for Patience and giving Hints!

0 Likes