Do you expect that someone presses the Reset button while the code writes to the Flash?
This is like pulling out an SD card or an USB-Stick while the PC writes to it. Something will go wrong.
In such a situation I find it acceptable that the user needs to press the Reset button again if the first reset not booted correct. Or that it waits for the next Watchdog timeout if a Wathdog has interrupted the write/erase (what never should happen in good code).
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 you connect IO0..IO3 backwards to avoid the gaps, you can only read back the data in the same mode that you have written it.
If you for example write in 1-bit SPI mode and read it back in Quad mode, every nibble of the databytes is bitreversed.
Cluso, from all the stuff I've seen, when CSn goes high, DO floats within a few nanoseconds.
Me too.
But I have found that NOT to be the case with SD Cards
So extra clocks have to be given after CSn goes high!
We will still have middle pins 57 & 58 spare if we use SD.
I'd rather have the bits sequenced correctly, and not require a REV instruction periodically. But that is just a preference.
What do you still think about allowing I2C EEPROM ? It's just a pullup check on CLK, and only requires 2 pins leaving the whole lower 4 free. And it can co-exist with FLASH or SD. And those new BGAs are tiny (just slightly smaller than 0403 imperial, so wider than an 0402 resistor/capacitor but the pads are underneath). And the SOT23-5 are easily hand soldered at 0.95mm pitch.
So, this is my preferred software sequence... (presumes my pinout, else change Pxx numbers to suit)
1. P63=SI=1 ? Y: Try booting from serial
2. Pullup on P60 CLK ? Y: Boot from I2C
3. Pullup on P61 CSn ? Y: Boot from FLASH SPI
If reply on P56 DI/DO joined - 3bit mode
If reply on P57 DI separate - 4bit mode (could be DSPI or QSPI)
4. Pullup on P59 CSn ? Note: SD Card requires >1ms delay after power up!
Y: Set P61=DI=1, P60=CLK=0, P59=CSn=1, give >74 clocks, then P59=CSn=0, give >74 clocks,
Send CMD0 & check reply=$01 ?
Y: SD Card found, continue init sequence.
5. Serial Debug Mode???
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 you connect IO0..IO3 backwards to avoid the gaps, you can only read back the data in the same mode that you have written it.
If you for example write in 1-bit SPI mode and read it back in Quad mode, every nibble of the databytes is bitreversed.
Andy
Andy,
Chip means REV the nibbles before outputting them, and again REV when reading them back in.
I don't think I2C is worth messing with, as it is SLOW. There is a lot more data likely needing to be read in for a P2 than for a P1. At higher densities, I2C is not cost competitive, at all, with SPI flash. I say forget about it. It's not practical for P2.
I'm having a hard time accepting the pin ghetto. I'd really like things to be high and tight.
Just thinking, but wouldn't it be possible to support SPI flash and SPI SD in a single 4-pin group?
if pull-up on pin 61 then try SPI flash
else if pull-up on pin 59 then try SD card
pin flash SD
pin 2-bit* 1-bit
---------------------------------
61 CSn MOSI
60 CLK CLK
59 DQ1/DO CSn
58 DQ0/DI MISO
* HOLDn and WPn are tied high on the SPI flash
That would give 2-bit SPI reading for 20MB/s. It would not pretend to be able to do 4-bit SD.
That would give 2-bit SPI reading for 20MB/s. It would not pretend to be able to do 4-bit SD.
Loosing 4-bit is a significant cost to pay for cosmetic reasons....
There is also Octal-versions of SPI that should be Streamer- compatible, either as 2 x QuadSPI, or the new Adesto ECOXIP parts.
Boot does not need to read octal, but it should be able to extend the nibble on a PCB that uses 8b SPI.
I don't think I2C is worth messing with, as it is SLOW. There is a lot more data likely needing to be read in for a P2 than for a P1. At higher densities, I2C is not cost competitive, at all, with SPI flash. I say forget about it. It's not practical for P2.
I'm having a hard time accepting the pin ghetto. I'd really like things to be high and tight.
Just thinking, but wouldn't it be possible to support SPI flash and SPI SD in a single 4-pin group?
if pull-up on pin 61 then try SPI flash
else if pull-up on pin 59 then try SD card
pin flash SD
pin 2-bit* 1-bit
---------------------------------
61 CSn MOSI
60 CLK CLK
59 DQ1/DO CSn
58 DQ0/DI MISO
* HOLDn and WPn are tied high on the SPI flash
That would give 2-bit SPI reading for 20MB/s. It would not pretend to be able to do 4-bit SD.
Certainly you could support either Flash or SD, and determine it by the pullup on the relevant CSn pin.
It's not possible to support both on the same 4 pins, but I don't see this as an issue at all.
With the alternative below, under initial boot conditions the pins would be in the same direction so no possible conflicts if the pullup got misdetected.
Of course, others will suggest you then swap 58 & 59 (below) to get QSPI, but the downside is DPI and QSPI will both need bit reversals
if pull-up on pin 61 then try SPI flash
else if pull-up on pin 58 then try SD card
P2 flash SD
pin 2-bit* 1-bit
---------- ------------- --------
61 out CSn in MOSI in
60 out CLK in CLK in
59 in /io DQ1/DO out/oi MISO out
58 out/io DQ0/DI in /oi CSn in
* HOLDn and WPn are tied high on the SPI flash
In such a situation I find it acceptable that the user needs to press the Reset button again if the first reset not booted correct. Or that it waits for the next Watchdog timeout if a Wathdog has interrupted the write/erase (what never should happen in good code).
There may be no user...
If there is a repeating Watchdog then that may be ok, but a SW reset may not be able to multi-try once control passes to ROM.
So best if the recovery is more managed, and less a dice-roll.
Easy enough to field test a Busy poll, and see if it has any issues.
The Winbond & Macronix data I have, does not mention your 'QPI', but they do give wave forms showing a 1-bit 0x66,0x99 reset, so I am following the vendor data here.
Given the strict adjacent command caveats they apply, to me that makes this a separate reset state engine. Makes sense.
Keeps it away from any Dual-Quad modes.
datasheet, page 79 http://www.winbond.com/resource-files/w25q128fv rev.m 05132016 kms.pdf
clearly indicates 66/99 sequence for SPI and QPI. For SPI is intended SPI,SDI, SQI. This do not depend on QE setting. When you enter QPI mode with command 38h you have switched command receiving fron 1b to 4b thus the reset (66/99h) must be given in 4b format.
BTW cypress reset is F0h only, in SPI (1b) because they do not support QPI
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)
I've understood from Cluso that the SD remains with the active drive even without CS and that he needs to issue some clocks pulses in this condition to make the card release the output.
SD and Flash could share the CLK signal. You can start by issuing a series of CLK pulses with all the CS signals not asserted to eventually stop the SD driving the output.
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...
for SQI (commands 1bit, data 4bits) FF will work. For QPI (commands 4bit, data 4bit) you need to drive/pull-up high DQ1,DQ2,DQ3 while transmitting ones on DQ0(DI). You probably need to drive hidh CS after 2 bits on DI, which with the 3 pull-ups forms the 2 nibbless for "FF". So I think is better issuing 2 clocks with DI high, then pulse high CS and then issue 8 clocks with DI high
SD and Flash could share the CLK signal. You can start by issuing a series of CLK pulses with all the CS signals not asserted to eventually stop the SD driving the output.
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.
Chip, your sentence says that as opposite there will be users wanting multiple type of memory. How will flash and SD coexist id when driving FLASH.DI you at the same time gives SD.CS and opposite.
Should't SD and FLASH share only the clock and data signals but have separate CS? This will require a pin more, but perhaps serial.RX can be shared with common.CLK to save it. Giving CLK pulses to the pcb devices while serially receiving shouldn't hurt anything because the devices are all deselected (CS=high). And between the P2.RX&CLK and the FTDI.TX can be a series resistor to avoid collisions when P2 outputs CLK
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 you connect IO0..IO3 backwards to avoid the gaps, you can only read back the data in the same mode that you have written it.
If you for example write in 1-bit SPI mode and read it back in Quad mode, every nibble of the databytes is bitreversed.
Andy
And in case of SD where the media is removable and could be read by other systems? Or if someone makes a removable flash daughterboard?
dMajo, I didn't think about the SPIflash/SD conflict in my proposal. Sorry about that.
I think it would be better not to repurpose the serial pins, though. We don't know about half-duplex until we get the commands on RX. So, it has to be assumed for the flash/SD that TX (pin 62) is not available.
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 you connect IO0..IO3 backwards to avoid the gaps, you can only read back the data in the same mode that you have written it.
If you for example write in 1-bit SPI mode and read it back in Quad mode, every nibble of the databytes is bitreversed.
Andy
And in case of SD where the media is removable and could be read by other systems? Or if someone makes a removable flash daughterboard?
For those reasons, it would be important to keep the data properly justified.
I also think serial should remain on P62/63 as 2 pins.
As for FLASH vs SD, as far as I am concerned, it is fine to just support one or the other. For users who want/require both, then they should boot from FLASH. They can use any combination of pins, shared or not, to support their SD.
My reasoning for supporting SD was to remove the requirement of having to use FLASH to boot to SD. This is what I have to do in P1 because there is no other way.
FWIW, my Prop OS detects all my various boards, and the locations of the SD card and optional SRAM. It's not difficult. I share pins in different ways. This part should be left to the user to decide... Either have and boot from FLASH, or no FLASH and boot from SD, else serial of course.
Postedit: My Prop OS is readable on PC's via USB/SD adapter or SD slot. I can also transfer files to/from the PC over the serial/usb link. I can even program the EEPROM from a file, or make a file from EEPROM, all on the P1. With my RamBlade hardware it even runs CPM2.2 with heater's ZiCog, and can transfer files back and forth between FAT and CPM. I even have Michael Park's spin/pasm P1 compiler running although it's not been robustly tested.
I am saying this because I expect similar, but better, on P2. I just don't need, nor want, FLASH as I can boot straight to SD which can be setup from my PC (Windows, but I know *nix can also do it).
dMajo, I didn't think about the SPIflash/SD conflict in my proposal. Sorry about that.
I think it would be better not to repurpose the serial pins, though. We don't know about half-duplex until we get the commands on RX. So, it has to be assumed for the flash/SD that TX (pin 62) is not available.
Chip, I edited immediately after posting, perhaps you don't read the lattest.
I meant RX of propeller being shared with clock. I thought that sharing TX is not good because you can use these 2 pins for serial comm in the user program independently of that that the prop has booted from flash/sd.
If you share TX, in a setup where serial port is present with the storage devices, that means you will always be serially transmitting something while driving clock. Sharing RX will keep the clock not entering the serial channel. At worse you will lose some serial packets in incoming directions. The host can resend these packets after some delay, or the user, with the user code can drive additional free IOs for serial hw handshake purpose. A serial resistor between usb/serial converter (TX) and prop RX pin can safeguard from output conflicts between the two pins.
Please leave the P63/62 alone for serial SI/SO. These same pins can be used for our USB direct connect. My latest P1 boards have the required resistors, etc in place for this. They can also be used for 1pin PS2 Keyboard and 1pin TV (mono generated by the VGA section for composite video) - I do this on the P1.
So P63/62 have their own uses, besides loading code. And they are the constant part of most P1 designs, together with the P28/29 EEPROM pins, which can also be shared BTW.
On P1, I share SDA & CLK with OEn & WEn on SRAM, and CEn gets shared between SRAM and SD. I use 19 pins for address pins to the SRAM, and 8 pins for the Data on SRAM (which also get shared with SD).
It's probably better to not have SD in ROM.
SQI flash support is already taking up a lot of pins.
Or, have it so SD is only supported in the case of SPI only flash with shared DI/DO.
The smallest member of P2 family looks to only have 16 I/O pins.
Do we really want to dedicate a bunch of those to different boot options?
It's probably better to not have SD in ROM.
SQI flash support is already taking up a lot of pins.
Or, have it so SD is only supported in the case of SPI only flash with shared DI/DO.
The smallest member of P2 family looks to only have 16 I/O pins.
Do we really want to dedicate a bunch of those to different boot options?
Maybe the smaller members of the P2 family could be limited to 3 and 4 pin boot? I guess even 4 is a quarter of the pins on the smallest version.
It's probably better to not have SD in ROM.
SQI flash support is already taking up a lot of pins.
Or, have it so SD is only supported in the case of SPI only flash with shared DI/DO.
The smallest member of P2 family looks to only have 16 I/O pins.
Do we really want to dedicate a bunch of those to different boot options?
Maybe the smaller members of the P2 family could be limited to 3 and 4 pin boot? I guess even 4 is a quarter of the pins on the smallest version.
Exactly. That is my concern. What we need is reliable boot in just a few pins. We can do it in three.
It's probably better to not have SD in ROM.
SQI flash support is already taking up a lot of pins.
Or, have it so SD is only supported in the case of SPI only flash with shared DI/DO.
The smallest member of P2 family looks to only have 16 I/O pins.
Do we really want to dedicate a bunch of those to different boot options?
Maybe the smaller members of the P2 family could be limited to 3 and 4 pin boot? I guess even 4 is a quarter of the pins on the smallest version.
Exactly. That is my concern. What we need is reliable boot in just a few pins. We can do it in three.
So limit the tiny variants of P2 to 3 pin boot and allow the other options only on the larger variants?
It's probably better to not have SD in ROM.
SQI flash support is already taking up a lot of pins.
Or, have it so SD is only supported in the case of SPI only flash with shared DI/DO.
The smallest member of P2 family looks to only have 16 I/O pins.
Do we really want to dedicate a bunch of those to different boot options?
Maybe the smaller members of the P2 family could be limited to 3 and 4 pin boot? I guess even 4 is a quarter of the pins on the smallest version.
Exactly. That is my concern. What we need is reliable boot in just a few pins. We can do it in three.
Or 4 with SD as an either/or with FLASH. ie either FLASH or SD, but not both for booting.
That is why I also suggested 2 pins with the tiny EEPROM. Just enough to allow the P2 to boot from something else, like WiFi, etc. The pins can be shared with either FLASH or SD if required. At least EEPROM is a known entity, only 2 pins, cheap at the bottom end 24LC64 0.239/5K for WLSCP4 (BGA), 0.253/2K5 for SOT23-5, and 511-M24128SFCU6T/T 128Kb/16KB 0.307/2K5 for WLSCP4, all at Mouser.
863-CAT24C512YI-GT3 TSSOP8 0.398/3K.
It is only the ROM space required to boot from EEPROM, by testing for a pullup on CLK so it's quick. The rest is a known quantity.
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. I'm sorry I've been around and around with this, but I don't think we have the right solution, yet.
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. .
That sequence makes sense.
If someone does want to pin-overlap & use both in a design, they have Flash, so can map their own SD overlay.
If we require that the other 3 QPI data pins need external pullups, then that could be a test as to whether it is connected or not.
That way, you could avoid doing anything on those pins if any of them were pulled down...
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. I'm sorry I've been around and around with this, but I don't think we have the right solution, yet.
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. .
That sequence makes sense.
If someone does want to pin-overlap & use both in a design, they have Flash, so can map their own SD overlay.
+1
But we are going to need to test the booting of both FLASH and SD before you put it out in files.
Chip,
What is the current state of the Boot ROM in release 11b ?
ie What does it do? Do we require a FLASH device present?
I want to be able to load P2 code (without reloading/repowering the FPGA board) to test the SD Card (on other pins initially) to confirm everything works fine at least for me before I release it into the wild for testing.
I would presume the same will be required for FLASH testing. I have S25FL116X here to test when Boot FLASH code is ready for download & test.
Maybe we don't need something external to boot from (which is why I suggested EEPROM on the other thread even if it does not make it into the final Boot ROM, even tho' I think it would make a great reliable option)
Comments
This is like pulling out an SD card or an USB-Stick while the PC writes to it. Something will go wrong.
In such a situation I find it acceptable that the user needs to press the Reset button again if the first reset not booted correct. Or that it waits for the next Watchdog timeout if a Wathdog has interrupted the write/erase (what never should happen in good code).
Andy
If you connect IO0..IO3 backwards to avoid the gaps, you can only read back the data in the same mode that you have written it.
If you for example write in 1-bit SPI mode and read it back in Quad mode, every nibble of the databytes is bitreversed.
Andy
But I have found that NOT to be the case with SD Cards
So extra clocks have to be given after CSn goes high!
We will still have middle pins 57 & 58 spare if we use SD.
I'd rather have the bits sequenced correctly, and not require a REV instruction periodically. But that is just a preference.
What do you still think about allowing I2C EEPROM ? It's just a pullup check on CLK, and only requires 2 pins leaving the whole lower 4 free. And it can co-exist with FLASH or SD. And those new BGAs are tiny (just slightly smaller than 0403 imperial, so wider than an 0402 resistor/capacitor but the pads are underneath). And the SOT23-5 are easily hand soldered at 0.95mm pitch.
So, this is my preferred software sequence... (presumes my pinout, else change Pxx numbers to suit)
1. P63=SI=1 ? Y: Try booting from serial 2. Pullup on P60 CLK ? Y: Boot from I2C 3. Pullup on P61 CSn ? Y: Boot from FLASH SPI If reply on P56 DI/DO joined - 3bit mode If reply on P57 DI separate - 4bit mode (could be DSPI or QSPI) 4. Pullup on P59 CSn ? Note: SD Card requires >1ms delay after power up! Y: Set P61=DI=1, P60=CLK=0, P59=CSn=1, give >74 clocks, then P59=CSn=0, give >74 clocks, Send CMD0 & check reply=$01 ? Y: SD Card found, continue init sequence. 5. Serial Debug Mode???Chip means REV the nibbles before outputting them, and again REV when reading them back in.
I'm having a hard time accepting the pin ghetto. I'd really like things to be high and tight.
Just thinking, but wouldn't it be possible to support SPI flash and SPI SD in a single 4-pin group?
That would give 2-bit SPI reading for 20MB/s. It would not pretend to be able to do 4-bit SD.
Aesthetics are nice, but not at the cost of technical performance.
Loosing 4-bit is a significant cost to pay for cosmetic reasons....
There is also Octal-versions of SPI that should be Streamer- compatible, either as 2 x QuadSPI, or the new Adesto ECOXIP parts.
Boot does not need to read octal, but it should be able to extend the nibble on a PCB that uses 8b SPI.
Certainly you could support either Flash or SD, and determine it by the pullup on the relevant CSn pin.
It's not possible to support both on the same 4 pins, but I don't see this as an issue at all.
With the alternative below, under initial boot conditions the pins would be in the same direction so no possible conflicts if the pullup got misdetected.
Of course, others will suggest you then swap 58 & 59 (below) to get QSPI, but the downside is DPI and QSPI will both need bit reversals
if pull-up on pin 61 then try SPI flash else if pull-up on pin 58 then try SD card P2 flash SD pin 2-bit* 1-bit ---------- ------------- -------- 61 out CSn in MOSI in 60 out CLK in CLK in 59 in /io DQ1/DO out/oi MISO out 58 out/io DQ0/DI in /oi CSn in * HOLDn and WPn are tied high on the SPI flashRayNo, but in the field glitches can arrive any time....
There may be no user...
If there is a repeating Watchdog then that may be ok, but a SW reset may not be able to multi-try once control passes to ROM.
So best if the recovery is more managed, and less a dice-roll.
Easy enough to field test a Busy poll, and see if it has any issues.
datasheet, page 79
http://www.winbond.com/resource-files/w25q128fv rev.m 05132016 kms.pdf
clearly indicates 66/99 sequence for SPI and QPI. For SPI is intended SPI,SDI, SQI. This do not depend on QE setting. When you enter QPI mode with command 38h you have switched command receiving fron 1b to 4b thus the reset (66/99h) must be given in 4b format.
BTW cypress reset is F0h only, in SPI (1b) because they do not support QPI
SD and Flash could share the CLK signal. You can start by issuing a series of CLK pulses with all the CS signals not asserted to eventually stop the SD driving the output.
for SQI (commands 1bit, data 4bits) FF will work. For QPI (commands 4bit, data 4bit) you need to drive/pull-up high DQ1,DQ2,DQ3 while transmitting ones on DQ0(DI). You probably need to drive hidh CS after 2 bits on DI, which with the 3 pull-ups forms the 2 nibbless for "FF". So I think is better issuing 2 clocks with DI high, then pulse high CS and then issue 8 clocks with DI high
Yes, that is worth testing.
(plus the 0xffff case for exit Dual mode for full coverage )
Should't SD and FLASH share only the clock and data signals but have separate CS? This will require a pin more, but perhaps serial.RX can be shared with common.CLK to save it. Giving CLK pulses to the pcb devices while serially receiving shouldn't hurt anything because the devices are all deselected (CS=high). And between the P2.RX&CLK and the FTDI.TX can be a series resistor to avoid collisions when P2 outputs CLK
I think it would be better not to repurpose the serial pins, though. We don't know about half-duplex until we get the commands on RX. So, it has to be assumed for the flash/SD that TX (pin 62) is not available.
For those reasons, it would be important to keep the data properly justified.
As for FLASH vs SD, as far as I am concerned, it is fine to just support one or the other. For users who want/require both, then they should boot from FLASH. They can use any combination of pins, shared or not, to support their SD.
My reasoning for supporting SD was to remove the requirement of having to use FLASH to boot to SD. This is what I have to do in P1 because there is no other way.
FWIW, my Prop OS detects all my various boards, and the locations of the SD card and optional SRAM. It's not difficult. I share pins in different ways. This part should be left to the user to decide... Either have and boot from FLASH, or no FLASH and boot from SD, else serial of course.
Postedit: My Prop OS is readable on PC's via USB/SD adapter or SD slot. I can also transfer files to/from the PC over the serial/usb link. I can even program the EEPROM from a file, or make a file from EEPROM, all on the P1. With my RamBlade hardware it even runs CPM2.2 with heater's ZiCog, and can transfer files back and forth between FAT and CPM. I even have Michael Park's spin/pasm P1 compiler running although it's not been robustly tested.
I am saying this because I expect similar, but better, on P2. I just don't need, nor want, FLASH as I can boot straight to SD which can be setup from my PC (Windows, but I know *nix can also do it).
Chip, I edited immediately after posting, perhaps you don't read the lattest.
I meant RX of propeller being shared with clock. I thought that sharing TX is not good because you can use these 2 pins for serial comm in the user program independently of that that the prop has booted from flash/sd.
If you share TX, in a setup where serial port is present with the storage devices, that means you will always be serially transmitting something while driving clock. Sharing RX will keep the clock not entering the serial channel. At worse you will lose some serial packets in incoming directions. The host can resend these packets after some delay, or the user, with the user code can drive additional free IOs for serial hw handshake purpose. A serial resistor between usb/serial converter (TX) and prop RX pin can safeguard from output conflicts between the two pins.
So P63/62 have their own uses, besides loading code. And they are the constant part of most P1 designs, together with the P28/29 EEPROM pins, which can also be shared BTW.
On P1, I share SDA & CLK with OEn & WEn on SRAM, and CEn gets shared between SRAM and SD. I use 19 pins for address pins to the SRAM, and 8 pins for the Data on SRAM (which also get shared with SD).
SQI flash support is already taking up a lot of pins.
Or, have it so SD is only supported in the case of SPI only flash with shared DI/DO.
The smallest member of P2 family looks to only have 16 I/O pins.
Do we really want to dedicate a bunch of those to different boot options?
Exactly. That is my concern. What we need is reliable boot in just a few pins. We can do it in three.
Or 4 with SD as an either/or with FLASH. ie either FLASH or SD, but not both for booting.
That is why I also suggested 2 pins with the tiny EEPROM. Just enough to allow the P2 to boot from something else, like WiFi, etc. The pins can be shared with either FLASH or SD if required. At least EEPROM is a known entity, only 2 pins, cheap at the bottom end 24LC64 0.239/5K for WLSCP4 (BGA), 0.253/2K5 for SOT23-5, and 511-M24128SFCU6T/T 128Kb/16KB 0.307/2K5 for WLSCP4, all at Mouser.
863-CAT24C512YI-GT3 TSSOP8 0.398/3K.
It is only the ROM space required to boot from EEPROM, by testing for a pullup on CLK so it's quick. The rest is a known quantity.
If someone does want to pin-overlap & use both in a design, they have Flash, so can map their own SD overlay.
That way, you could avoid doing anything on those pins if any of them were pulled down...
+1
But we are going to need to test the booting of both FLASH and SD before you put it out in files.
Chip,
What is the current state of the Boot ROM in release 11b ?
ie What does it do? Do we require a FLASH device present?
I want to be able to load P2 code (without reloading/repowering the FPGA board) to test the SD Card (on other pins initially) to confirm everything works fine at least for me before I release it into the wild for testing.
I would presume the same will be required for FLASH testing. I have S25FL116X here to test when Boot FLASH code is ready for download & test.
Maybe we don't need something external to boot from (which is why I suggested EEPROM on the other thread even if it does not make it into the final Boot ROM, even tho' I think it would make a great reliable option)