I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in standard 8 pin package. I'm not sure I correctly understood the quad mode. It appears to me two quad modes are supported: SPI Quad mode (IOC=1 in Configuration Register) and SQI mode (after sending Enable Quad I/O command). For example, after setting IOC bit in Configuration Register I can use SQOR command (SPI Quad Output Read) to output data from SIO[3:0] pins. A similar behaviour can be obtained after enabling SQI mode (sending EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B). What is the difference? I think the difference is only in the data transmitted by the SPI master: opcode byte, address bytes and dummy bytes. In the first case, they are transmitted serially on a single signal (SI/SIO0); in SQI mode, they are transmitted serially on 4 signals (SIO[3-0]). The behaviour on data transmitted by the serial Flash should be exactly the same: they are transmitted on the 4 signals SIO[3-0]. Is my understanding correct? I think the penalty of the first Quad mode respect the SQI mode is very small.
SPI Quad Serial Flash: two "quad" modes?
Started by ●April 4, 2023
Reply by ●April 4, 20232023-04-04
On 2023-04-04, pozz <pozzugno@gmail.com> wrote:> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in > standard 8 pin package. > > I'm not sure I correctly understood the quad mode. It appears to me > two quad modes are supported: SPI Quad mode (IOC=1 in Configuration > Register) and SQI mode (after sending Enable Quad I/O command). > > [...] > > [...] I think the difference is only in the data transmitted by the > SPI master: opcode byte, address bytes and dummy bytes. In the first > case, they are transmitted serially on a single signal (SI/SIO0); in > SQI mode, they are transmitted serially on 4 signals (SIO[3-0]).That sounds right -- that's how I remember it.> The behaviour on data transmitted by the serial Flash should be > exactly the same: they are transmitted on the 4 signals SIO[3-0]. > > Is my understanding correct?I think so.> I think the penalty of the first Quad mode respect the SQI mode is > very small.For things like a bootloader which sends one read command and then shifts out many KB of data, the difference is not noticable. You might be able to see a difference if you do a lot of large writes. or a lot of very small reads. -- Grant
Reply by ●April 5, 20232023-04-05
On 04/04/2023 22:57, pozz wrote:> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in > standard 8 pin package. > > I'm not sure I correctly understood the quad mode. It appears to me two > quad modes are supported: SPI Quad mode (IOC=1 in Configuration > Register) and SQI mode (after sending Enable Quad I/O command). > > For example, after setting IOC bit in Configuration Register I can use > SQOR command (SPI Quad Output Read) to output data from SIO[3:0] pins. > > A similar behaviour can be obtained after enabling SQI mode (sending > EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B). > > What is the difference? I think the difference is only in the data > transmitted by the SPI master: opcode byte, address bytes and dummy > bytes. In the first case, they are transmitted serially on a single > signal (SI/SIO0); in SQI mode, they are transmitted serially on 4 > signals (SIO[3-0]). The behaviour on data transmitted by the serial > Flash should be exactly the same: they are transmitted on the 4 signals > SIO[3-0]. > > Is my understanding correct?Yes. In SPI Quad mode, /data/ is send 4 bits per clock (or twice that, for double data rate pins). In SQI mode, /everything/ is sent 4 bits at a time.> > I think the penalty of the first Quad mode respect the SQI mode is very > small.It all depends on your clock speeds, your mix of reads and writes, your wait states, the length of your transfers, etc. If you are doing big transfers then there will be little difference since most clocks are data anyway. For lots of small transfers with few wait states, SQI will make a bigger difference. (And if you are doing big data transfers, you might also want to enable double data rate on the pins, if your hardware supports it.)
Reply by ●April 11, 20232023-04-11
Il 05/04/2023 17:52, David Brown ha scritto:> On 04/04/2023 22:57, pozz wrote: >> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in >> standard 8 pin package. >> >> I'm not sure I correctly understood the quad mode. It appears to me >> two quad modes are supported: SPI Quad mode (IOC=1 in Configuration >> Register) and SQI mode (after sending Enable Quad I/O command). >> >> For example, after setting IOC bit in Configuration Register I can use >> SQOR command (SPI Quad Output Read) to output data from SIO[3:0] pins. >> >> A similar behaviour can be obtained after enabling SQI mode (sending >> EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B). >> >> What is the difference? I think the difference is only in the data >> transmitted by the SPI master: opcode byte, address bytes and dummy >> bytes. In the first case, they are transmitted serially on a single >> signal (SI/SIO0); in SQI mode, they are transmitted serially on 4 >> signals (SIO[3-0]). The behaviour on data transmitted by the serial >> Flash should be exactly the same: they are transmitted on the 4 >> signals SIO[3-0]. >> >> Is my understanding correct? > > Yes. > > In SPI Quad mode, /data/ is send 4 bits per clock (or twice that, for > double data rate pins). In SQI mode, /everything/ is sent 4 bits at a > time.Ok, now suppose you would like to work in SQI mode. During startup you send the Enable SQI command over a single data line (MOSI). From now on, you can send SQI commands using 4 data lines even for command code byte (two clocks). However you can't be sure at startup the Flash is in normal SPI mode. This happens when you power up the board, but it's not true when the MCU resets itself (for example, for watchdog). What could be the initialization process to bring the SPI Flash in SQI mode at startup, without knowing if it is already in SQI mode or not?>> I think the penalty of the first Quad mode respect the SQI mode is >> very small. > > It all depends on your clock speeds, your mix of reads and writes, your > wait states, the length of your transfers, etc. If you are doing big > transfers then there will be little difference since most clocks are > data anyway. For lots of small transfers with few wait states, SQI will > make a bigger difference. > > (And if you are doing big data transfers, you might also want to enable > double data rate on the pins, if your hardware supports it.)What do you mean with DDR here?
Reply by ●April 11, 20232023-04-11
On 11/04/2023 08:46, pozz wrote:> Il 05/04/2023 17:52, David Brown ha scritto: >> On 04/04/2023 22:57, pozz wrote: >>> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory >>> in standard 8 pin package. >>> >>> I'm not sure I correctly understood the quad mode. It appears to me >>> two quad modes are supported: SPI Quad mode (IOC=1 in Configuration >>> Register) and SQI mode (after sending Enable Quad I/O command). >>> >>> For example, after setting IOC bit in Configuration Register I can >>> use SQOR command (SPI Quad Output Read) to output data from SIO[3:0] >>> pins. >>> >>> A similar behaviour can be obtained after enabling SQI mode (sending >>> EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B). >>> >>> What is the difference? I think the difference is only in the data >>> transmitted by the SPI master: opcode byte, address bytes and dummy >>> bytes. In the first case, they are transmitted serially on a single >>> signal (SI/SIO0); in SQI mode, they are transmitted serially on 4 >>> signals (SIO[3-0]). The behaviour on data transmitted by the serial >>> Flash should be exactly the same: they are transmitted on the 4 >>> signals SIO[3-0]. >>> >>> Is my understanding correct? >> >> Yes. >> >> In SPI Quad mode, /data/ is send 4 bits per clock (or twice that, for >> double data rate pins). In SQI mode, /everything/ is sent 4 bits at a >> time. > > Ok, now suppose you would like to work in SQI mode. During startup you > send the Enable SQI command over a single data line (MOSI). From now on, > you can send SQI commands using 4 data lines even for command code byte > (two clocks). > > However you can't be sure at startup the Flash is in normal SPI mode. > This happens when you power up the board, but it's not true when the MCU > resets itself (for example, for watchdog). > > What could be the initialization process to bring the SPI Flash in SQI > mode at startup, without knowing if it is already in SQI mode or not?Connect the processor reset and the Flash reset. Failing that, I suspect you'll find that if you try to send the SPI code for enable SQI mode while you are already in SQI mode, you'll not do any harm.> > >>> I think the penalty of the first Quad mode respect the SQI mode is >>> very small. >> >> It all depends on your clock speeds, your mix of reads and writes, >> your wait states, the length of your transfers, etc. If you are doing >> big transfers then there will be little difference since most clocks >> are data anyway. For lots of small transfers with few wait states, >> SQI will make a bigger difference. >> >> (And if you are doing big data transfers, you might also want to >> enable double data rate on the pins, if your hardware supports it.) > > What do you mean with DDR here?Double data rate - data pin changes on both rising and falling edges of the clock. Many QSPI flash chips support it.
Reply by ●April 11, 20232023-04-11
On 4/10/2023 11:46 PM, pozz wrote:> Ok, now suppose you would like to work in SQI mode. During startup you send the > Enable SQI command over a single data line (MOSI). From now on, you can send > SQI commands using 4 data lines even for command code byte (two clocks). > > However you can't be sure at startup the Flash is in normal SPI mode. This > happens when you power up the board, but it's not true when the MCU resets > itself (for example, for watchdog).This is the bane of all devices that have "modes"; how do you know that the I/O pins that you've "programmed" to be outputs are actually outputs, NOW? Or, that any device requiring a multicycle transaction is in the state where it is expecting the first of those cycles to be issued, next, in time? I've found it prudent to have an entry point in the code (called "RESET") that is treated as an adjective and verb: - the system is *in* the reset state - reset the system *to* that state This ensures that any assumptions one can make for a *device* coming out of (hardware) RESET apply any time the code executes from that point. The device can reach that point: - through the normal PoR process - through a watchdog or other sentinel - through a random crash - as a result of panic() I usually (start) write this as one of the first pieces of production code as it gives me a chance to think about how the hardware "comes up" (you have to think about EVERYTHING, not just the CPU/MCU itself) and whether or not that can pose problems after deployment (e.g., what if the motors aren't guaranteed to be stopped, at this point in time?) It also gives you an idea of those parts of your hardware interface that need to be atomic, accessed via monitors, etc. Esp if two different active entities (e.g., two threads, a thread and an ISR, etc.) can compete for the device "in some yet unforeseen scenario".> What could be the initialization process to bring the SPI Flash in SQI mode at > startup, without knowing if it is already in SQI mode or not?Again, applies to every aspect of a system that has modes (embedded state). You look at the device and posit the different possible "states" that the interface may be in; then figure out which assumptions can allow you to unambiguously drive the interface to a particular state from which behavior is reliable. E.g., you may opt to put the device in the "wrong" state (temporarily) if only because getting it *there* may be easier to guarantee... then, deliberately transitioning from "there" to wherever you'd ultimately like it to be. E.g., multicycle interfaces often abort their sequences if a read occurs when a write is expected (or, might be encountered). So, assuming a read to be "safe" (for that particular device/situation), you do one or more reads (discarding the data, if necessary) before you start the multicycle *write* sequence. Consider a video LUT. Often, you have to write the address of the location of interest *within* the LUT to the device before you can read or write. If you think the device is waiting for this "specify address" portion of its interface cycle and send "0x44" to it (because you want to access the 0x44th entry) but, instead, it was already in the "address specified, waiting for read/write" mode, then your 0x44 will clobber some "random" (as in, "location that you can't predict" because you don't know what address had been specified prior to your barging in on the interaction) location. And, your subsequent "here's the data that I want to write" will, instead, be interpreted as the next *address* that you want to access thereby perpetuating the dyssynchrony. OTOH, if you had done a *read* operation and knew that this would reset the little state machine inside the LUT to "waiting for next address", then that throw-away action can serve to get the interface back into lock-step with the code (assuming you don't wedge it later). The pisser is that you have to come up with a strategy that will work for any device that might be placed in that role (as the design evolves).>>> I think the penalty of the first Quad mode respect the SQI mode is very small. >> >> It all depends on your clock speeds, your mix of reads and writes, your wait >> states, the length of your transfers, etc. If you are doing big transfers >> then there will be little difference since most clocks are data anyway. For >> lots of small transfers with few wait states, SQI will make a bigger difference. >> >> (And if you are doing big data transfers, you might also want to enable >> double data rate on the pins, if your hardware supports it.) > > What do you mean with DDR here?Instead of a cycle being defined by a rising (falling) "clock" edge, it is defined by rising *and* falling edges. So, you get twice the throughput for a given "cycle" (without having to double the "clock" frequency).
