I don't think there's a need for that 3.3k resistor, as the SPI flash only drives SO when CS is low and it's been configured to output data. The Prop2 controls that, so there's no possibility of a conflict.
How realistic is it and what advantage is there in running the SD in 4-data-wire mode? Are you using 4-wire mode in your projects, or are you in SPI mode using just DI/DO? And do you know if DI and DO could be tied together for the same reasons that make it work with SPI flash chips?
Yes, I do think the 3K3 resistor is required because it's not possible to be sure how much lag there is between the prop tristating the pin and the FLASH enabling the DO. This could cause a glitch in power and result in premature death of the part(s). I just think it is dangerous otherwise.
I answered the other questions on the FPGA thread.
How do you test for that RXD pulldown, given RXD is likely connected to a driving UART, or MCU - which can be either CMOS out, or Pullup designs ?
The rxd pulldown is tested to determine if an external uart txd is connected.
AH, you mean the pin is actually tested for Hi, not 'tested for pulldown' ?
ie a LOW on the pin, is assumed to be no-uart connected (but Low might be due to a sending/polling char).
A problem with that, is systems could have connected UART and want fast SPI boot.
Any sense design should allow that combination.
So how do you cater for a software bug in the Flash/SD/eeprom then?
So how do you cater for a software bug in the Flash/SD/eeprom then?
Not sure what you mean ?
Chip's current flow shows SPI boot, tests checksum, and if that fails, it then does a Serial-wait.
So that covers flash faults.
If you mean user over-ride of a fast-spi-boot request, that executes fine and runs, but is wrong revision, then that needs the fast-SPI jumper physically removed.
(in my example, that is a resistor RXD-SPI_CS - Presence sensed by RXD toggled and CPI_CS is checked for changes)
If you do not like jumpers/physical removal, but do have a standard USB-UART type connection, you can always use the second handshake line to control a switch.
If I was doing a P2/Eval design, I'd include something like MUN5213DW1T1G, (Dual NPN pre-bias) for RST control and 'user control'.
of one feature, using both handshake lines.
I can see development use in remote manage/select of Serial Loader / standard SPI loader esp for classrooms.
Mostly you use Serial, and then can change to Flash load and flash boot tests, involving RST then finally power cycling.
Hopefully, the full power cycling is the same outcomes as the host-drives-RST tests
...Yes, I do think the 3K3 resistor is required because it's not possible to be sure how much lag there is between the prop tristating the pin and the FLASH enabling the DO. This could cause a glitch in power and result in premature death of the part(s)...
You know, based on the CLK signal that you drive, when the DO output enable is going to switch. Your code ensures that there's no electrical conflict. I certainly would have noticed on the scope if there were any mid-levels due to contention. I just wrote code according to how the data sheet said things change and it works fine. For example, if I know the DO is going to output after the next clock transition, I will float my data pin to accommodate that, before I cause the clock transition. And these clock transitions are separate from the transitions which clock data into the DI pin.
These flash chips are designed to accommodate their DI and DO being tied together.
How are you currently finding the data for booting in your SD card driver?
Are you just reading the first data out of the card, or are you looking for maybe a certain-named file? I remember there was much discussion over the merits of different techniques. Anyway, I am just wondering how you propose to do it.
...Yes, I do think the 3K3 resistor is required because it's not possible to be sure how much lag there is between the prop tristating the pin and the FLASH enabling the DO. This could cause a glitch in power and result in premature death of the part(s)...
You know, based on the CLK signal that you drive, when the DO output enable is going to switch. Your code ensures that there's no electrical conflict. I certainly would have noticed on the scope if there were any mid-levels due to contention. I just wrote code according to how the data sheet said things change and it works fine. For example, if I know the DO is going to output after the next clock transition, I will float my data pin to accommodate that, before I cause the clock transition. And these clock transitions are separate from the transitions which clock data into the DI pin.
These flash chips are designed to accommodate their DI and DO being tied together.
I have been out, and thinking about this further.
Provided you tristate the output before the clock change, and enable after the clock change, the flash will not output until the clock change (perhaps plus a minor delay), and tristate at the clock change (perhaps plus a minor delay). So there should be no collisions and that would avoid the need for a protection series 3K3 resistor. You will need to be careful to use the correct clock edge depending on whether you use mode 0 or mode 3 SPI. Mode 0 seems to be preferred (CLK=0 at rest).
The AT25SF041 gives the setup time >2ns and hold time >2ns for SI (input to flash) wrt rising CLK,
and output hold time >0ns wrt falling CLK, and next output data valid <6-8ns wrt falling CLK. I presume the output will tristate (not shown) before the next output data would be valid ie <6-8ns.
SD SPI does not work that way though, at least from what the documentation says.
How are you currently finding the data for booting in your SD card driver?
Are you just reading the first data out of the card, or are you looking for maybe a certain-named file? I remember there was much discussion over the merits of different techniques. Anyway, I am just wondering how you propose to do it.
I use FAT16/32 to search for specifically named files (two such files can boot the P1).
However, I propose (as had been discussed long ago) to not cater for specific formatting such as FAT16/32, but rather look for a defined sequence in the MBR, followed by a card sector number, and use this sector number, potentially followed by a length, to directly load up some SD boot code into the P2 and execute it.
This also caters for future formats such as exFAT (requires MS license) or an open standard to avoid the license, or a separate partition, or whatever.
So, this can be as simple as a stub to negotiate the card format followed by searching for a file, or whatever. This way, the SD Boot ROM is minimal (currently about 1KB cog with debugging)
How long does it take to locate the start of data, from best case to worst case?
Can the CS, CLK, DI and DO pins be common between SPI flash and SPI SD? Or, is there a need to, say, make their CS pins different? Only one or the other would be present, mind you. In other words, could you figure out which one you were talking to over the same pins?
I normally share the SD lines with Flash except for CS but in some systems it's one or the other on the same 4 lines. The slowest part of using SD is really the card initialization which has to start at a few hundred kHz before ramping up and going through the rest of the initialization sequence. Some brands take longer than others but I can check my figures. As for finding the startup file that is very easy, especially if it's in the first sector of the root directory, it should only be a matter of a few milliseconds.
How long does it take to locate the start of data, from best case to worst case?
Can the CS, CLK, DI and DO pins be common between SPI flash and SPI SD? Or, is there a need to, say, make their CS pins different? Only one or the other would be present, mind you. In other words, could you figure out which one you were talking to over the same pins?
I did a drawing a few posts back that shows the pin connections required. nCS is on a different pin to FLASH.
It's hard to say how long the boot takes as cards are different for initialisation. You need to poll them and I presume they may get slower as they get used due to wear levelling. I have a test program so if I get a chance I will try my different cards over the w/e and time them.
Basically, you wait 1ms, send 74+ clocks at 50KHz (could be faster I think), then send some command sequences faster ~2.5MHz ($FF, cmd_byte, par_long, crc_byte, then clock in byte(s) reply) to setup and identify the card type, etc. The command sequences depend upon the replies. There is also a wait mechanism where the card replies $FF to delay the micro.
Why the obsession with saving one pin by combining DI and DO for SPI booting? Why not just use the standard SPI wiring?
If we could use a common CS between SD card and SPI flash, we might as well use separate data pins. However, SD card needs its own CS, which we must employ a separate pin for. So, this allows us to boot from either SPI flash or SD card with a mere 4-pin footprint. That's three pins for SPI flash or four pins for SD card, each nicely tucked upwards.
Why the obsession with saving one pin by combining DI and DO for SPI booting? Why not just use the standard SPI wiring?
If we could use a common CS between SD card and SPI flash, we might as well use separate data pins. However, SD card needs its own CS, which we must employ a separate pin for. So, this allows us to boot from either SPI flash or SD card with a mere 4-pin footprint. That's three pins for SPI flash or four pins for SD card, each nicely tucked upwards.
Didn't we already discuss SD boot at length and decide that it wasn't worth putting it in the ROM?
Why the obsession with saving one pin by combining DI and DO for SPI booting? Why not just use the standard SPI wiring?
If we could use a common CS between SD card and SPI flash, we might as well use separate data pins. However, SD card needs its own CS, which we must employ a separate pin for. So, this allows us to boot from either SPI flash or SD card with a mere 4-pin footprint. That's three pins for SPI flash or four pins for SD card, each nicely tucked upwards.
Didn't we already discuss SD boot at length and decide that it wasn't worth putting it in the ROM?
Yes, but Cluso99 and Peter Jakacki have developed a reliable approach that they've been using for a while in their own creations. Cluso99 has offered to do a load implementation for the ROM.
If we could use a common CS between SD card and SPI flash, we might as well use separate data pins. However, SD card needs its own CS, which we must employ a separate pin for. So, this allows us to boot from either SPI flash or SD card with a mere 4-pin footprint. That's three pins for SPI flash or four pins for SD card, each nicely tucked upwards.
Is that pin map also compatible with Streamer in 4-bit and 8-bit modes, for users of QuadSPI and OctalSPI devices ?
OctalSPI parts avoid the HOLDn,WPn, but do not care if their Dn has light-pull-hi - I'm less sure how the 8-bit streamer mode impacts possible pin-maps ?
That's why Octal users need to be included in the pin-choices.
I normally share the SD lines with Flash except for CS but in some systems it's one or the other on the same 4 lines. The slowest part of using SD is really the card initialization which has to start at a few hundred kHz before ramping up and going through the rest of the initialization sequence. Some brands take longer than others but I can check my figures. As for finding the startup file that is very easy, especially if it's in the first sector of the root directory, it should only be a matter of a few milliseconds.
So, could we make a static 4-pin pinout that works with both SPI flash and SD card, assuming one or the other is present (or neither is present)?
If we had this:
P61 = CS (pull-up indicates presence of either SPI flash or SD card)
P60 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P59 = DI (could be used as SPI flash DQ0)
P58 = DO (could be used as SPI flash DQ1)
P57 = (could be used as SPI flash DQ2)
P56 = (could be used as SPI flash DQ3)
In the ROM booter now, I do some initial command/response sleuthing to determine if a SPI chip is present. That takes umpteen microseconds. If it seems present, it takes ~4ms to read in $100 longs and determine if they're legit. If either of those checks fail, could we then treat those 4 pins as if an SD card is connected, and see what we get? This would all be predicated on seeing a pull-up on P61, indicating some kind of memory is present. This keeps our initial "is-memory-present" pin checking down to ONE pin. Also, by keeping DI and DO separate for both SPI flash and SD card, we could hold DI high while reading SPI flash (CS is low during reading) to avoid some command being interpreted by the SD card. Also, keeping those pins separate allows for quad SPI flash usage.
What do you guys think about this? Is it possible to have a pin-out scheme for booting that supports both SPI flash and SD card, with static CS, CLK, DI, and DO pins?
P61 = CS (pull-up indicates presence of either SPI flash or SD card)
P60 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P59 = DI (could be used as SPI flash DQ0)
P58 = DO (could be used as SPI flash DQ1)
P57 = (could be used as SPI flash DQ2)
P56 = (could be used as SPI flash DQ3)
..... Also, by keeping DI and DO separate for both SPI flash and SD card, we could hold DI high while reading SPI flash (CS is low during reading) to avoid some command being interpreted by the SD card. Also, keeping those pins separate allows for quad SPI flash usage.
That sounds ok.
How does that pin map co-operate with the Streamer, in 4-bit and 8-bit modes ?
Can 4 more pins below P56, connect DQ4..DQ7 on a OctalFlash device, and work with the streamer ?
Why does this have to be so hard? Just boot from the simplest, smallest, cheapest thing that is likely to be around for years.
Anything else can be boot strapped from that if anyone needs it.
It is not hard, but needs a little care so Parallax can avoid telling users they need TWO DEVICES connected.
ie the Pin map needs to be physically & SW compatible, with common superset devices.
QuadSPI is now pretty much default, ('simplest, smallest, cheapest') starting at ~20c, and OctalSPI is emerging, and is a simple superset of 1-SPI/extended Quad.
This BOOTS in 1-spi mode, but users will expect to operate the same device, in Quad. (or octal)
Here is a more detailed schematic. The user will just choose one option to fit.
I have done this before Chip has suggested reversing the D0..D3 pins, so I haven't thought that through yet, athough it does require an additional REV instruction every CLK (nibble) when using Quad mode.
There are also a few things than need explaining as some of you continue to get it wrong...
Most of the SPI FLASH have internal pullups on the HOLD and WP pins (see AT25SF041 datasheet). They do however also recommend that these pins be tied to Vcc.
* If the user only wants to use SPI FLASH in 3 or 4 pin mode, then you can tie the flash chips hold and wp to Vcc.
* If the user wants to use Quad SPI, then he either uses a FLASH with internal pullups on hold and wp, or he adds external pullup resistors.
If FLASH is used, then there will be a pullup on nCS = P61. This is easily detected by the boot software.
For those that want a really minimal boot pin system, then use I2C EEPROM. It only uses 2 pins and can easily be detected by pullups on SDA=P61 & SCL=CLK=P60. I don't care for EEPROM booting, but it's cheap, simple, known, and only uses 2 pins and 2 pullups.
Personally, I don't see the advantage of FLASH joining SI/SO to save a pin, but Chip wants it. I still do not like joining without a series resistor because the timing is quite strict to avoid bus conflict. It's hard to dig out the precise timing for tristate from the datasheets, if it's there at all.
Like many of you, I want to see the QUAD-SPI FLASH able to be used, so I am hoping for an ordered D0..D3 pinout. This does mean skipping 2pins (on my arrangement D0..D3 on P56..P59). IMHO we are not short of pins, and QSPI appears important enough to skip these pins. If a later P2 version is done with less pins, then P58 & P59 could be omitted from the IC unless by then the usage of QSPI will be known.
For SD, it needs/has a pullup on nCS=P59 which also doubles as D3 for SD 4-bit mode. There is an internal pullup on this pin, so Peter (Tachyon) does not fit an external pullup. I already had a pullup on my pcb when Peter told me this. It also serves to show an SD card is inserted. I really want to try and get the SD 4-bit mode to work, so I need the 6-pin option. For those that think I am wanting to put this in the ROM, I have clearly said this is NOT my intention. Nor do I intend to support FAT16/32, Partitions, or any other formatting on the SD Card. The ROM will just initialise the SD card in SPI mode, read the MBR and use (currently 16 bytes at offset $1AE) for an "identifier" plus a "sector address" plus a possible "length" to load and run a stub block of data (user programmable) which will boot the SD card from there.
So there you have it. 3 possible pullups for the ROM to detect what to boot.
BTW I am looking at the implications of reversing D0..D3 on P59..P56 instead. An obvious second benefit is Octal SPI, but there is an extra REV instruction for every CLK (nibble for QSPI, byte for OctaSPI).
I normally share the SD lines with Flash except for CS but in some systems it's one or the other on the same 4 lines. The slowest part of using SD is really the card initialization which has to start at a few hundred kHz before ramping up and going through the rest of the initialization sequence. Some brands take longer than others but I can check my figures. As for finding the startup file that is very easy, especially if it's in the first sector of the root directory, it should only be a matter of a few milliseconds.
So, could we make a static 4-pin pinout that works with both SPI flash and SD card, assuming one or the other is present (or neither is present)?
If we had this:
P61 = CS (pull-up indicates presence of either SPI flash or SD card)
P60 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P59 = DI (could be used as SPI flash DQ0)
P58 = DO (could be used as SPI flash DQ1)
P57 = (could be used as SPI flash DQ2)
P56 = (could be used as SPI flash DQ3)
In the ROM booter now, I do some initial command/response sleuthing to determine if a SPI chip is present. That takes umpteen microseconds. If it seems present, it takes ~4ms to read in $100 longs and determine if they're legit. If either of those checks fail, could we then treat those 4 pins as if an SD card is connected, and see what we get? This would all be predicated on seeing a pull-up on P61, indicating some kind of memory is present. This keeps our initial "is-memory-present" pin checking down to ONE pin. Also, by keeping DI and DO separate for both SPI flash and SD card, we could hold DI high while reading SPI flash (CS is low during reading) to avoid some command being interpreted by the SD card. Also, keeping those pins separate allows for quad SPI flash usage.
What do you guys think about this? Is it possible to have a pin-out scheme for booting that supports both SPI flash and SD card, with static CS, CLK, DI, and DO pins?
The SD Card removes CS and becomes D3 when in native (non SPI) modes 1 & 4 bit. There is an internal pullup on CSin the SD Card - it may get switched off when in native mode, I just don't know. It would be preferable to not have a pullup on this pin.
Chip,
What happens when the FLASH has a valid but buggy program that locks the P2 up (eg a JMP missing "#") ?
It happens more than I would like. If there is no way the serial can get a look in, then the user may have to remove a resistor (if no jumper - and this is common with tiny pcbs). You covered this in the P1 by checking for a UART connection in booter (first 2 lines) and a pulldown on RXD=P63.
This is not a problem for the SD card as it can be removed and a new boot block of data written externally by a PC.
I am looking into your suggestion of reversing DO..D3 pins.
It will require an additional REV instruction per CLK. Currently the loop is 7 instructions (28 clocks) sending SPI 1-bit serial data, so it's not insignificant. Of course we will be sending nibbles per clock so there may be other savings.
For SD native mode, we also have to calculate CRCC16
I am looking into your suggestion of reversing DO..D3 pins.
It will require an additional REV instruction per CLK. Currently the loop is 7 instructions (28 clocks) sending SPI 1-bit serial data, so it's not insignificant. Of course we will be sending nibbles per clock so there may be other savings.
How does that reverse, impact someone using the streamer in 4 or 8 bit modes ?
You do not want the streamer info arriving scrambled.
I am looking into your suggestion of reversing DO..D3 pins.
It will require an additional REV instruction per CLK. Currently the loop is 7 instructions (28 clocks) sending SPI 1-bit serial data, so it's not insignificant. Of course we will be sending nibbles per clock so there may be other savings.
How does that reverse, impact someone using the streamer in 4 or 8 bit modes ?
You do not want the streamer info arriving scrambled.
I have left in EEPROM (2 pins) and FLASH (3 pins) just in case, or for reference.
CLK is always P60=CLK.
FLASH (4 & 6 pins)
Detection: Pullup on P61=nCS (If EEPROM supported, No-pullup on P60=CLK).
Initialisation: CS on P61=nCS, Send on P59=SI, Receive on P58=SO.
SD CARD (4 pins)
Detection: Pullup on P58=nCS, No-pullup on P61=DI.
Initialisation: CS on P58=nCS, Send on P61=DI, Receive on P59=DO.
SD CARD (6 pins)
Detection: Pullup on P56=nCS, No-pullup on P61=DI.
Initialisation: CS on P56=nCS, Send on P61=DI, Receive on P59=DO.
EEPROM (2 pins)
If supported...
Detection: Pullup on P61=SDA, Pullup on P60=CLK.
Initialisation: Send & Receive on P61=SDA.
Garbage in, garbage out. You only need to do a REV on command and address. Data doesn't care, or it can be done at the long level.
And, I don't want to mess with 4-data-wire SD card stuff, even supporting the pinout. It's totally unproven for us and I don't want to spend the pins on it.
The matter is this: Can we have CS/CLK/DI/DO pins that can connect to either a SPI flash or an SD card? Can we be confident about that working, and can we prove it sometime in the next several weeks?
P61 = CS (pull-up indicates presence of either SPI flash or SD card)
P60 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P59 = DI (could be used as SPI flash DQ0)
P58 = DO (could be used as SPI flash DQ1)
P57 = (could be used as SPI flash DQ2)
P56 = (could be used as SPI flash DQ3)
..... Also, by keeping DI and DO separate for both SPI flash and SD card, we could hold DI high while reading SPI flash (CS is low during reading) to avoid some command being interpreted by the SD card. Also, keeping those pins separate allows for quad SPI flash usage.
That sounds ok.
How does that pin map co-operate with the Streamer, in 4-bit and 8-bit modes ?
Can 4 more pins below P56, connect DQ4..DQ7 on a OctalFlash device, and work with the streamer ?
Wouldn't the data pins need to fall on a particular boundary, or are streamer pin blocks arbitrary in alignment? I don't recall. Use of the streamer may allow the four pins to be 56 to 59, while octal may need to push the pin set down to start on a block-of-8 boundary, regardless of bit orientation.
So, there may not be a suitable boot pinout that meets all stated aims of
minimal pin use;
1-bit, (2-bit), 4-bit, and octal FLASH/SD SPI variants; and
streamer support.
We've been presented a few options for boot pinouts, but I don't see how octal SPI can truly fit with any of them. A better option for those desiring the throughput of octal SPI is to "sacrifice" a further 8 contiguous pins on an appropriate boundary.
The remaining discussion seems to hinge on whether the boot pin set should be considered as a viable size and whether potentially skipping two pins in the boot pin set causes a problem.
I don't see the problem myself, as if you fix the boot pin set size at 8 there are 56 other pins on this device that most designers will use first, before this even starts to be a consideration.
If the Boot ROM doing a dance on pin 59, looking for a 3 pin FLASH SPI connection, doesn't disturb a 6 pin FLASH SPI connected device waiting on pin 56, then it seems that Cluso99's latest offering gives the most flexibility while also offering a number of minimal pin options.
It also means that the trade-off may be between boot time and run time data throughput: 3 pin 1-bit FLASH SPI will start booting faster, but 6 pin 4-bit FLASH SPI will give better throughput, especially if it can use a streamer.
The most radical suggestion to address bit order, minimal pin usage, and common pinning between FLASH/SD 1-bit/2-bit/4-bit/octal, would be to reverse it all, building from the bottom instead of the top:
P0 = SI/RXD
P1 = SO/TXD
P2 = CS (pull-up indicates presence of either SPI flash or SD card)
P3 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P4 = DI (could be used as SPI flash DQ0)
P5 = DO (could be used as SPI flash DQ1)
P6 = (could be used as SPI flash DQ2)
P7 = (could be used as SPI flash DQ3)
leaving P8 to P11 available to complete the set for octal SPI if the bye wide streamer can work from a 4 bit boundary.
What implications would this have for 1 bit streamer operation on the serial receive line?
If SI and SO is tied together, you should use the FastRead command ($0B) not the old Read command ($03). This command adds a dummy byte after the address which gives you 8 clocks time to switch from output to input (and allows also much faster clock rates).
Reversed D0..D3: In best case you only need to reverse the bits when you write the command and the address. For the data the bit order is not significant as long as it is the same for read and write.
But if you want to write the data in 1bit and read it in 4bit mode (or vice versa) you will get reversed data. So connecting the Flash in non-reversed bit order is preferable.
SI and SO on separate pins allows to use the Dual-FastRead command, which doubles the speed on reads. It's often a good compromise if you want fast speed but small pin count.
You might get away with reverse order data on Flash, although as Andy said, you cannot mix 1-bit and 4-bit reading and writing or you will get incorrect data.
If you are pre-programming the flash, then there is one more thing to go wrong.
Not a good choice IMHO. Just use a REV instruction.
However, with SD Card, you must have the data correctly stored, or otherwise you will not be able to read/write the card in another system, such as a pc.
But I can live with using REV to reverse the bit order.
I really want to persue the faster SD 4-bit mode. Thing is, self hosting (ie compiling) needs faster SD access if we can get it. It's a simple matter to permit both 4 & 6 pin SD boot options. I can write this in the time required.
So what boot options in my diagram above are out ???
How will we handle FLASH that passes checksum but has a bug preventing operation ?
I am presuming that we bypassed Serial download to make bootup quicker.
You might get away with reverse order data on Flash, although as Andy said, you cannot mix 1-bit and 4-bit reading and writing or you will get incorrect data.
If you are pre-programming the flash, then there is one more thing to go wrong.
Not a good choice IMHO. Just use a REV instruction.
However, with SD Card, you must have the data correctly stored, or otherwise you will not be able to read/write the card in another system, such as a pc.
But I can live with using REV to reverse the bit order.
I really want to persue the faster SD 4-bit mode. Thing is, self hosting (ie compiling) needs faster SD access if we can get it. It's a simple matter to permit both 4 & 6 pin SD boot options. I can write this in the time required.
So what boot options in my diagram above are out ???
How will we handle FLASH that passes checksum but has a bug preventing operation ?
I am presuming that we bypassed Serial download to make bootup quicker.
A header and jumper on the trace to nCS?
If FLASH gets corrupted, pull the jumper, boot from serial, install the jumper and re-program?
Comments
I answered the other questions on the FPGA thread.
Not sure what you mean ?
Chip's current flow shows SPI boot, tests checksum, and if that fails, it then does a Serial-wait.
So that covers flash faults.
If you mean user over-ride of a fast-spi-boot request, that executes fine and runs, but is wrong revision, then that needs the fast-SPI jumper physically removed.
(in my example, that is a resistor RXD-SPI_CS - Presence sensed by RXD toggled and CPI_CS is checked for changes)
If you do not like jumpers/physical removal, but do have a standard USB-UART type connection, you can always use the second handshake line to control a switch.
If I was doing a P2/Eval design, I'd include something like MUN5213DW1T1G, (Dual NPN pre-bias) for RST control and 'user control'.
of one feature, using both handshake lines.
I can see development use in remote manage/select of Serial Loader / standard SPI loader esp for classrooms.
Mostly you use Serial, and then can change to Flash load and flash boot tests, involving RST then finally power cycling.
Hopefully, the full power cycling is the same outcomes as the host-drives-RST tests
You know, based on the CLK signal that you drive, when the DO output enable is going to switch. Your code ensures that there's no electrical conflict. I certainly would have noticed on the scope if there were any mid-levels due to contention. I just wrote code according to how the data sheet said things change and it works fine. For example, if I know the DO is going to output after the next clock transition, I will float my data pin to accommodate that, before I cause the clock transition. And these clock transitions are separate from the transitions which clock data into the DI pin.
These flash chips are designed to accommodate their DI and DO being tied together.
How are you currently finding the data for booting in your SD card driver?
Are you just reading the first data out of the card, or are you looking for maybe a certain-named file? I remember there was much discussion over the merits of different techniques. Anyway, I am just wondering how you propose to do it.
Provided you tristate the output before the clock change, and enable after the clock change, the flash will not output until the clock change (perhaps plus a minor delay), and tristate at the clock change (perhaps plus a minor delay). So there should be no collisions and that would avoid the need for a protection series 3K3 resistor. You will need to be careful to use the correct clock edge depending on whether you use mode 0 or mode 3 SPI. Mode 0 seems to be preferred (CLK=0 at rest).
The AT25SF041 gives the setup time >2ns and hold time >2ns for SI (input to flash) wrt rising CLK,
and output hold time >0ns wrt falling CLK, and next output data valid <6-8ns wrt falling CLK. I presume the output will tristate (not shown) before the next output data would be valid ie <6-8ns.
SD SPI does not work that way though, at least from what the documentation says.
I use FAT16/32 to search for specifically named files (two such files can boot the P1).
However, I propose (as had been discussed long ago) to not cater for specific formatting such as FAT16/32, but rather look for a defined sequence in the MBR, followed by a card sector number, and use this sector number, potentially followed by a length, to directly load up some SD boot code into the P2 and execute it.
This also caters for future formats such as exFAT (requires MS license) or an open standard to avoid the license, or a separate partition, or whatever.
So, this can be as simple as a stub to negotiate the card format followed by searching for a file, or whatever. This way, the SD Boot ROM is minimal (currently about 1KB cog with debugging)
Sounds good about the SD boot process.
How long does it take to locate the start of data, from best case to worst case?
Can the CS, CLK, DI and DO pins be common between SPI flash and SPI SD? Or, is there a need to, say, make their CS pins different? Only one or the other would be present, mind you. In other words, could you figure out which one you were talking to over the same pins?
I normally share the SD lines with Flash except for CS but in some systems it's one or the other on the same 4 lines. The slowest part of using SD is really the card initialization which has to start at a few hundred kHz before ramping up and going through the rest of the initialization sequence. Some brands take longer than others but I can check my figures. As for finding the startup file that is very easy, especially if it's in the first sector of the root directory, it should only be a matter of a few milliseconds.
I did a drawing a few posts back that shows the pin connections required. nCS is on a different pin to FLASH.
It's hard to say how long the boot takes as cards are different for initialisation. You need to poll them and I presume they may get slower as they get used due to wear levelling. I have a test program so if I get a chance I will try my different cards over the w/e and time them.
Basically, you wait 1ms, send 74+ clocks at 50KHz (could be faster I think), then send some command sequences faster ~2.5MHz ($FF, cmd_byte, par_long, crc_byte, then clock in byte(s) reply) to setup and identify the card type, etc. The command sequences depend upon the replies. There is also a wait mechanism where the card replies $FF to delay the micro.
Okay. So, could we arrange pins like this:
61= SPI flash "CS", SD card "DI"
60 = "CLK" for both
59 = SPI flash "DI/DO", SD card "DO"
58 = SD card "CS"
The SD card's DI and DO could be swapped.
If we could use a common CS between SD card and SPI flash, we might as well use separate data pins. However, SD card needs its own CS, which we must employ a separate pin for. So, this allows us to boot from either SPI flash or SD card with a mere 4-pin footprint. That's three pins for SPI flash or four pins for SD card, each nicely tucked upwards.
Yes, but Cluso99 and Peter Jakacki have developed a reliable approach that they've been using for a while in their own creations. Cluso99 has offered to do a load implementation for the ROM.
If it works, and it's not a PITA, not glitchy, fine.
Would be nice to put the pointers in there in such a way as to not preclude using actual partition and filesystem support, but...
I'm sort of done. People want SD.
Just make sure it's solid.
Is that pin map also compatible with Streamer in 4-bit and 8-bit modes, for users of QuadSPI and OctalSPI devices ?
OctalSPI parts avoid the HOLDn,WPn, but do not care if their Dn has light-pull-hi - I'm less sure how the 8-bit streamer mode impacts possible pin-maps ?
That's why Octal users need to be included in the pin-choices.
Why does this have to be so hard? Just boot from the simplest, smallest, cheapest thing that is likely to be around for years.
Anything else can be boot strapped from that if anyone needs it.
So, could we make a static 4-pin pinout that works with both SPI flash and SD card, assuming one or the other is present (or neither is present)?
If we had this:
P61 = CS (pull-up indicates presence of either SPI flash or SD card)
P60 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P59 = DI (could be used as SPI flash DQ0)
P58 = DO (could be used as SPI flash DQ1)
P57 = (could be used as SPI flash DQ2)
P56 = (could be used as SPI flash DQ3)
In the ROM booter now, I do some initial command/response sleuthing to determine if a SPI chip is present. That takes umpteen microseconds. If it seems present, it takes ~4ms to read in $100 longs and determine if they're legit. If either of those checks fail, could we then treat those 4 pins as if an SD card is connected, and see what we get? This would all be predicated on seeing a pull-up on P61, indicating some kind of memory is present. This keeps our initial "is-memory-present" pin checking down to ONE pin. Also, by keeping DI and DO separate for both SPI flash and SD card, we could hold DI high while reading SPI flash (CS is low during reading) to avoid some command being interpreted by the SD card. Also, keeping those pins separate allows for quad SPI flash usage.
What do you guys think about this? Is it possible to have a pin-out scheme for booting that supports both SPI flash and SD card, with static CS, CLK, DI, and DO pins?
That sounds ok.
How does that pin map co-operate with the Streamer, in 4-bit and 8-bit modes ?
Can 4 more pins below P56, connect DQ4..DQ7 on a OctalFlash device, and work with the streamer ?
It is not hard, but needs a little care so Parallax can avoid telling users they need TWO DEVICES connected.
ie the Pin map needs to be physically & SW compatible, with common superset devices.
QuadSPI is now pretty much default, ('simplest, smallest, cheapest') starting at ~20c, and OctalSPI is emerging, and is a simple superset of 1-SPI/extended Quad.
This BOOTS in 1-spi mode, but users will expect to operate the same device, in Quad. (or octal)
I have done this before Chip has suggested reversing the D0..D3 pins, so I haven't thought that through yet, athough it does require an additional REV instruction every CLK (nibble) when using Quad mode.
There are also a few things than need explaining as some of you continue to get it wrong...
Most of the SPI FLASH have internal pullups on the HOLD and WP pins (see AT25SF041 datasheet). They do however also recommend that these pins be tied to Vcc.
* If the user only wants to use SPI FLASH in 3 or 4 pin mode, then you can tie the flash chips hold and wp to Vcc.
* If the user wants to use Quad SPI, then he either uses a FLASH with internal pullups on hold and wp, or he adds external pullup resistors.
If FLASH is used, then there will be a pullup on nCS = P61. This is easily detected by the boot software.
For those that want a really minimal boot pin system, then use I2C EEPROM. It only uses 2 pins and can easily be detected by pullups on SDA=P61 & SCL=CLK=P60. I don't care for EEPROM booting, but it's cheap, simple, known, and only uses 2 pins and 2 pullups.
Personally, I don't see the advantage of FLASH joining SI/SO to save a pin, but Chip wants it. I still do not like joining without a series resistor because the timing is quite strict to avoid bus conflict. It's hard to dig out the precise timing for tristate from the datasheets, if it's there at all.
Like many of you, I want to see the QUAD-SPI FLASH able to be used, so I am hoping for an ordered D0..D3 pinout. This does mean skipping 2pins (on my arrangement D0..D3 on P56..P59). IMHO we are not short of pins, and QSPI appears important enough to skip these pins. If a later P2 version is done with less pins, then P58 & P59 could be omitted from the IC unless by then the usage of QSPI will be known.
For SD, it needs/has a pullup on nCS=P59 which also doubles as D3 for SD 4-bit mode. There is an internal pullup on this pin, so Peter (Tachyon) does not fit an external pullup. I already had a pullup on my pcb when Peter told me this. It also serves to show an SD card is inserted. I really want to try and get the SD 4-bit mode to work, so I need the 6-pin option. For those that think I am wanting to put this in the ROM, I have clearly said this is NOT my intention. Nor do I intend to support FAT16/32, Partitions, or any other formatting on the SD Card. The ROM will just initialise the SD card in SPI mode, read the MBR and use (currently 16 bytes at offset $1AE) for an "identifier" plus a "sector address" plus a possible "length" to load and run a stub block of data (user programmable) which will boot the SD card from there.
So there you have it. 3 possible pullups for the ROM to detect what to boot.
BTW I am looking at the implications of reversing D0..D3 on P59..P56 instead. An obvious second benefit is Octal SPI, but there is an extra REV instruction for every CLK (nibble for QSPI, byte for OctaSPI).
The SD Card removes CS and becomes D3 when in native (non SPI) modes 1 & 4 bit. There is an internal pullup on CSin the SD Card - it may get switched off when in native mode, I just don't know. It would be preferable to not have a pullup on this pin.
Chip,
What happens when the FLASH has a valid but buggy program that locks the P2 up (eg a JMP missing "#") ?
It happens more than I would like. If there is no way the serial can get a look in, then the user may have to remove a resistor (if no jumper - and this is common with tiny pcbs). You covered this in the P1 by checking for a UART connection in booter (first 2 lines) and a pulldown on RXD=P63.
This is not a problem for the SD card as it can be removed and a new boot block of data written externally by a PC.
I am looking into your suggestion of reversing DO..D3 pins.
It will require an additional REV instruction per CLK. Currently the loop is 7 instructions (28 clocks) sending SPI 1-bit serial data, so it's not insignificant. Of course we will be sending nibbles per clock so there may be other savings.
For SD native mode, we also have to calculate CRCC16
You do not want the streamer info arriving scrambled.
I have left in EEPROM (2 pins) and FLASH (3 pins) just in case, or for reference.
CLK is always P60=CLK.
FLASH (4 & 6 pins)
Detection: Pullup on P61=nCS (If EEPROM supported, No-pullup on P60=CLK).
Initialisation: CS on P61=nCS, Send on P59=SI, Receive on P58=SO.
SD CARD (4 pins)
Detection: Pullup on P58=nCS, No-pullup on P61=DI.
Initialisation: CS on P58=nCS, Send on P61=DI, Receive on P59=DO.
SD CARD (6 pins)
Detection: Pullup on P56=nCS, No-pullup on P61=DI.
Initialisation: CS on P56=nCS, Send on P61=DI, Receive on P59=DO.
EEPROM (2 pins)
If supported...
Detection: Pullup on P61=SDA, Pullup on P60=CLK.
Initialisation: Send & Receive on P61=SDA.
And, I don't want to mess with 4-data-wire SD card stuff, even supporting the pinout. It's totally unproven for us and I don't want to spend the pins on it.
The matter is this: Can we have CS/CLK/DI/DO pins that can connect to either a SPI flash or an SD card? Can we be confident about that working, and can we prove it sometime in the next several weeks?
Wouldn't the data pins need to fall on a particular boundary, or are streamer pin blocks arbitrary in alignment? I don't recall. Use of the streamer may allow the four pins to be 56 to 59, while octal may need to push the pin set down to start on a block-of-8 boundary, regardless of bit orientation.
So, there may not be a suitable boot pinout that meets all stated aims of
1-bit, (2-bit), 4-bit, and octal FLASH/SD SPI variants; and
streamer support.
We've been presented a few options for boot pinouts, but I don't see how octal SPI can truly fit with any of them. A better option for those desiring the throughput of octal SPI is to "sacrifice" a further 8 contiguous pins on an appropriate boundary.
The remaining discussion seems to hinge on whether the boot pin set should be considered as a viable size and whether potentially skipping two pins in the boot pin set causes a problem.
I don't see the problem myself, as if you fix the boot pin set size at 8 there are 56 other pins on this device that most designers will use first, before this even starts to be a consideration.
If the Boot ROM doing a dance on pin 59, looking for a 3 pin FLASH SPI connection, doesn't disturb a 6 pin FLASH SPI connected device waiting on pin 56, then it seems that Cluso99's latest offering gives the most flexibility while also offering a number of minimal pin options.
It also means that the trade-off may be between boot time and run time data throughput: 3 pin 1-bit FLASH SPI will start booting faster, but 6 pin 4-bit FLASH SPI will give better throughput, especially if it can use a streamer.
The most radical suggestion to address bit order, minimal pin usage, and common pinning between FLASH/SD 1-bit/2-bit/4-bit/octal, would be to reverse it all, building from the bottom instead of the top:
P0 = SI/RXD
P1 = SO/TXD
P2 = CS (pull-up indicates presence of either SPI flash or SD card)
P3 = CLK (pull-up indicates 'skip serial wait if boot data okay')
P4 = DI (could be used as SPI flash DQ0)
P5 = DO (could be used as SPI flash DQ1)
P6 = (could be used as SPI flash DQ2)
P7 = (could be used as SPI flash DQ3)
leaving P8 to P11 available to complete the set for octal SPI if the bye wide streamer can work from a 4 bit boundary.
What implications would this have for 1 bit streamer operation on the serial receive line?
Regards,
Anthony.
Reversed D0..D3: In best case you only need to reverse the bits when you write the command and the address. For the data the bit order is not significant as long as it is the same for read and write.
But if you want to write the data in 1bit and read it in 4bit mode (or vice versa) you will get reversed data. So connecting the Flash in non-reversed bit order is preferable.
SI and SO on separate pins allows to use the Dual-FastRead command, which doubles the speed on reads. It's often a good compromise if you want fast speed but small pin count.
Andy
If you are pre-programming the flash, then there is one more thing to go wrong.
Not a good choice IMHO. Just use a REV instruction.
However, with SD Card, you must have the data correctly stored, or otherwise you will not be able to read/write the card in another system, such as a pc.
But I can live with using REV to reverse the bit order.
I really want to persue the faster SD 4-bit mode. Thing is, self hosting (ie compiling) needs faster SD access if we can get it. It's a simple matter to permit both 4 & 6 pin SD boot options. I can write this in the time required.
So what boot options in my diagram above are out ???
1. Remove FLASH SPI 3 pin ?
2. Remove SD 6 pin ? ..... Please leave it in!
3. Remove EEPROM I2C 2 pin ?
How will we handle FLASH that passes checksum but has a bug preventing operation ?
I am presuming that we bypassed Serial download to make bootup quicker.
A header and jumper on the trace to nCS?
If FLASH gets corrupted, pull the jumper, boot from serial, install the jumper and re-program?