- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a custom board with S25FL256S external flash
I try to read in quad mode, it works but the read speed is the same as when I use commands 0x13 (4READ) or 0x0C (4FAST_READ ) or 0x6C (4QOR ) or 0xEC (4QIOR), all give the same read speed.
I measure the time to read one sector of 64KB, and quad mode reading doesn’t seem to speed reading time.
I'm In quad mode, I set configuration register to 0x02 (quad mode enabled).
The data that I read is correct (because the total sum of the data and that’s what I get after reading).
I was hoping quad read commands 4QOR and 4QIOR would be close to 4 times faster
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
From QSPI_CLK.jpg, definitely the problem is due to extra overhead. As you noticed, the active clocks only has around ~15% of the overall read time. So Quad mode actually only improves ~10% overall read time.
Regard to the questions,
Why Am I reading 32 bits at a time? Why the clock is off 85% of the time?
The answer to those questions are the clock is input signal for flash, flash does not have any control of it. This may be due to software overhead or controller configuration.
Thank you
Regards,
Bushra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I spent more on this
We have a 180MHZ, Quad prescaler set to 1. So External Flash clock is 90Mhz.
I set CR[1] to 1 (i.e. second bit to 1) in the configuration register.
I write in a whole sector (65536 bytes) numbers from 0 to 255 and then again 0 to 255 and then again 0 to 255. Basically I write k%256, k is the index in the External flash (index ranging from 0 to 65535). The total sum of all numbers in the sector is 0x7F8000.
Using Quad mode, I correctly read the sector data. Sum of all the 65536 bytes I read is 0x7F8000 (which is correct), but the time to read is not 4 times (or closer to 4 times) faster than the non-quad mode.
Problem I noticed is that in quad mode, the SPI_CLK duty cycle is about 15% (a burst of 8 clock cycles: 8x4bits), so a burst of 32 bits then nothing for a while (image QSPI_CLK.jpg). Image QSPI_CLK Burst.jpg shows a zoomed out 8 clock cycles (I used a cheapy scope: never mind the quality of the signals).
When I pin IO0, I see the same issue, a burst of data out, but nothing happens for a while.
I attached a snippet of my function that reads the whole sector and put in external RAM.
I use HAL_QSPI_Receive to read.
Why Am I reading 32 bits at a time?
Why the clock is off 85% of the time?
thanks
Code Snippet:
bool ReadSectorExtEEPromToSRAM(uint32_t adrExtEEProm, uint8_t* pAdrExtRAM)
{
QSPI_CommandTypeDef s_command;
s_command.Instruction = 0x6C;
s_command.InstructionMode = QSPI_INSTRUCTION_1_LINE;
s_command.AlternateBytes = 0xA0;
s_command.AlternateBytesSize = QSPI_ALTERNATE_BYTES_8_BITS;
s_command.AddressMode = QSPI_ADDRESS_1_LINE;
s_command.AddressSize = QSPI_ADDRESS_32_BITS;
s_command.DataMode = QSPI_DATA_4_LINES;
s_command.DummyCycles = 8;
s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
s_command.Address = adrExtEEProm;
s_command.NbData = 65536;
s_command.DdrMode = QSPI_DDR_MODE_DISABLE;
s_command.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY;
s_command.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;
if (HAL_QSPI_Command(&hqspi, &s_command, cnQSPITimeoutMs) != HAL_OK)
return false;
// Receive data
if (HAL_QSPI_Receive(&hqspi, pAdrExtRAM, cnQSPITimeoutMs) != HAL_OK)
return false;
return true;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
From QSPI_CLK.jpg, definitely the problem is due to extra overhead. As you noticed, the active clocks only has around ~15% of the overall read time. So Quad mode actually only improves ~10% overall read time.
Regard to the questions,
Why Am I reading 32 bits at a time? Why the clock is off 85% of the time?
The answer to those questions are the clock is input signal for flash, flash does not have any control of it. This may be due to software overhead or controller configuration.
Thank you
Regards,
Bushra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thank you for contacting Infineon Technology.
We think this is software overhead issues. Please hook up Oscilloscopes and see how long is the idle time between clock and IOS.
Thank you
Regards,
Bushra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
From QSPI_CLK.jpg, definitely the problem is due to extra overhead. As you noticed, the active clocks only has around ~15% of the overall read time. I am going to share this thread https://community.infineon.com/t5/Nor-Flash/S25FL256S-not-floridaloteryresults-faster-Reading-in-Quad-mode/td-p/350125 to my kith and kin who want to know about that. So Quad mode actually only improves ~10% overall read time.
Regard to the questions,
Why Am I reading 32 bits at a time? Why the clock is off 85% of the time?
The answer to those questions are the clock is input signal for flash, flash does not have any control of it. This may be due to software overhead or controller configuration.
Thank you