Looks like all the Winbond W25Q parts work with $FF for exit sqi mode.
Winbond does have a new 512M-bit device that doesn't work, a W25M.
I think 0xff covers most older/smaller parts (Quad) (0xffff for Dual), and the 0x66,0x99 is in newer parts. Easy enough to simply include ALL 3 in the preamble.
I thought of a pin plan that grows in bit width, while keeping data MSB-top oriented, and eliminates false-positives as you search by having unique positions for DI:
pin 1-bit* 2-bit* 4-bit
---------------------------------
61 CS CS CS
60 CK CK CK
59 DI+DO DQ1/DO DQ3/HOLD#
58 z DQ0/DI DQ2/WP#
57 z z DQ1/DO
56 z z DQ0/DI
* HOLD# and WP# are tied high on the SPI flash
I thought of a pin plan that grows in bit width, while keeping data MSB-top oriented, and eliminates false-positives as you search by having unique positions for DI:
Which aligns best with Streamer ?
The moving DI makes testing mode-flip a little bit more complicated, but final end use will tend to have only one choice PCB.
What is a false positive ?
Boot will issue the Exit/reset preamble commands, and then a connected part can echo its ID, since Boot is always 1-pin only, I'm unclear how there can be a false positive.
We have to develop on the FPGA, which doesn't have pull-ups. So, we'd need to drive high.
Some series R's of lowish values 330R,470R could be used during testing.
If you drive high in FPGA, how does the binary ROM code relate to final P2 ?
Seems you really want to have minimal changes (ideally none at all) between mask-ROM and FPGA testing ?
In that case, is it smarter to enable Pullups in the ROM, but externally add them for FPGA testing ?
By testing for these possibilities, there's no need for pull-ups, because when we get to the 4-pin test, we can drive HOLD# and WP#.
I was just wary about hard-drive situations.
Cluso has mentioned SD cards that take some clocks before they release pin-drive, even with CS=H.
I guess if you tristate until drive is needed, then drive and test, then tristate as quickly as possible, any pin contention may be tolerable. (ie Drive OE is pretty much CS aligned)
Thinking about it, I really don't want to have flash boot search become a 6-pin affair. That seems to undervalue pins.
Maybe we could only check for 6-pin hookup if there is a pull-up on pin 59 (DQ3/HOLD#)? Ugh.
You know, that 3-pin hookup looks really good: No chance of crazy modes. Works with every SPI flash. As long as CS stays high, the SPI flash never drives DO nor mistakes a command on DI, allowing pin 60 (CK) and pin 59 (DI+DO) to be repurposed for SD or whatever else. Problem solved.
Thinking about it, I really don't want to have flash boot search become a 6-pin affair. That seems to undervalue pins.
I agree it uses pins, but this 6-pin is only done last.
The other modes are tested first, so there is no permanent pin impact or cost, to someone who wants to limit flash-pins.
You know, that 3-pin hookup looks really good: No chance of crazy modes. Works with every SPI flash. As long as CS stays high, the SPI flash never drives DO nor mistakes a command on DI, allowing pin 60 (CK) and pin 59 (DI+DO) to be repurposed for SD or whatever else. Problem solved.
Do you mean 3-pin with Quad-Mode preamble command exits added ?
Whichever pin subsets you settle on, it is important to be able to connect a QuadSPI part. (which also means SD, as that defaults to Quad read)
Do you mean 3-pin with Quad-Mode preamble command exits added ?
Whichever pin subsets you settle on, it is important to be able to connect a QuadSPI part. (which also means SD, as that defaults to Quad read)
No need for any quad-related commands if you know HOLD# and WP# are tied high. With DI and DO tied together, things are really compact. Only pin 61 (CS) need be exlusive to the booting SPI flash.
No need for any quad-related commands if you know HOLD# and WP# are tied high. With DI and DO tied together, things are really compact. Only pin 61 (CS) need be exlusive to the booting SPI flash.
- but this has problems.....
Leaving out quad-exit commands, means you cannot ensure (re)boot from any Flash part that may be in Quad mode, at the instant of reset.
Adding quad-exit commands, at least as NXP do, allows you to boot from SPI flash, that is Dual or Quad connected.
These exit commands are done by others, are simple, small and safe, so I cannot really comprehend, why not simply include them ?
Tying DI to DO probably works, but seems like a kludge for no apparent reason.
It implies that we don't have enough I/O pins.
But, I feel like we have plenty of pins on P2, but I guess I'm thinking about the full version...
Still, we are talking about just 1 I/O pin extra to support SQI flash. That seems like a no brainer to me...
Tying DI to DO probably works, but seems like a kludge for no apparent reason.
It implies that we don't have enough I/O pins.
But, I feel like we have plenty of pins on P2, but I guess I'm thinking about the full version...
Still, we are talking about just 1 I/O pin extra to support SQI flash. That seems like a no brainer to me...
Same here. Seems like a lot to give up just to save one pin.
No need for any quad-related commands if you know HOLD# and WP# are tied high. With DI and DO tied together, things are really compact. Only pin 61 (CS) need be exlusive to the booting SPI flash.
- but this has problems.....
Leaving out quad-exit commands, means you cannot ensure (re)boot from any Flash part that may be in Quad mode, at the instant of reset.
Adding quad-exit commands, at least as NXP do, allows you to boot from SPI flash, that is Dual or Quad connected.
These exit commands are done by others, are simple, small and safe, so I cannot really comprehend, why not simply include them ?
I'd go for this:
pin 1-bit* 2-bit* 4-bit**
-----------------------------------------
61 CS CS CS
60 CK CK CK
59 DI+DO DQ0/DI DQ0/DI
58 z DQ1/DO DQ1/DO
57 z z z (DQ2/WP#)
56 z z z (DQ3/HOLD#)
* HOLD# and WP# are tied high on the SPI flash
** HOLD# and WP# are pulled high on the SPI flash
This wouldn't disturb more than 4 pins on boot. Do you think quad could be supported by this arrangement? The data pins are reverse-ordered, which only matters for commands, as what goes in data-wise comes out the same way. This doesn't cause holes in the flash boot map, so it is a lot tidier. What do you think?
This would entail only TWO tests for pins, as 2-bit and 4-bit will look identical on boot-up.
One thing I'm not clear on is if the $FF command has to be given SQI style or can be SPI style.
If SPI style always works, then it's fine.
Otherwise, guess we need external pullups on DQ2 and DQ3.
We just need to bios then to strobe CK a few times with CS down and DI and DO high to give the $FF command to exit SQI mode...
This wouldn't disturb more than 4 pins on boot. Do you think quad could be supported by this arrangement? The data pins are reverse-ordered, which only matters for commands, as what goes in data-wise comes out the same way. This doesn't cause holes in the flash boot map, so it is a lot tidier. What do you think?
Pins are Cluso's domain, but provided the necessary Quad-Exit preambles are issued in all these modes, I'm fine with Pin Maps.
Reverse order of Commands is less than ideal, as that will trip up some users.
Reverse order of data is somewhat riskier, as SD support has a higher chance of the data being written elsewhere - that likely means users are better off reverse-fixing everything in SW, not just address.
I know that the pins 56..63 have holes when not used.
But why is that a really BIG deal. I respect that its not ideal, but its quite efficient in lots of ways. We have the same issue with P1 when P30..31 are not used, when P28..P29 (EEPROM) are used.
Now, if you really want to conserve pins, then just use an I2C EEPROM. You can go from a tiny 24C32/24AA32/24LC32/24FC32 with ~0.8x0.7mm WLSCP4 4pin BGA, SOT23-5, MSOP8, TSSOP8, SOIC8, DIP8, and DFN/QFN parts. They grow to 24x64, 24x128, 24x256, 24x512, 24x1024, 24M01 (as they grow in capacity, the smaller packages are not available, at least yet anyway). Since the smaller packages are new parts, I would expect that to continue thru the larger capacity as tie goes by. The boot code only needs to read the first 4K of EEPROM and execute it, then if that code wants more, it can do it.
I2C only uses 2 pins, is readily understood, reasonably cheap, and can co-exist with either FLASH (SPI/DSPI/QSPI) or SD (SPI or Native Quad).
In my schematic above, I2C can be detected simply by software checking for a pullup on the CLK pin (and SDA pin if you wish, although unnecessary). This does mean a pullup on CLK is required ! - I always put a pullup on CLK even tho' the P1 does not require it for your boot protocol.
So this would get us...
Serial I2C EEPROM 24xxxx series
P63 SI
P62 SO
P61 SDA (5K-10K pullup)
P60 CLK (5K-10K pullup)
P59 -spare-
P58 -spare-
P57 -spare-
P56 -spare-
And as a bonus, they are in the same order as the top 4 pins on P1
Now, let's add FLASH to the equation, either with or without EEPROM. With EEPROM, then it will control the FLASH, so no requirement to worry about pinouts at all
Now, let's add SD to the equation. If there is EEPROM, then we boot from that, and end of storey, else if there is FLASH 3/4/6 pin, we boot from that. Otherwise, no EEPROM and no FLASH, we try SD.
SD SPI 4pin SD std 6pin
P63
P62
P61 MOSI/DI (no pullup) CMD/MOSI/DI (no pullup)
P60 CLK (no pullup) CLK (no pullup)
P59 nCS (** pullup) D3/nCS (** pullup)
P58 -spare- D2
P57 -spare- D1
P56 MISO/DO (to P2) D0/MISO/DO (to P2)
** An external 10K pullup is optional. An internal pullup can be detected if the SD Card is plugged in.
While this leaves us with some spare pins in the middle, it does mean that the D0..D3 are in the corret order for Quad Mode, which IMHO is more important.
For a minimal system, use I2C EEPROM. There is virtually no delay in looking for it, because it can be detected by the external pullups.
To me, this seems so simple, yet with future expansion in mind.
I know that the pins 56..63 have holes when not used.
But why is that a really BIG deal. I respect that its not ideal, but its quite efficient in lots of ways. We have the same issue with P1 when P30..31 are not used, when P28..P29 (EEPROM) are used.
I agree, Gaps are tolerable - most other MCUs have some peripheral mappings, that result in 'sparse pinning'
If it came to a choice between NoGaps, or correct Streamer operation, correct Streamer wins easily.
While this leaves us with some spare pins in the middle, it does mean that the D0..D3 are in the corret order for Quad Mode, which IMHO is more important.
- and the correct order for Streamer, and SD, I think ?
For those designs that need absolute-smallest-boot pin counts, there is still the One-Pin Serial, right ?
One-Pin serial can optionally link to a Flash device, at the MCU, to give larger data space, but one pin.
I know that the pins 56..63 have holes when not used.
But why is that a really BIG deal. I respect that its not ideal, but its quite efficient in lots of ways. We have the same issue with P1 when P30..31 are not used, when P28..P29 (EEPROM) are used.
Now, if you really want to conserve pins, then just use an I2C EEPROM. You can go from a tiny 24C32/24AA32/24LC32/24FC32 with ~0.8x0.7mm WLSCP4 4pin BGA, SOT23-5, MSOP8, TSSOP8, SOIC8, DIP8, and DFN/QFN parts. They grow to 24x64, 24x128, 24x256, 24x512, 24x1024, 24M01 (as they grow in capacity, the smaller packages are not available, at least yet anyway). Since the smaller packages are new parts, I would expect that to continue thru the larger capacity as tie goes by. The boot code only needs to read the first 4K of EEPROM and execute it, then if that code wants more, it can do it.
I2C only uses 2 pins, is readily understood, reasonably cheap, and can co-exist with either FLASH (SPI/DSPI/QSPI) or SD (SPI or Native Quad).
In my schematic above, I2C can be detected simply by software checking for a pullup on the CLK pin (and SDA pin if you wish, although unnecessary). This does mean a pullup on CLK is required ! - I always put a pullup on CLK even tho' the P1 does not require it for your boot protocol.
So this would get us...
Serial I2C EEPROM 24xxxx series
P63 SI
P62 SO
P61 SDA (5K-10K pullup)
P60 CLK (5K-10K pullup)
P59 -spare-
P58 -spare-
P57 -spare-
P56 -spare-
And as a bonus, they are in the same order as the top 4 pins on P1
Now, let's add FLASH to the equation, either with or without EEPROM. With EEPROM, then it will control the FLASH, so no requirement to worry about pinouts at all
Now, let's add SD to the equation. If there is EEPROM, then we boot from that, and end of storey, else if there is FLASH 3/4/6 pin, we boot from that. Otherwise, no EEPROM and no FLASH, we try SD.
SD SPI 4pin SD std 6pin
P63
P62
P61 MOSI/DI (no pullup) CMD/MOSI/DI (no pullup)
P60 CLK (no pullup) CLK (no pullup)
P59 nCS (** pullup) D3/nCS (** pullup)
P58 -spare- D2
P57 -spare- D1
P56 MISO/DO (to P2) D0/MISO/DO (to P2)
** An external 10K pullup is optional. An internal pullup can be detected if the SD Card is plugged in.
While this leaves us with some spare pins in the middle, it does mean that the D0..D3 are in the corret order for Quad Mode, which IMHO is more important.
For a minimal system, use I2C EEPROM. There is virtually no delay in looking for it, because it can be detected by the external pullups.
To me, this seems so simple, yet with future expansion in mind.
Okay, Cluso. What about this:
If pull-up on pin 61 then search for SPI flash:
flash flash flash
pin 1-bit* 2-bit* 4-bit
---------------------------------
61 CSn CSn CSn
60 CLK CLK CLK
59 DI+DO DQ1/DO DQ3/HOLDn
58 z DQ0/DI DQ2/WPn
57 z z DQ1/DO
56 z z DQ0/DI
* HOLD# and WP# are tied high on the SPI flash
If pull-up on pin 59 then check for SD card:
SD SD
pin 1-bit 4-bit
---------------------------------
61 MOSI/DI CMD/MOSI/DI
60 CLK CLK
59 CSn D3/CSn
58 MISO/DO D2
57 z D1
56 z D0/MISO/DO
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
SD 4bit requires licensing due to patents. You can allow the wiring hookup, but having anything in the ROM that talks 4bit SD means Parallax will need to license it from SDA.
....
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
Great, streamer support is very important
I'll add into the mix, YASF (yet another serial Flash)...
SD 4bit requires licensing due to patents. You can allow the wiring hookup, but having anything in the ROM that talks 4bit SD means Parallax will need to license it from SDA.
Roy,
Yes, the current state requires licensing which no-one is interested in, at least currently.
Apparently there has been some clean room work done in this area.
But, if we don't permit the wiring option, we cannot ever use it. So I would like to future proof it.
Cluso99,
We are in agreement, the wiring option should be there, especially since a Parallax customer could license from SDA themselves to use 4bit SD mode with the P2 in their own software. I was just saying we should not put 4bit mode support for SD into the ROM (or in any parallax official tools/loaders/etc. Just to be safe.
jmg,
I have been ignoring 1pin. It just simplifies the mix.
I'm not sure where Chip is with that - he mentioned it was already half duplex and one-wire serial
was more a Tx pin mapping choice, than any core code changes, & I think he has added it.
Surely we can survive with 2 pins? Either serial on P62/P63 or I2C on P60/P61? Most micros can support I2C or bit bash them and the same with serial.
i2c is harder to support, as a Slave in a bottom end MCU.
One wire debug is quite popular, and the one-wire serial got a positive response, 63 Smart Pins has appeal...
Base-end MCUs are in the price region they can displace modest memories, and that price drop is relatively recent.
They open up other choices too, besides modest-Boot.
* A small MCU can act as a watchdog, for less $ than Memory+Wdog
* Even small MCU come now with ~2-3% calibrated oscillators, opening crystal-less P2 operation, to 2% precision.
* Various bridge choices open, Small MCU+SPI, allows larger boot, costing just one pin.
* etc
I know that the pins 56..63 have holes when not used.
But why is that a really BIG deal. I respect that its not ideal, but its quite efficient in lots of ways. We have the same issue with P1 when P30..31 are not used, when P28..P29 (EEPROM) are used.
Now, if you really want to conserve pins, then just use an I2C EEPROM. You can go from a tiny 24C32/24AA32/24LC32/24FC32 with ~0.8x0.7mm WLSCP4 4pin BGA, SOT23-5, MSOP8, TSSOP8, SOIC8, DIP8, and DFN/QFN parts. They grow to 24x64, 24x128, 24x256, 24x512, 24x1024, 24M01 (as they grow in capacity, the smaller packages are not available, at least yet anyway). Since the smaller packages are new parts, I would expect that to continue thru the larger capacity as tie goes by. The boot code only needs to read the first 4K of EEPROM and execute it, then if that code wants more, it can do it.
I2C only uses 2 pins, is readily understood, reasonably cheap, and can co-exist with either FLASH (SPI/DSPI/QSPI) or SD (SPI or Native Quad).
In my schematic above, I2C can be detected simply by software checking for a pullup on the CLK pin (and SDA pin if you wish, although unnecessary). This does mean a pullup on CLK is required ! - I always put a pullup on CLK even tho' the P1 does not require it for your boot protocol.
So this would get us...
Serial I2C EEPROM 24xxxx series
P63 SI
P62 SO
P61 SDA (5K-10K pullup)
P60 CLK (5K-10K pullup)
P59 -spare-
P58 -spare-
P57 -spare-
P56 -spare-
And as a bonus, they are in the same order as the top 4 pins on P1
Now, let's add FLASH to the equation, either with or without EEPROM. With EEPROM, then it will control the FLASH, so no requirement to worry about pinouts at all
Now, let's add SD to the equation. If there is EEPROM, then we boot from that, and end of storey, else if there is FLASH 3/4/6 pin, we boot from that. Otherwise, no EEPROM and no FLASH, we try SD.
SD SPI 4pin SD std 6pin
P63
P62
P61 MOSI/DI (no pullup) CMD/MOSI/DI (no pullup)
P60 CLK (no pullup) CLK (no pullup)
P59 nCS (** pullup) D3/nCS (** pullup)
P58 -spare- D2
P57 -spare- D1
P56 MISO/DO (to P2) D0/MISO/DO (to P2)
** An external 10K pullup is optional. An internal pullup can be detected if the SD Card is plugged in.
While this leaves us with some spare pins in the middle, it does mean that the D0..D3 are in the corret order for Quad Mode, which IMHO is more important.
For a minimal system, use I2C EEPROM. There is virtually no delay in looking for it, because it can be detected by the external pullups.
To me, this seems so simple, yet with future expansion in mind.
Okay, Cluso. What about this:
If pull-up on pin 61 then search for SPI flash:
flash flash flash
pin 1-bit* 2-bit* 4-bit
---------------------------------
61 CSn CSn CSn
60 CLK CLK CLK
59 DI+DO DQ1/DO DQ3/HOLDn
58 z DQ0/DI DQ2/WPn
57 z z DQ1/DO
56 z z DQ0/DI
* HOLD# and WP# are tied high on the SPI flash
If pull-up on pin 59 then check for SD card:
SD SD
pin 1-bit 4-bit
---------------------------------
61 MOSI/DI CMD/MOSI/DI
60 CLK CLK
59 CSn D3/CSn
58 MISO/DO D2
57 z D1
56 z D0/MISO/DO
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
FLASH 1bit
I don't see any problems with FLASH 1bit if they are joined.
However, if they are wired for 2bit you are sending out the software reset instruction on P59 but this is DO on the 2bit connection. If the flash has been active then this line may be driven, causing a collision!!!
Also, if they are wired as 4bit, then you are sending out on DQ3/HOLDn. What will the Flash do??? We don't know what the flash will see on DQ0, DQ1 or DQ2.
BTW I realise we have a potential situation where we can be sending out on DO(DQ1) when in fact the flash could be also outputting.
Hopefully exercising CSn= then CSn=0 this will reset any sending out of data on any of the pins, removing any possibility of conflicts. It is what I would design, but you never really know.
FLASH 2bit
With Flash 4bit, you are going to output on P58 (DQ2/WPn) and input on P59 (DQ3/HOLD#) . What will be the result of toggling DQ2/WPn ??? What will the flash 4bit see on DQ0 & DQ1 and will this matter ??? We just don't know.
BTW 24FL1xxK chips have internal high value pullups on HOLDn and WPn. Not sure on other FLASH parts.
SD
This should actually work fine as its the reading that will be affected. So the software can look for a reply on both P56 & P58 to determine if the card has a 4bit or 6bit connection.
If pull-up on pin 61 then search for SPI flash:
flash flash flash
pin 1-bit* 2-bit* 4-bit
---------------------------------
61 CSn CSn CSn
60 CLK CLK CLK
59 DI+DO DQ1/DO DQ3/HOLDn
58 z DQ0/DI DQ2/WPn
57 z z DQ1/DO
56 z z DQ0/DI
* HOLD# and WP# are tied high on the SPI flash
...
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
You need to check for 3 possible connections, while with Clusos scheme you just go with 1-bit SPI mode over separate DI / DO lines without any check.
My proposal for the SPI startsequence: $FF $AB $03 adr[2] adr[1] adr[0] data, data data ..
I know that the pins 56..63 have holes when not used.
But why is that a really BIG deal. I respect that its not ideal, but its quite efficient in lots of ways. We have the same issue with P1 when P30..31 are not used, when P28..P29 (EEPROM) are used.
Now, if you really want to conserve pins, then just use an I2C EEPROM. You can go from a tiny 24C32/24AA32/24LC32/24FC32 with ~0.8x0.7mm WLSCP4 4pin BGA, SOT23-5, MSOP8, TSSOP8, SOIC8, DIP8, and DFN/QFN parts. They grow to 24x64, 24x128, 24x256, 24x512, 24x1024, 24M01 (as they grow in capacity, the smaller packages are not available, at least yet anyway). Since the smaller packages are new parts, I would expect that to continue thru the larger capacity as tie goes by. The boot code only needs to read the first 4K of EEPROM and execute it, then if that code wants more, it can do it.
I2C only uses 2 pins, is readily understood, reasonably cheap, and can co-exist with either FLASH (SPI/DSPI/QSPI) or SD (SPI or Native Quad).
In my schematic above, I2C can be detected simply by software checking for a pullup on the CLK pin (and SDA pin if you wish, although unnecessary). This does mean a pullup on CLK is required ! - I always put a pullup on CLK even tho' the P1 does not require it for your boot protocol.
So this would get us...
Serial I2C EEPROM 24xxxx series
P63 SI
P62 SO
P61 SDA (5K-10K pullup)
P60 CLK (5K-10K pullup)
P59 -spare-
P58 -spare-
P57 -spare-
P56 -spare-
And as a bonus, they are in the same order as the top 4 pins on P1
Now, let's add FLASH to the equation, either with or without EEPROM. With EEPROM, then it will control the FLASH, so no requirement to worry about pinouts at all
Now, let's add SD to the equation. If there is EEPROM, then we boot from that, and end of storey, else if there is FLASH 3/4/6 pin, we boot from that. Otherwise, no EEPROM and no FLASH, we try SD.
SD SPI 4pin SD std 6pin
P63
P62
P61 MOSI/DI (no pullup) CMD/MOSI/DI (no pullup)
P60 CLK (no pullup) CLK (no pullup)
P59 nCS (** pullup) D3/nCS (** pullup)
P58 -spare- D2
P57 -spare- D1
P56 MISO/DO (to P2) D0/MISO/DO (to P2)
** An external 10K pullup is optional. An internal pullup can be detected if the SD Card is plugged in.
While this leaves us with some spare pins in the middle, it does mean that the D0..D3 are in the corret order for Quad Mode, which IMHO is more important.
For a minimal system, use I2C EEPROM. There is virtually no delay in looking for it, because it can be detected by the external pullups.
To me, this seems so simple, yet with future expansion in mind.
Okay, Cluso. What about this:
If pull-up on pin 61 then search for SPI flash:
flash flash flash
pin 1-bit* 2-bit* 4-bit
---------------------------------
61 CSn CSn CSn
60 CLK CLK CLK
59 DI+DO DQ1/DO DQ3/HOLDn
58 z DQ0/DI DQ2/WPn
57 z z DQ1/DO
56 z z DQ0/DI
* HOLD# and WP# are tied high on the SPI flash
If pull-up on pin 59 then check for SD card:
SD SD
pin 1-bit 4-bit
---------------------------------
61 MOSI/DI CMD/MOSI/DI
60 CLK CLK
59 CSn D3/CSn
58 MISO/DO D2
57 z D1
56 z D0/MISO/DO
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
FLASH 1bit
I don't see any problems with FLASH 1bit if they are joined.
However, if they are wired for 2bit you are sending out the software reset instruction on P59 but this is DO on the 2bit connection. If the flash has been active then this line may be driven, causing a collision!!!
Also, if they are wired as 4bit, then you are sending out on DQ3/HOLDn. What will the Flash do??? We don't know what the flash will see on DQ0, DQ1 or DQ2.
BTW I realise we have a potential situation where we can be sending out on DO(DQ1) when in fact the flash could be also outputting.
Hopefully exercising CSn= then CSn=0 this will reset any sending out of data on any of the pins, removing any possibility of conflicts. It is what I would design, but you never really know.
FLASH 2bit
With Flash 4bit, you are going to output on P58 (DQ2/WPn) and input on P59 (DQ3/HOLD#) . What will be the result of toggling DQ2/WPn ??? What will the flash 4bit see on DQ0 & DQ1 and will this matter ??? We just don't know.
BTW 24FL1xxK chips have internal high value pullups on HOLDn and WPn. Not sure on other FLASH parts.
SD
This should actually work fine as its the reading that will be affected. So the software can look for a reply on both P56 & P58 to determine if the card has a 4bit or 6bit connection.
Ah, good point about the undriven DI pins blowing in the wind. I agree, that's not good.
It seems now like it comes down to either a variable pin gap in the different flash hookups, or an MSB-LSB inversion on the data pins, which will cause pin growth to go cleanly from the top-down, but needs a REV instruction periodically to reverse the bits. Both ways are fine with the streamer.
If pull-up on pin 61 then search for SPI flash:
flash flash flash
pin 1-bit* 2-bit* 4-bit
---------------------------------
61 CSn CSn CSn
60 CLK CLK CLK
59 DI+DO DQ1/DO DQ3/HOLDn
58 z DQ0/DI DQ2/WPn
57 z z DQ1/DO
56 z z DQ0/DI
* HOLD# and WP# are tied high on the SPI flash
...
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
You need to check for 3 possible connections, while with Clusos scheme you just go with 1-bit SPI mode over separate DI / DO lines without any check.
My proposal for the SPI startsequence: $FF $AB $03 adr[2] adr[1] adr[0] data, data data ..
Andy
Okay. Good. I think we'd also need to wait out any pending erase/program cycle by waiting for BUSY to go high in STATUS.
Comments
I think 0xff covers most older/smaller parts (Quad) (0xffff for Dual), and the 0x66,0x99 is in newer parts.
Easy enough to simply include ALL 3 in the preamble.
The moving DI makes testing mode-flip a little bit more complicated, but final end use will tend to have only one choice PCB.
What is a false positive ?
Boot will issue the Exit/reset preamble commands, and then a connected part can echo its ID, since Boot is always 1-pin only, I'm unclear how there can be a false positive.
Some series R's of lowish values 330R,470R could be used during testing.
If you drive high in FPGA, how does the binary ROM code relate to final P2 ?
Seems you really want to have minimal changes (ideally none at all) between mask-ROM and FPGA testing ?
In that case, is it smarter to enable Pullups in the ROM, but externally add them for FPGA testing ?
And these are optimally arranged, MSB-wise and position-wise, for the streamer to interact with.
By testing for these possibilities, there's no need for pull-ups, because when we get to the 4-pin test, we can drive HOLD# and WP#.
Cluso may comment on how Pin maps relate to SD uses.
I was just wary about hard-drive situations.
Cluso has mentioned SD cards that take some clocks before they release pin-drive, even with CS=H.
I guess if you tristate until drive is needed, then drive and test, then tristate as quickly as possible, any pin contention may be tolerable. (ie Drive OE is pretty much CS aligned)
Maybe we could only check for 6-pin hookup if there is a pull-up on pin 59 (DQ3/HOLD#)? Ugh.
You know, that 3-pin hookup looks really good: No chance of crazy modes. Works with every SPI flash. As long as CS stays high, the SPI flash never drives DO nor mistakes a command on DI, allowing pin 60 (CK) and pin 59 (DI+DO) to be repurposed for SD or whatever else. Problem solved.
The other modes are tested first, so there is no permanent pin impact or cost, to someone who wants to limit flash-pins.
I think you simply check for 6 pin, when other tests find no flash.
Do you mean 3-pin with Quad-Mode preamble command exits added ?
Whichever pin subsets you settle on, it is important to be able to connect a QuadSPI part. (which also means SD, as that defaults to Quad read)
No need for any quad-related commands if you know HOLD# and WP# are tied high. With DI and DO tied together, things are really compact. Only pin 61 (CS) need be exlusive to the booting SPI flash.
Leaving out quad-exit commands, means you cannot ensure (re)boot from any Flash part that may be in Quad mode, at the instant of reset.
Adding quad-exit commands, at least as NXP do, allows you to boot from SPI flash, that is Dual or Quad connected.
These exit commands are done by others, are simple, small and safe, so I cannot really comprehend, why not simply include them ?
SQI is blazing fast. Some mention execution from flash...
Some seem to have DDR too.
This is not really future compatibility it's present day compatibility...
It implies that we don't have enough I/O pins.
But, I feel like we have plenty of pins on P2, but I guess I'm thinking about the full version...
Still, we are talking about just 1 I/O pin extra to support SQI flash. That seems like a no brainer to me...
I'd go for this:
This wouldn't disturb more than 4 pins on boot. Do you think quad could be supported by this arrangement? The data pins are reverse-ordered, which only matters for commands, as what goes in data-wise comes out the same way. This doesn't cause holes in the flash boot map, so it is a lot tidier. What do you think?
This would entail only TWO tests for pins, as 2-bit and 4-bit will look identical on boot-up.
One thing I'm not clear on is if the $FF command has to be given SQI style or can be SPI style.
If SPI style always works, then it's fine.
Otherwise, guess we need external pullups on DQ2 and DQ3.
We just need to bios then to strobe CK a few times with CS down and DI and DO high to give the $FF command to exit SQI mode...
Reverse order of Commands is less than ideal, as that will trip up some users.
Reverse order of data is somewhat riskier, as SD support has a higher chance of the data being written elsewhere - that likely means users are better off reverse-fixing everything in SW, not just address.
How does this work with the streamer ?
Yes, those are the 3-pin and 4-pin choices I have mentioned.
What is wrong with this format?
I know that the pins 56..63 have holes when not used.
But why is that a really BIG deal. I respect that its not ideal, but its quite efficient in lots of ways. We have the same issue with P1 when P30..31 are not used, when P28..P29 (EEPROM) are used.
Now, if you really want to conserve pins, then just use an I2C EEPROM. You can go from a tiny 24C32/24AA32/24LC32/24FC32 with ~0.8x0.7mm WLSCP4 4pin BGA, SOT23-5, MSOP8, TSSOP8, SOIC8, DIP8, and DFN/QFN parts. They grow to 24x64, 24x128, 24x256, 24x512, 24x1024, 24M01 (as they grow in capacity, the smaller packages are not available, at least yet anyway). Since the smaller packages are new parts, I would expect that to continue thru the larger capacity as tie goes by. The boot code only needs to read the first 4K of EEPROM and execute it, then if that code wants more, it can do it.
I2C only uses 2 pins, is readily understood, reasonably cheap, and can co-exist with either FLASH (SPI/DSPI/QSPI) or SD (SPI or Native Quad).
In my schematic above, I2C can be detected simply by software checking for a pullup on the CLK pin (and SDA pin if you wish, although unnecessary). This does mean a pullup on CLK is required ! - I always put a pullup on CLK even tho' the P1 does not require it for your boot protocol.
So this would get us... And as a bonus, they are in the same order as the top 4 pins on P1
Now, let's add FLASH to the equation, either with or without EEPROM. With EEPROM, then it will control the FLASH, so no requirement to worry about pinouts at all
If FLASH only, then...
Now, let's add SD to the equation. If there is EEPROM, then we boot from that, and end of storey, else if there is FLASH 3/4/6 pin, we boot from that. Otherwise, no EEPROM and no FLASH, we try SD.
While this leaves us with some spare pins in the middle, it does mean that the D0..D3 are in the corret order for Quad Mode, which IMHO is more important.
For a minimal system, use I2C EEPROM. There is virtually no delay in looking for it, because it can be detected by the external pullups.
To me, this seems so simple, yet with future expansion in mind.
If it came to a choice between NoGaps, or correct Streamer operation, correct Streamer wins easily.
- and the correct order for Streamer, and SD, I think ?
For those designs that need absolute-smallest-boot pin counts, there is still the One-Pin Serial, right ?
One-Pin serial can optionally link to a Flash device, at the MCU, to give larger data space, but one pin.
Okay, Cluso. What about this:
This is like what you posted, but with pins kept tight. It allows for gapless pin usage in cases where the customer knew that they only wanted to connect one type of memory. Do you see any problems with this?
These pin orientations are all optimal for the streamer, too. Nothing is reversed.
I have been ignoring 1pin. It just simplifies the mix.
Surely we can survive with 2 pins? Either serial on P62/P63 or I2C on P60/P61? Most micros can support I2C or bit bash them and the same with serial.
Great, streamer support is very important
I'll add into the mix, YASF (yet another serial Flash)...
http://www.adestotech.com/products/ecoxip/
This ECOXIP looks to be an interesting merge of HyperFLASH and QuadSPI (x 2)
Unlike Hyperflash, it can run (and thus also boot!
It also has Quad and Octal transfers, and DTR in those.
I don't have pinout/full data info, but have asked.
The Quad/Octal exit commands will be very topical on this, as will how they map Quad-Oct pins.
Serial Peripheral Interface (SPI) Compatible
* Supports SPI Modes 0 and 3 (1-1-1)
* Supports QPI Mode (4-4-4)
* Supports Octal Mode (8-8-8)
* Supports Dual Transfer Rate (DTR) for QPI and Octal modes
Yes, the current state requires licensing which no-one is interested in, at least currently.
Apparently there has been some clean room work done in this area.
But, if we don't permit the wiring option, we cannot ever use it. So I would like to future proof it.
We are in agreement, the wiring option should be there, especially since a Parallax customer could license from SDA themselves to use 4bit SD mode with the P2 in their own software. I was just saying we should not put 4bit mode support for SD into the ROM (or in any parallax official tools/loaders/etc. Just to be safe.
I'm not sure where Chip is with that - he mentioned it was already half duplex and one-wire serial
was more a Tx pin mapping choice, than any core code changes, & I think he has added it.
i2c is harder to support, as a Slave in a bottom end MCU.
One wire debug is quite popular, and the one-wire serial got a positive response, 63 Smart Pins has appeal...
Base-end MCUs are in the price region they can displace modest memories, and that price drop is relatively recent.
They open up other choices too, besides modest-Boot.
* A small MCU can act as a watchdog, for less $ than Memory+Wdog
* Even small MCU come now with ~2-3% calibrated oscillators, opening crystal-less P2 operation, to 2% precision.
* Various bridge choices open, Small MCU+SPI, allows larger boot, costing just one pin.
* etc
FLASH 1bit
I don't see any problems with FLASH 1bit if they are joined.
However, if they are wired for 2bit you are sending out the software reset instruction on P59 but this is DO on the 2bit connection. If the flash has been active then this line may be driven, causing a collision!!!
Also, if they are wired as 4bit, then you are sending out on DQ3/HOLDn. What will the Flash do??? We don't know what the flash will see on DQ0, DQ1 or DQ2.
BTW I realise we have a potential situation where we can be sending out on DO(DQ1) when in fact the flash could be also outputting.
Hopefully exercising CSn= then CSn=0 this will reset any sending out of data on any of the pins, removing any possibility of conflicts. It is what I would design, but you never really know.
FLASH 2bit
With Flash 4bit, you are going to output on P58 (DQ2/WPn) and input on P59 (DQ3/HOLD#) . What will be the result of toggling DQ2/WPn ??? What will the flash 4bit see on DQ0 & DQ1 and will this matter ??? We just don't know.
BTW 24FL1xxK chips have internal high value pullups on HOLDn and WPn. Not sure on other FLASH parts.
SD
This should actually work fine as its the reading that will be affected. So the software can look for a reply on both P56 & P58 to determine if the card has a 4bit or 6bit connection.
You need to check for 3 possible connections, while with Clusos scheme you just go with 1-bit SPI mode over separate DI / DO lines without any check.
My proposal for the SPI startsequence: $FF $AB $03 adr[2] adr[1] adr[0] data, data data ..
Andy
Ah, good point about the undriven DI pins blowing in the wind. I agree, that's not good.
It seems now like it comes down to either a variable pin gap in the different flash hookups, or an MSB-LSB inversion on the data pins, which will cause pin growth to go cleanly from the top-down, but needs a REV instruction periodically to reverse the bits. Both ways are fine with the streamer.
Okay. Good. I think we'd also need to wait out any pending erase/program cycle by waiting for BUSY to go high in STATUS.