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.
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:
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.
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.
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
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:
or
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")
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:
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
That's the first trema I've seen on the TI EE Forums. Good on ya!
( can't find your # KISS-KISS-Forever! tag... )