I think you are taking my support of what Chip wants to do as me only wanting that. I personally would be fine with 4 pin mode being used, but still only doing what Chip has done so far in the ROM code.
The only difference from Chips plan, is that Chip feels 3 pin mode discourages people using QPI mode more. So, they won't get into bad states which require power cycling to recover. 4 pin mode allows for people to do QPI if they want, and they have to deal with the reset situations themselves if they have the flash in QPI mode and a reset happens.
Only you can't actually kick the can down the road, as you advocate.
"deal with the reset situations themselves" is easy to say, but the reality is, you cannot fix later in SW, what you cannot boot from!!
Quad exists already in the real world, users will expect it, and the part I find hardest to comprehend here is, adding the Quad reset preambles is not rocket science!!.
Peter tested some, in less time than it took me to type this. Quite the opposite of 'complicated', or 'unsafe'.
I think part of the problem is that we haven't convinced Chip that there is a use for QPI beyond just booting the P2 and he doesn't feel that the slight increase in boot speed is worth "wasting" three more pins. We need to make a compelling case that people will want fast access to the flash after boot.
I think part of the problem is that we haven't convinced Chip that there is a use for QPI beyond just booting the P2 and he doesn't feel that the slight increase in boot speed is worth "wasting" three more pins. We need to make a compelling case that people will want fast access to the flash after boot.
Where does the 'waste three more pins' come from ?
The Boot decision tree I give in #1, tries 3 pin mode, then tries 4 pin mode if any Flash ID is not found.
4 pin mode is all you need to send commands to exit Quad Mode, which is all BOOT needs to do.
BOOT has no need to use more pins, as it is always operating in 1-bit SPI, and needs know nothing more about QuadMode, apart from the safe & simple 1-bit-mode preambles, sent to exit from any possible quad modes.
99% of the time, those preambles are simply ignored, if the SPI/SD part is not in Quad mode.
I think part of the problem is that we haven't convinced Chip that there is a use for QPI beyond just booting the P2 and he doesn't feel that the slight increase in boot speed is worth "wasting" three more pins. We need to make a compelling case that people will want fast access to the flash after boot.
Where does the 'waste three more pins' come from ?
Not sure. I think he's still thinking of the simple serial/flash boot tree he originally proposed. Maybe he'll see this and explain.
Regarding QPI, I don't think trading 3 pins for what will most likely be an imperceptible decrease in boot time for most projects is a good idea. Keeping the door open for SD cards would be way more important.
Can the SD card share the same pins as the SPI boot flash if you tie DI to DO as you've been suggesting?
Please don't join DI & DO together. It's not a nice engineering solution and can preclude sharing this pin.
On P1 I share the I2C pins in different ways on different boards. If P2 has SPI, then I can share those pins too provided you haven't joined DI & DO.
... Keeping the door open for SD cards would be way more important.
Even if you could connect SD SDI to SDO (which I would be wary of..), I find this on SE, re SDIO modes...
["An SD card comes up by default in 1-bit SD mode, but can be changed into 4-bit mode after startup. If necessary, the card can also be switched into SPI mode, which is always 1-bit wide. The bus width in SD mode can be anywhere from 1 to 4-bits (see 6.2.1). There isn't any 8-bit SD mode, because there aren't enough pins on the SD card to support it. There is an 8-bit SD mode for MMC (MultiMediaCard) cards which have more pins.
I don't see where anyone would want to run in SD mode with less than four data lines, unless they were limited for I/O lines. So let's forget about that."]
To me that says you do need to cover Quad-mode-exit commands, in order to support SD-Boot, and you get QuadSPI mode for free then.
Actually, from everything I have read, the SD Card powers up in it's native mode, which is 4-bit mode. However, by giving it a precise sequence of command(s) it places the card into SPI 1bit mode (with separate DI & DO pins). A problem I have found sharing these pins is that the SD card requires a sequence of clocks to force it to release the DO from a driven high state. I have modified all the standard SD drivers for P1 to do this sequence. Kye's FAT driver does includes this modification.
For P2, I would like to reserve the extra pins in the correct sequence, just as I would like to reserve the QSPI pins in correct sequence, bu dedicating the right pins in the P56:P63 section. If a user does not require these modes, then these pins can remain unconnected to the P2 and then are free for the user to use.
This is why I am pleading for D0..D3 to be on P56..P59 and in correct order.
I think part of the problem is that we haven't convinced Chip that there is a use for QPI beyond just booting the P2 and he doesn't feel that the slight increase in boot speed is worth "wasting" three more pins. We need to make a compelling case that people will want fast access to the flash after boot.
Where does the 'waste three more pins' come from ?
Not sure. I think he's still thinking of the simple serial/flash boot tree he originally proposed. Maybe he'll see this and explain.
I think he said it was for smaller P2 versions with very few I/O lines.
We need to understand the hardware connection possibilities before a PROPER software boot solution can be found !!!
What Chip is giving us is fine for testing the P2 out. We can adjust this and even try out our own solutions using other pins and out own boot code. Without this, we cannot try out booting for ourselves because of the need to reset the FPGA.
Regarding QPI, I don't think trading 3 pins for what will most likely be an imperceptible decrease in boot time for most projects is a good idea. Keeping the door open for SD cards would be way more important.
Can the SD card share the same pins as the SPI boot flash if you tie DI to DO as you've been suggesting?
Please don't join DI & DO together. It's not a nice engineering solution and can preclude sharing this pin.
On P1 I share the I2C pins in different ways on different boards. If P2 has SPI, then I can share those pins too provided you haven't joined DI & DO.
About joining DI and DO together: The SPI device will never drive DO unless CS is low and a command to output has been received on DI. This does not preempt that shorted DI/DO pin pair from also connecting to, say, D3 on an SD card which has its own CS (or is it CMD?).
Actually, from everything I have read, the SD Card powers up in it's native mode, which is 4-bit mode. However, by giving it a precise sequence of command(s) it places the card into SPI 1bit mode (with separate DI & DO pins).
.. Then that makes Quad-Exit handling 'housekeeping code', even more important.
A problem I have found sharing these pins is that the SD card requires a sequence of clocks to force it to release the DO from a driven high state.
I have modified all the standard SD drivers for P1 to do this sequence.
Kye's FAT driver does includes this modification.
Do you mean it powers-up driving DO ?
Does it need a 0xff / 0xffff / ?? command on DI, or just some N number of clocks ?
Actually, from everything I have read, the SD Card powers up in it's native mode, which is 4-bit mode. However, by giving it a precise sequence of command(s) it places the card into SPI 1bit mode (with separate DI & DO pins).
.. Then that makes Quad-Exit handling 'housekeeping code', even more important.
Yes, for SD it is required to place the SD in SPI mode
A problem I have found sharing these pins is that the SD card requires a sequence of clocks to force it to release the DO from a driven high state.
I have modified all the standard SD drivers for P1 to do this sequence.
Kye's FAT driver does includes this modification.
Do you mean it powers-up driving DO ?
Does it need a 0xff / 0xffff / ?? command on DI, or just some N number of clocks ?
Here is a suggested hardware interface with the resultant software decisions...
This makes the boot software easily detect what is on the various boot pins by checking for external (outside the P2) pullup/pulldown resistors on certain pins. This makes the sequence quick and reliable.
PS I could not recall what makes the P1 skip looking for a serial load. IIRC it is a longer low (start) on the SI/P31 pin. Note when referring to the P1 SI pin number is P31 and not P2 P63 of course).
Do you mean it powers-up driving DO ?
Does it need a 0xff / 0xffff / ?? command on DI, or just some N number of clocks ?
Just a number of clocks with nCS=High
Do you know how many clocks are required ?
I'm guessing it is not driving DO when nCS is hi, but will on nCS=L unless X Clocks are delivered.
That sounds an easy, common, preamble to include.
You must set /CS=1 (ie deselect) and then send it some clocks. Initially we sent lots of clocks.
Seems like just a few characters worth of clocks is fine now.
The SD still drives its DO (=1 IIRC) even though /CS goes high to deselect. This is the problem!
It is easy once you realise where the problem is!
Oh, and it is a different problem to the initialisation (or soft reset) of the SD card.
4 pin SPI with an external resistor can be effectively the 3 pin solution Chip wants, while allowing for QSPI parts for those who want to use them.
There are actually two parts to this problem.
ROM-Quad-exit, and the optional ability to Quad Drive.
Even using a resistor, you do still need to have the simple few reset-preambles I've detailed in #1
If you cannot boot, you cannot 'apply user reset later'. This bit is the brick-wall fish-hook.
Note those preambles are present on both 3P and 4P, and that is actually simpler, as the 3P to 4P change is a single
DO pin-map-define step, in the outer tree. All the inner SPI code can be common.
Those serial preambles ensure most QSPI parts will exit Quad mode, for boot.
Once that Preamble code is in there, yes, Parallax can freely choose what they offer users :
a) ROM with automatic 3P-4P connection, based on PCB wiring, which is what Post #1 provides. Simple Plug and run.
Note if a 3P connected part is found, 4P is not used and the extra pin is saved.
b) ROM with 3P only mode, with associated explanations of an external resistor, along with documents on the limits of that resistor,
and how that relates to the Clocks speeds they may be running in their own code. Those who overlook these documents will have to live with their PCB re-spins. ( This will be zero, because everyone fully reads manuals, right ? )
Support questions around this will be on-going, 2017,2018,2019...
4 pin SPI with an external resistor can be effectively the 3 pin solution Chip wants, while allowing for QSPI parts for those who want to use them.
There are actually two parts to this problem.
ROM-Quad-exit, and the optional ability to Quad Drive.
Even using a resistor, you do still need to have the simple few reset-preambles I've detailed in #1
If you cannot boot, you cannot 'apply user reset later'. This bit is the brick-wall fish-hook.
Note those preambles are present on both 3P and 4P, and that is actually simpler, as the 3P to 4P change is a single
DO pin-map-define step, in the outer tree. All the inner SPI code can be common.
Those serial preambles ensure most QSPI parts will exit Quad mode, for boot.
Once that Preamble code is in there, yes, Parallax can freely choose what they offer users :
a) ROM with automatic 3P-4P connection, based on PCB wiring, which is what Post #1 provides. Simple Plug and run.
Note if a 3P connected part is found, 4P is not used and the extra pin is saved.
b) ROM with 3P only mode, with associated explanations of an external resistor, along with documents on the limits of that resistor,
and how that relates to the Clocks speeds they may be running in their own code. Those who overlook these documents will have to live with their PCB re-spins. ( This will be zero, because everyone fully reads manuals, right ? )
Support questions around this will be on-going, 2017,2018,2019...
I agree about the DI-to-DO resistor being a bad idea. It could cause severe speed limitations.
If you're not supporting QPI, there is no reason to do discrete DI and DO connections. They can be one wire.
Going beyond three wires means going to six wires and issuing all the 'exit-QPI' commands and then all the 'reset' commands you can learn about. Or, after all the 'exit-QPI' commands, wait out any erase or program that is in-progress.
Of course, there's the reset input that exists on some SPI flash chips that would be much better to use.
Three-wire is the most sure-fire approach and it reduces the pin ghetto. Going beyond three pins is a huge step.
Going beyond three wires means going to six wires and issuing all the 'exit-QPI' commands and then all the 'reset' commands you can learn about. Or, after all the 'exit-QPI' commands, wait out any erase or program that is in-progress.
I'm really not following this ? - you can issue EXIT QPI commands even in 3-pin mode, to the majority of P2-target parts.
The next step after 3-Pin mode, is 4 pin, as shown in #1.
It is actually very easy to test and confirm - Just add some RESET preambles to your 3-bit code, and release to users.
User can place various parts into Quad mode, using that 3 Pin connection, and then try Reboot, and report back.
There is always Power Cycle recovery during these tests.
Of course, there's the reset input that exists on some SPI flash chips that would be much better to use.
See above, on the Winbond data I have here, the combined Hold/Reset pin does not work, in Quad mode....
A Higher pin count package (SO16N, or BGA)** does have a separate reset pin.
To use that separate pin, (no longer shared) you have increased the pin impact to users wanting Software reboot.
It is probably tolerable to those using external watchdogs, as they connect watchdog to P2.RESET and SO16N.RESET
Three-wire is the most sure-fire approach and it reduces the pin ghetto. Going beyond three pins is a huge step.
? The next step above 3 pin, is 4 pin ?
** just checked Digikey, who have 2,939 entries under Serial Flash.
For SO16N, they list just 1 part, (N25Q032A11ESF40G-ND) not stocked, no price given.
For wide body SO16W, they list 452 parts, price starts at 40c/3k (no stock) for 32MBit
For stocks > 100 pcs, price is 64c/3k.
(compare with sub 15c/3k start for SO8 mainstream standard package)
.....
I agree about the DI-to-DO resistor being a bad idea. It could cause severe speed limitations.
If you're not supporting QPI, there is no reason to do discrete DI and DO connections. They can be one wire.
Going beyond three wires means going to six wires and issuing all the 'exit-QPI' commands and then all the 'reset' commands you can learn about. Or, after all the 'exit-QPI' commands, wait out any erase or program that is in-progress.
Of course, there's the reset input that exists on some SPI flash chips that would be much better to use.
Three-wire is the most sure-fire approach and it reduces the pin ghetto. Going beyond three pins is a huge step.
Chip,
If you are intent on using 3 wires, then please please please consider the 2 wire I2C 24Cxxx (32/64/128/235/512/1024) as an option, followed by 4 wire SPI FLASH & 4 wire SD.
Note that these pins need to be routed with gaps so that we can chose to do QSPI or SD 4bit if we wish to.
My diagram above shows how to test simply by looking for pullups/pulldowns.
The EEPROM can co-exist on the same pcb as FLASH without problems.
The flash can then be configured by user software into QSPI if desired using a tiny SOT23-5 or WLCSP-4 or DFN-8 etc. Just read in 4KB (ie presume 24C32 initially) which will be the same as reading the first 4KB of any of the 24Cxxx parts above.
The SOT23-5 and WLCSP-4 are NEW parts!
BTW I will have SD 1bit boot code for testing shortly - I will be posting code for P1 testing as many users have SD on their props, or easy to add to test for us. I found an SD Card that does not follow the initialisation sequence properly. I can make it work, so I am just looking for the common key to this solution.
Jmg, I did see in one datasheet that the exit-QPI instruction was $F5 or $5F, which would take 4 data pins to signal.
I've focused on P2-likely Flash, and a good example there is the AT25SF041 data.
(FT25H16 has the same commands, 0xff, 0xffff, but has some typos - this very cheap part, can hold 4 P2 images )
AT25SF041 data shows only DI is needed for exit via 0xff, or 0xffff, and this is because the sticky-quad-state needs M4 bit = 0 to continue in Quad.
That M4 bit arrives on DI-pin(IO0) , in the 6th Clock edge, if the Chip is in Quad Mode.
Other bits do not care, as you deselect before any read occurs.
In dual mode, the M4 bit arrives later, which is why 16 clocks 0xffff are needed
Dual mode would be rare, but it is very easy to include, so I did that.
Larger parts like Winbond W25Q32JV, use a dual-byte 0x66/0x99 keyed reset, and that is clearly shown driven into only IO0.
To do this, I think they have a special state engine, that is mode-independent, and it uses the double CS with no gaps rule, to avoid false triggers in any other normal use condition.
The trend on larger parts, seems to be to use the dual-byte 0x66/0x99 (which is why it is also in the preambles, I gave in #1)
IIRC Peter tested this on a smaller variant, with no side effects.
Updated Post#2 : I thought I had found a part for the "don't use" column, but it is just poorly written.
Deeper reading shows it does have an M4 bit exit mode. Intern wrote the data ?
I am going to order and try some WLSCP-4 parts.
They are really tiny 0.8x0.68@0.4mm pitch.
On the topic of smallest, I found a QuadSPI flash 16Mbit part in USON2x3. (smaller than SOT23-5)
That uses the 0x66,0x99 reset command, added to list in #2.
Jmg, to solve the SPI-flash-reset problem, could a list of QPI and SPI commands be made so that we know what is required to handle discrete DI/DO signalling (which also means DQ3..DQ0)?
Here is a fact, as I see it: If you are going to have discrete DI and DO connections, but don't intend to use a 4-bit data path (DQ3..DQ0), you might as well tie DI and DO together and have a single data pin to the Prop2, as there is going to be no significant performance difference (only making the data signal an input before the 8th clock on commands which return data). Given that, the next step up is to wire for DQ3..DQ0 and go through the whole set of exit-QPI and reset commands, so that the flash can be booted from in DI/DO SPI mode. Am I wrong on any of this?
Jmg, to solve the SPI-flash-reset problem, could a list of QPI and SPI commands be made so that we know what is required to handle discrete DI/DO signalling (which also means DQ3..DQ0)?
Sure, I've already listed a suggested-for-test preamble set in #1, which is to send in 1-bit mode, this
(it does not need DQ3..DQ0)
(0xff,0xffff,0x66,0x99,wait,0xAB,wait)
ie
CS=\_Send 0xff, 8 clk CS_/=
CS=\_Send 0xffff, 16 clk CS_/=
CS=\_Send 0x66 8 clk CS_/=\_Send 0x99 8 clk CS_/=
Wait is the 30~35us parts spec as Reset Exit.
0xAB exits power down, so gives more coverage.
Just include that, and let users test it in the wild.....even in 3P mode.
Here is a fact, as I see it: If you are going to have discrete DI and DO connections, but don't intend to use a 4-bit data path (DQ3..DQ0), you might as well tie DI and DO together and have a single data pin to the Prop2, as there is going to be no significant performance difference (only making the data signal an input before the 8th clock on commands which return data).
Yes, I see 3pin SPI as a valid connection choice (saves a pin!), but I also see 4 Pin SPI, as the path to Quad SPI.
The problem with 3Pin, is users cannot cleanly PCB route QuadSPI.
Given that, the next step up is to wire for DQ3..DQ0 and go through the whole set of exit-QPI and reset commands, so that the flash can be booted from in DI/DO SPI mode. Am I wrong on any of this?
You still appear to think Quad-connection is needed, as a prerequisite to issue Quad-Exit. That is not correct.
You can issue Quad-Exit commands, even in 3P SPI mode, on all the parts I listed in #2
I have yet to find a recent, competitive, P2-use part that cannot exit Quad, using DIO0 commands only, but there probably is one....
The user then decides, by PCB connection, if they want QuadSPI, & because the ROM can exit QSPI, it can boot using DI/DO SPI mode.
The ROM can pullup HOLD,WP, or, that can be a user-PCB-addition. - once DI,DO are defined, the other pins are obvious (as Cluso mentions)
That's a relatively minor point, some may think enabling even a pullup on 2 other pins during Boot violates the purity of 4-pin.
If boot wants to float those pins, some outside-P2 pullups will be needed.
(Apparently, some vendors include pull-ups on HOLD,WP)
Chip,
It is easy to check if DO & DI are joined in software in the boot software. So I guess you can support both 3 pin and 4 pin SPI without problems - it's just code space
I guess I like Cluso's pinout idea. Except, I might reverse the order of D0..D3 so that if someone wants to use regular SPI flash, there are no gaps in pins.
Then, there are maybe two ways to use SQI.
1. Add a second chip that shares all but CS# pin. So, just needs one more pin.
2. Use RESn to gate of p-channel mosfet to cycle power on SQI chip when there is hardware reset.
Here is a fact, as I see it: If you are going to have discrete DI and DO connections, but don't intend to use a 4-bit data path (DQ3..DQ0), you might as well tie DI and DO together and have a single data pin to the Prop2, as there is going to be no significant performance difference (only making the data signal an input before the 8th clock on commands which return data). Given that, the next step up is to wire for DQ3..DQ0 and go through the whole set of exit-QPI and reset commands, so that the flash can be booted from in DI/DO SPI mode. Am I wrong on any of this?
You forget the DualRead Modes. With 4 pin SPI connection (DI, DO not tied together) you can read data two times as fast as in 1bit SPI mode.
I've done that on FPGA Developmentboards which normally have no Quad compatible connection of the Config-Flash, but Dual mode works always. If you want to execute code from the Flash the double rate helps alot.
The Dual modes also have no sticky variants, they always terminate when /CS goes high.
Comments
Where does the 'waste three more pins' come from ?
The Boot decision tree I give in #1, tries 3 pin mode, then tries 4 pin mode if any Flash ID is not found.
4 pin mode is all you need to send commands to exit Quad Mode, which is all BOOT needs to do.
BOOT has no need to use more pins, as it is always operating in 1-bit SPI, and needs know nothing more about QuadMode, apart from the safe & simple 1-bit-mode preambles, sent to exit from any possible quad modes.
99% of the time, those preambles are simply ignored, if the SPI/SD part is not in Quad mode.
On P1 I share the I2C pins in different ways on different boards. If P2 has SPI, then I can share those pins too provided you haven't joined DI & DO.
Actually, from everything I have read, the SD Card powers up in it's native mode, which is 4-bit mode. However, by giving it a precise sequence of command(s) it places the card into SPI 1bit mode (with separate DI & DO pins). A problem I have found sharing these pins is that the SD card requires a sequence of clocks to force it to release the DO from a driven high state. I have modified all the standard SD drivers for P1 to do this sequence. Kye's FAT driver does includes this modification.
For P2, I would like to reserve the extra pins in the correct sequence, just as I would like to reserve the QSPI pins in correct sequence, bu dedicating the right pins in the P56:P63 section. If a user does not require these modes, then these pins can remain unconnected to the P2 and then are free for the user to use.
This is why I am pleading for D0..D3 to be on P56..P59 and in correct order.
I think he said it was for smaller P2 versions with very few I/O lines.
What Chip is giving us is fine for testing the P2 out. We can adjust this and even try out our own solutions using other pins and out own boot code. Without this, we cannot try out booting for ourselves because of the need to reset the FPGA.
About joining DI and DO together: The SPI device will never drive DO unless CS is low and a command to output has been received on DI. This does not preempt that shorted DI/DO pin pair from also connecting to, say, D3 on an SD card which has its own CS (or is it CMD?).
.. Then that makes Quad-Exit handling 'housekeeping code', even more important.
Do you mean it powers-up driving DO ?
Does it need a 0xff / 0xffff / ?? command on DI, or just some N number of clocks ?
This makes the boot software easily detect what is on the various boot pins by checking for external (outside the P2) pullup/pulldown resistors on certain pins. This makes the sequence quick and reliable.
PS I could not recall what makes the P1 skip looking for a serial load. IIRC it is a longer low (start) on the SI/P31 pin. Note when referring to the P1 SI pin number is P31 and not P2 P63 of course).
I'm guessing it is not driving DO when nCS is hi, but will on nCS=L unless X Clocks are delivered.
That sounds an easy, common, preamble to include.
No.
You must set /CS=1 (ie deselect) and then send it some clocks. Initially we sent lots of clocks.
Seems like just a few characters worth of clocks is fine now.
The SD still drives its DO (=1 IIRC) even though /CS goes high to deselect. This is the problem!
It is easy once you realise where the problem is!
Oh, and it is a different problem to the initialisation (or soft reset) of the SD card.
3 pin SPI eliminates the ability to put QSPI on those pins, which is very bad.
There are actually two parts to this problem.
ROM-Quad-exit, and the optional ability to Quad Drive.
Even using a resistor, you do still need to have the simple few reset-preambles I've detailed in #1
If you cannot boot, you cannot 'apply user reset later'. This bit is the brick-wall fish-hook.
Note those preambles are present on both 3P and 4P, and that is actually simpler, as the 3P to 4P change is a single
DO pin-map-define step, in the outer tree. All the inner SPI code can be common.
Those serial preambles ensure most QSPI parts will exit Quad mode, for boot.
Once that Preamble code is in there, yes, Parallax can freely choose what they offer users :
a) ROM with automatic 3P-4P connection, based on PCB wiring, which is what Post #1 provides. Simple Plug and run.
Note if a 3P connected part is found, 4P is not used and the extra pin is saved.
b) ROM with 3P only mode, with associated explanations of an external resistor, along with documents on the limits of that resistor,
and how that relates to the Clocks speeds they may be running in their own code. Those who overlook these documents will have to live with their PCB re-spins. ( This will be zero, because everyone fully reads manuals, right ?
Support questions around this will be on-going, 2017,2018,2019...
I agree about the DI-to-DO resistor being a bad idea. It could cause severe speed limitations.
If you're not supporting QPI, there is no reason to do discrete DI and DO connections. They can be one wire.
Going beyond three wires means going to six wires and issuing all the 'exit-QPI' commands and then all the 'reset' commands you can learn about. Or, after all the 'exit-QPI' commands, wait out any erase or program that is in-progress.
Of course, there's the reset input that exists on some SPI flash chips that would be much better to use.
Three-wire is the most sure-fire approach and it reduces the pin ghetto. Going beyond three pins is a huge step.
The next step after 3-Pin mode, is 4 pin, as shown in #1.
It is actually very easy to test and confirm - Just add some RESET preambles to your 3-bit code, and release to users.
User can place various parts into Quad mode, using that 3 Pin connection, and then try Reboot, and report back.
There is always Power Cycle recovery during these tests.
See above, on the Winbond data I have here, the combined Hold/Reset pin does not work, in Quad mode....
A Higher pin count package (SO16N, or BGA)** does have a separate reset pin.
To use that separate pin, (no longer shared) you have increased the pin impact to users wanting Software reboot.
It is probably tolerable to those using external watchdogs, as they connect watchdog to P2.RESET and SO16N.RESET
? The next step above 3 pin, is 4 pin ?
** just checked Digikey, who have 2,939 entries under Serial Flash.
For SO16N, they list just 1 part, (N25Q032A11ESF40G-ND) not stocked, no price given.
For wide body SO16W, they list 452 parts, price starts at 40c/3k (no stock) for 32MBit
For stocks > 100 pcs, price is 64c/3k.
(compare with sub 15c/3k start for SO8 mainstream standard package)
Chip,
If you are intent on using 3 wires, then please please please consider the 2 wire I2C 24Cxxx (32/64/128/235/512/1024) as an option, followed by 4 wire SPI FLASH & 4 wire SD.
Note that these pins need to be routed with gaps so that we can chose to do QSPI or SD 4bit if we wish to.
My diagram above shows how to test simply by looking for pullups/pulldowns.
The EEPROM can co-exist on the same pcb as FLASH without problems.
The flash can then be configured by user software into QSPI if desired using a tiny SOT23-5 or WLCSP-4 or DFN-8 etc. Just read in 4KB (ie presume 24C32 initially) which will be the same as reading the first 4KB of any of the 24Cxxx parts above.
The SOT23-5 and WLCSP-4 are NEW parts!
BTW I will have SD 1bit boot code for testing shortly - I will be posting code for P1 testing as many users have SD on their props, or easy to add to test for us. I found an SD Card that does not follow the initialisation sequence properly. I can make it work, so I am just looking for the common key to this solution.
SOT23 has appeal, but in this package the 24C32 seems more expensive than 24C64, and 24C128 is not mentioned in SOT23
Sweet spot for SOT23 looks to be just 24C64 :
FT24C64A-ULR-T Fremont Micro Devices USA IC EEPROM 64KBIT 1MHZ SOT23-5 Stk:2,064 0.23375 @ 3000
I've focused on P2-likely Flash, and a good example there is the AT25SF041 data.
(FT25H16 has the same commands, 0xff, 0xffff, but has some typos - this very cheap part, can hold 4 P2 images )
AT25SF041 data shows only DI is needed for exit via 0xff, or 0xffff, and this is because the sticky-quad-state needs M4 bit = 0 to continue in Quad.
That M4 bit arrives on DI-pin(IO0) , in the 6th Clock edge, if the Chip is in Quad Mode.
Other bits do not care, as you deselect before any read occurs.
In dual mode, the M4 bit arrives later, which is why 16 clocks 0xffff are needed
Dual mode would be rare, but it is very easy to include, so I did that.
Larger parts like Winbond W25Q32JV, use a dual-byte 0x66/0x99 keyed reset, and that is clearly shown driven into only IO0.
To do this, I think they have a special state engine, that is mode-independent, and it uses the double CS with no gaps rule, to avoid false triggers in any other normal use condition.
The trend on larger parts, seems to be to use the dual-byte 0x66/0x99 (which is why it is also in the preambles, I gave in #1)
IIRC Peter tested this on a smaller variant, with no side effects.
Updated Post#2 : I thought I had found a part for the "don't use" column, but it is just poorly written.
Deeper reading shows it does have an M4 bit exit mode. Intern wrote the data ?
They are really tiny 0.8x0.68@0.4mm pitch.
On the topic of smallest, I found a QuadSPI flash 16Mbit part in USON2x3. (smaller than SOT23-5)
That uses the 0x66,0x99 reset command, added to list in #2.
Here is a fact, as I see it: If you are going to have discrete DI and DO connections, but don't intend to use a 4-bit data path (DQ3..DQ0), you might as well tie DI and DO together and have a single data pin to the Prop2, as there is going to be no significant performance difference (only making the data signal an input before the 8th clock on commands which return data). Given that, the next step up is to wire for DQ3..DQ0 and go through the whole set of exit-QPI and reset commands, so that the flash can be booted from in DI/DO SPI mode. Am I wrong on any of this?
Sure, I've already listed a suggested-for-test preamble set in #1, which is to send in 1-bit mode, this
(it does not need DQ3..DQ0)
(0xff,0xffff,0x66,0x99,wait,0xAB,wait)
ie
CS=\_Send 0xff, 8 clk CS_/=
CS=\_Send 0xffff, 16 clk CS_/=
CS=\_Send 0x66 8 clk CS_/=\_Send 0x99 8 clk CS_/=
Wait is the 30~35us parts spec as Reset Exit.
0xAB exits power down, so gives more coverage.
Just include that, and let users test it in the wild.....even in 3P mode.
Yes, I see 3pin SPI as a valid connection choice (saves a pin!), but I also see 4 Pin SPI, as the path to Quad SPI.
The problem with 3Pin, is users cannot cleanly PCB route QuadSPI.
You still appear to think Quad-connection is needed, as a prerequisite to issue Quad-Exit. That is not correct.
You can issue Quad-Exit commands, even in 3P SPI mode, on all the parts I listed in #2
I have yet to find a recent, competitive, P2-use part that cannot exit Quad, using DIO0 commands only, but there probably is one....
The user then decides, by PCB connection, if they want QuadSPI, & because the ROM can exit QSPI, it can boot using DI/DO SPI mode.
The ROM can pullup HOLD,WP, or, that can be a user-PCB-addition. - once DI,DO are defined, the other pins are obvious (as Cluso mentions)
That's a relatively minor point, some may think enabling even a pullup on 2 other pins during Boot violates the purity of 4-pin.
If boot wants to float those pins, some outside-P2 pullups will be needed.
(Apparently, some vendors include pull-ups on HOLD,WP)
It is easy to check if DO & DI are joined in software in the boot software. So I guess you can support both 3 pin and 4 pin SPI without problems - it's just code space
Then, there are maybe two ways to use SQI.
1. Add a second chip that shares all but CS# pin. So, just needs one more pin.
2. Use RESn to gate of p-channel mosfet to cycle power on SQI chip when there is hardware reset.
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m3/lpc1800-cortex-m3/lpc-spifi-peripheral:SPIFI-NXP-MICROCONTROLLERS
Basically, they require that flash reverts to SQI mode on receipt of 0xFF command.
Also requires read command on 0x03.
There is a list of several vendors who support this.
Anyway, here is a clear example of how to solve this problem.
You forget the DualRead Modes. With 4 pin SPI connection (DI, DO not tied together) you can read data two times as fast as in 1bit SPI mode.
I've done that on FPGA Developmentboards which normally have no Quad compatible connection of the Config-Flash, but Dual mode works always. If you want to execute code from the Flash the double rate helps alot.
The Dual modes also have no sticky variants, they always terminate when /CS goes high.
Andy