This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: Interfacing to quad SPI Flash

Part Number: TM4C1294NCPDT

I need to interface S70FL01GS which is 1 Gbit (128 Mbyte) 3.0V SPI Flash to Tiva microprocessor. 

This is dual die chip. Two Chip selects to select one other other die for memory access operations.

Does the SPI driver support dual die Quad SPI flashes or do we use it as a standard non quad SPI flash?

The siganls for interfacing to Tiva (for this chip) are:

  1. RESET 
  2. CLOCK
  3. Chip Select 1
  4. Chip Select 2
  5. Serial Input for single bit data commands or IO0 for Dual or Quad commands.
  6. Serial output for single bit data commands or IO0 for Dual or Quad commands.
  7. Write Protect when not in Quad mode. IO2 in Quad mode. The signal has an internal pull-up
    resistor and may be left unconnected in the host system if not used for Quad commands.

  8. Hold (pause) serial transfer in single bit or Dual data commands. IO3 in Quad-I/O mode. The
    signal has an internal pull-up resistor and may be left unconnected in the host system if not used
    for Quad commands.

  9. Core power Vcc
  10. Ground Vss

  • Pavitra Ramanujam said:
    I need to interface S70FL01GS which is 1 Gbit (128 Mbyte) 3.0V SPI Flash to Tiva microprocessor. 

    Often - when attempting something (new/unusual) - best information resides w/in (both) the MCU & Slave Device's datasheets.

    Firm/I have yet to work w/"dual die" chip (unless unknowingly) so I'm limited to suggesting, "methods of attack."

    Might the "dual die" chip's vendor have included (typical) interface diagrams - which serve to model the preferred interface?    Further - sometimes application examples specify the "mating" devices - which then enables your compare/contrast of "successful matings" vs. your TM4C's function capabilities.

    It may prove wise to create so specific an, "interface need" - only after you've convincingly determined that the "need" (really) is required - and may reasonably succeed.      (otherwise - you've effectively placed the cart in front of the horse - never the "best" idea.)

    There are many - quad, dual & single bit SPI memories - which have been proven - some even identified/reported here.      (Forum Search reveals)

  • Pavitra Ramanujam said:
    This is dual die chip. Two Chip selects to select one other other die for memory access operations.

    That should, I think, be neither here nor there. It should just look like two chips to the interface, and pretty similar to two chips electrically as well.

    One caution, by moving from SPI to Quad SPI, you've gone from a synchronous serial bus to a synchronous parallel bus. That'll require greater care in layout, especially at the high rates you are likely to want to use.

    Robert

  • Greetings Robert,

    Might that "dual die" (almost) enable an "8 bit sync'ed parallel bus" - due to the improved - (all on one chip) signal matching? Now I'm unaware of any ARM MCU able to "officially support" two such "Quad SPI Ports" operated "In sync & in parallel." (One vendor's Rep hinted at this as "distant" - I've no other knowledge... yet the dual die (may) be playing to this likely development. (maybe)
  • cb1_mobile said:
    Might that "dual die" (almost) enable an "8 bit sync'ed parallel bus" - due to the improved - (all on one chip) signal matching?

    I doubt it. I haven't checked the pinout but I suspect the I/O lines for both die come to the same pins.

    cb1_mobile said:
    Now I'm unaware of any ARM MCU able to "officially support" two such "Quad SPI Ports" operated "In sync & in parallel."

    Nor am I but Quad SPI isn't on my RADAR. Don't see why it would be necessary though.

    Robert

  • Robert Adsett said:
    Nor am I but Quad SPI isn't on my RADAR. Don't see why it would be necessary though.

    I can read that writing in several ways:

    • You don't see why "Quad SPI" proves superior to "plain jane" (1 lonely bit) SPI.      Surely the wider data path enables, "higher effective "bit transfer rate."

    or

    • You don't see why "Octal SPI" [(c) 2017, cb1, all rights reserved] proves superior to "Quad SPI."     If the case can be made for "Quad SPI" - then a 2x wider data path (to 8 bits) extends that benefit...

    We must note that poster's claimed "need" has not proved sufficient to bring about his response...

  • cb1_mobile said:

    or

    • You don't see why "Octal SPI" [(c) 2017, cb1, all rights reserved] proves superior to "Quad SPI."     If the case can be made for "Quad SPI" - then a 2x wider data path (to 8 bits) extends that benefit...

    This would be the one. But if you are driven by speed requirements then a more conventional standard parallel interface would suffice, or a more sophisticated serial interface. Developing a new parallel interface using SPI doesn't seem to me to be compelling.

    cb1_mobile said:
    We must note that poster's claimed "need" has not proved sufficient to bring about his response.

    Yep, pretty much the sound of crickets. I suspect the needed information was in the first reply or two.

    Robert

  • May the record show, "Poster vocabulary words employed w/ "bent" meaning:"        (interpretation provided by crack staff - cb1 simply  "reporting")

    • Need (hoped for - yet (really) only a "long-shot / pipe-dream.")
    • Easy (only employed when "others" are assigned poster's task/homework)
    • Fast (further "motivation/manipulation" forced upon hapless helpers)
    • Urgent (poster has YET to start - passes the buck to those here - "Avoidance" far better describes poster's behavior) 

    Quad - and even the (hallucinatory)  "Octal SPI"  [(c) 2017, cb1, all rights reserved] eliminate the de-mux chip  required of the (assumed) mux'ed Adr/Data Parallel Bus.    As 65KB is approached - 8 ADDED address lines must be "found/massaged out" - thus it would appear that "Octal SPI's" escaping:

    • the de-mux IC - so often demanded to separate address from data
    • 8 added address lines 
    • and (satisfying) the "clear preference" of  "byte data rather than nibble"

    may  one day - bring about the creation of such "Octal SPI" - nicely expanding (likely completing) the SPI crüe...     

  • cb1_mobile said:
    Quad - and even the (hallucinatory)  "Octal SPI"  [(c) 2017, cb1, all rights reserved] eliminate the de-mux chip  required of the (assumed) mux'ed Adr/Data Parallel Bus.

    That would be one way of doing it but ware assumptions, you could also use a counter for the address lines if working that way.One write to load a base address (and clear the counter) followed by any number of successive reads or writes. That's essentially how SPI memories already work.

    The advantage of direct addressing (as you described and rather than counter described) is that on any system with enough memory for this to be a concern you already have the memory bus brought out, otherwise you would not have enough memory to make the extra speed desirable. And you get immediate random access to any individual location. Now when you have a chip with 10's of meg of RAM on the die that calculus may change.

    However, I was actually thinking of ATA which is essentially designed for this purpose or if that's too slow you could go to SATA.  I don't see the utility of re-inventing ATA when it already exists.

    Robert

  • Once more - you've countered w/good & thoughtful points.

    That said - the fact that there exists (strong) movement from "single bit SPI" - to its "Quad big brother" - opens the door for, "Four more bits!"

    We shall see - again - nameless/faceless Rep (not from here) conveyed (while under interrogation) that "such was under (high) consideration!"
  • That's the first trema I've seen on the TI EE Forums. Good on ya!

    ( can't find your # KISS-KISS-Forever! tag... )