And chips are designed not to burn up under such shorted circumstances. By outputing to DI/DO/WPn/HOLDn (DQ0..DQ3) when any of them are outputting would also cause contention. It would only waste power, though.
So I, as a naive new user with a new P2 QuickStart board, can't damage anything by fiddling around with my new P2 program and unintentionally programming those pins to do something completely different from what the carefully designed boot code does? No 'halt and catch fire'?
Still thinking and still believe 3pin SPI is bad. Here is my best reason why...
On P1, most of my projects have been short of pins, then hub memory, mostly in that order.
I have been able to share the boot pins of P1 (P28 CLK, P29 SDA, P30 SO, P31 SI).
On P2, I will not be able to share the common DO/DI pin. This may be fine for the initial 64 pin version. But it would be a shame to lock this in for a smaller P2 with less pins.
SD SPI
It is easy to share 4pin FLASH and 4pin SD SPI pins provided the CSn of both devices are separated.
The faultly mode of SD SPI (where DO remains an output after CSn=1) is easily solved by giving the SD some more clocks (with CSn=1 and perhaps DI=1 - not sure on the DI=1 part). It is not a power up problem, just an issue while using the SD.
It was found because I share the CLK, DI & DO pins with SRAM address and/or data pins, and the SD failed to release DO under some circumstances, corrupting my SRAM access. But it has been totally resolved. IIRC it was only on sme SD cards, not all. So most likely a bug.
As for "hot inserting" SD cards, I don't allow this on my boards. I don't test for the removal, and if you do, then you need to reinitialise the card for use. Even the FAT could change with this. But this is not a problem for booting the P2 - It is a user problem to resolve with following code (not boot code).
So, to sum up...
* Allow I2C EEPROM boot - 2pin, quick and easy to test for pullup on CLK (& SDA), and can be shared with boot FLASH or SD, other I2C devices, and other devices. Only read 4KB and execute this will allow for 24C32 and above.
* FLASH SPI 4pin - allows for sharing of pins, even I2C, other SPI devices, and other devices.
* SD SPI 4pin - allows for sharing of pins, even I2C, other SPI devices, and other devices.
* SERIAL - traditional P62/63 as on P1 and/or other modes.
If some radical new chip comes up during the life of the P2, then just use a small I2C EEPROM or SPI 4pin FLASH to boot the new whatever. Should be future proof!!
As for "hot inserting" SD cards, I don't allow this on my boards.
How do you prevent this? It seems to me that users of any self-hosted system will expect to be able to hot-plug SD cards. Even if you say it isn't supported, people will do it anyway. Seems like the only safe approach is to use separate pins for SD.
As for "hot inserting" SD cards, I don't allow this on my boards.
How do you prevent this? It seems to me that users of any self-hosted system will expect to be able to hot-plug SD cards. Even if you say it isn't supported, people will do it anyway. Seems like the only safe approach is to use separate pins for SD.
Never tried it, so I will.
I would expect that since the card does not get issued with the proper initialisation command sequence that it just wont work.
As for "hot inserting" SD cards, I don't allow this on my boards.
How do you prevent this? It seems to me that users of any self-hosted system will expect to be able to hot-plug SD cards. Even if you say it isn't supported, people will do it anyway. Seems like the only safe approach is to use separate pins for SD.
Never tried it, so I will.
I would expect that since the card does not get issued with the proper initialisation command sequence that it just wont work.
I'm not so much worried that the card won't work. I'm more worried that an insertion during a SPI access on the same bus to another device will end up with corrupted data.
On P2, I will not be able to share the common DO/DI pin....
Why not? You can share the Flash DI/DO pin with the DI pin of the SDcard. The SD-DO pin needs anyway its own pin if the SD card does not support DI/DO tied together.
The SPI driver needs the DO pin to be configurable, as it is anyway the case for the CS pin.
Here the 3 pin Flash connection is even an advantage: You can access the Flash also if the SD-DO pin is not tristated.
On P2, I will not be able to share the common DO/DI pin....
Why not? You can share the Flash DI/DO pin with the DI pin of the SDcard. The SD-DO pin needs anyway its own pin if the SD card does not support DI/DO tied together.
The SPI driver needs the DO pin to be configurable, as it is anyway the case for the CS pin.
Here the 3 pin Flash connection is even an advantage: You can access the Flash also if the SD-DO pin is not tristated.
Andy
Thanks Andy,
Of course you are correct. But will have to remember to go from the P2 end (star formation) and not daisy chain from the SPI end.
On P2, I will not be able to share the common DO/DI pin....
Why not? You can share the Flash DI/DO pin with the DI pin of the SDcard. The SD-DO pin needs anyway its own pin if the SD card does not support DI/DO tied together.
The SPI driver needs the DO pin to be configurable, as it is anyway the case for the CS pin.
Here the 3 pin Flash connection is even an advantage: You can access the Flash also if the SD-DO pin is not tristated.
Andy
Good point.
All this three-pin disagreement really stems from the fact that dual/quad access will be impeded. It's NOT an electrical issue. Well, it's an electro-political issue.
I would like to be able to detect 3 vs 4 pin, but I'm worried about capacitive coupling causing false positives.
If there is a pullup on DI pin, that is unlikely.
In the FPGA that pullup can be external, but enabled on the final Device. The ROM line would be ignored in FPGA ?
I would like to be able to detect 3 vs 4 pin, but I'm worried about capacitive coupling causing false positives.
If there is a pullup on DI pin, that is unlikely.
In the FPGA that pullup can be external, but enabled on the final Device. The ROM line would be ignored in FPGA ?
Good idea. I'd like to not disturb pin 58 when checking for 3-pin.
If you're thinking about using 4 pins to support either one of SPI flash or SD win one CS, you could also make P58 the CS for the SD and have it pulled up.
On P2, I will not be able to share the common DO/DI pin....
Why not? You can share the Flash DI/DO pin with the DI pin of the SDcard. The SD-DO pin needs anyway its own pin if the SD card does not support DI/DO tied together.
The SPI driver needs the DO pin to be configurable, as it is anyway the case for the CS pin.
Here the 3 pin Flash connection is even an advantage: You can access the Flash also if the SD-DO pin is not tristated.
Andy
Thanks Andy,
Of course you are correct. But will have to remember to go from the P2 end (star formation) and not daisy chain from the SPI end.
Again, can you verify that a hot-plugged SD card won't interfere with concurrent transfers on the SPI flash with shared pins? Remember that the SD card starts in SDIO mode when first inserted.
If you're thinking about using 4 pins to support either one of SPI flash or SD win one CS, you could also make P58 the CS for the SD and have it pulled up.
Then you are back to 4-pin SPI...
Yes, 4-pin SPI memory or 4-pin SD card, with a 3-pin SPI memory option to save one pin. Whatever is on those pins gets booted.
Is it possible to run an SD card over 3 pins by using a resistor between DI and DO? I think this would only come up during commands, not reading or writing. Thinking about it, this should always work, because if you are driving DI directly and connecting to DO via a ~1k resistor, you could always drive for DI during the input clock edge (to write) and then float for DO on the output edge (to read). I think that would have to work. During long reads, you should be able to float the data pin continuously and on writes, you would drive it. Unless there are some rules about shifting in 1's to DI while you read DO, this should be quite fast in operation.
If that were possible, we could have three-pin boot options for both SPI memories and SD cards.
I like that idea (of 3 and 4 pin SPI flash support)... For SPI, you could listen on both P58 and P59 for MISO and test both 3-pin and 4-pin modes at same time...
But, I think that mode won't work with that Cypress DDR flash.
Their datasheet says this in the CS section:
"After Power-up, a falling edge on CS# is required prior to the start of any command."
...
If that were possible, we could have three-pin boot options for both SPI memories and SD cards.
Worth testing, tho the practical use of this depends on if you can also write to a SD card in 3-pin mode.
If you need to connect as 4-pin in order to write to SD, you have actually saved a pin only in SD-Read-only-Boot cases.
...
If that were possible, we could have three-pin boot options for both SPI memories and SD cards.
Worth testing, tho the practical use of this depends on if you can also write to a SD card in 3-pin mode.
If you need to connect as 4-pin in order to write to SD, you have actually saved a pin only in SD-Read-only-Boot cases.
Even in reading, you must have a two-way chat, right?
Even in reading, you must have a two-way chat, right?
Well, yes, the difference is subtle, with the odds being if you can issue commands, you can likely also continue and write data.
It is very likely users will be writing to SD cards, so this should be picked up in 4P & 3P connection testing.
Is it possible to run an SD card over 3 pins by using a resistor between DI and DO? I think this would only come up during commands, not reading or writing. Thinking about it, this should always work, because if you are driving DI directly and connecting to DO via a ~1k resistor, you could always drive for DI during the input clock edge (to write) and then float for DO on the output edge (to read). I think that would have to work. During long reads, you should be able to float the data pin continuously and on writes, you would drive it. Unless there are some rules about shifting in 1's to DI while you read DO, this should be quite fast in operation.
If that were possible, we could have three-pin boot options for both SPI memories and SD cards.
Chip,
Please don't try this!
I don't know anyone who has tried it.
The DO failing to release "could" cause a problem with the prop outputting an initialisation sequence ( /CS=1 + DI=1(fm P2) + 74*CLKs) if the "fix" that I found has not been applied to the SD Driver. All drivers suffered from this, and it is not written about in any of the SD writeups that I googled.
I share all 4 SD SPI pins (yes, even /CS with a 6pin decoder chip).
If you are so obsessed (apologies for being so blunt) with a minimum number of boot pins, then you should really think about adding 2 pin I2C EEPROM boot code because these pins can be shared without problems because we have done this on P1.
IMHO you should support both 3 & 4 pin SPI FLASH too, or just 4pin.
I would still like to know the ramifications of a minimum of EEPROM/FLASH/OTP on the P2 die. It would solve all these issues, and be more like a mainstream micro from the booting point of view.
The DO failing to release "could" cause a problem with the prop outputting an initialisation sequence ( /CS=1 + DI=1(fm P2) + 74*CLKs) if the "fix" that I found has not been applied to the SD Driver. All drivers suffered from this, and it is not written about in any of the SD writeups that I googled.
I share all 4 SD SPI pins (yes, even /CS with a 6pin decoder chip).
If you are so obsessed (apologies for being so blunt) with a minimum number of boot pins, then you should really think about adding 2 pin I2C EEPROM boot code because these pins can be shared without problems because we have done this on P1.
IMHO you should support both 3 & 4 pin SPI FLASH too, or just 4pin.
I would still like to know the ramifications of a minimum of EEPROM/FLASH/OTP on the P2 die. It would solve all these issues, and be more like a mainstream micro from the booting point of view.
Well, hold on a minute...
Let's say that 2 RC periods are plenty to get us beyond logic thresholds.
Capacitance should be well under 50pf, but we'll use 50pf. So, C = 5e-11.
At 25 MHz, T = 4*10e-8, or 40ns.
We need to know what R would have to be. T = RC, or R = T/C.
R = 4*10e-8 / 5e-11 = 800 ohms. That's for one RC period. Halve that to 400 ohms for two RC periods.
So, let's say we put a 470 ohm resistor between DI and DO and connect DI to the Prop2. That way, we can always drive a good logic level into DI, no matter what DO is driving, and we can make that pin an input to read DO.
At 3.3V, that 470-ohm resistor would have 7mA of current going through it, assuming opposing pins were at the rails, which they wouldn't be. It might be more like 5mA. So, would an SD card get upset if it was sinking or sourcing 5mA through its DO pin? That is maybe the only question. Remember, we can always drive a good logic level into DI and we can always float our pin to read DO. Would the card have issues with 5mA currents on its DO pin? I think that determines it.
Imagine a 3-pin scheme for booting either SPI memory or SD cards!!!!
We could accommodate 4-pin, as well, but it would be really neat to do either one in only 3 pins.
Imagine a 3-pin scheme for booting either SPI memory or SD cards!!!!
We could accommodate 4-pin, as well, but it would be really neat to do either one in only 3 pins.
I think it is fine to test first for a 3-Pin connected Boot source, but it does need to have a fall-back to a 4-Pin mode as a next thing to try....
Otherwise, it's rather more of a drop-dead situation to the users.
You can test 3P first, without any pin disturbance on the 4th pin, and then only if that fails to detect, you try 4 pin.
Imagine a 3-pin scheme for booting either SPI memory or SD cards!!!!
We could accommodate 4-pin, as well, but it would be really neat to do either one in only 3 pins.
I think it is fine to test first for a 3-Pin connected Boot source, but it does need to have a fall-back to a 4-Pin mode as a next thing to try....
Otherwise, it's rather more of a drop-dead situation to the users.
You can test 3P first, without any pin disturbance on the 4th pin, and then only if that fails to detect, you try 4 pin.
Comments
On P1, most of my projects have been short of pins, then hub memory, mostly in that order.
I have been able to share the boot pins of P1 (P28 CLK, P29 SDA, P30 SO, P31 SI).
On P2, I will not be able to share the common DO/DI pin. This may be fine for the initial 64 pin version. But it would be a shame to lock this in for a smaller P2 with less pins.
SD SPI
It is easy to share 4pin FLASH and 4pin SD SPI pins provided the CSn of both devices are separated.
The faultly mode of SD SPI (where DO remains an output after CSn=1) is easily solved by giving the SD some more clocks (with CSn=1 and perhaps DI=1 - not sure on the DI=1 part). It is not a power up problem, just an issue while using the SD.
It was found because I share the CLK, DI & DO pins with SRAM address and/or data pins, and the SD failed to release DO under some circumstances, corrupting my SRAM access. But it has been totally resolved. IIRC it was only on sme SD cards, not all. So most likely a bug.
As for "hot inserting" SD cards, I don't allow this on my boards. I don't test for the removal, and if you do, then you need to reinitialise the card for use. Even the FAT could change with this. But this is not a problem for booting the P2 - It is a user problem to resolve with following code (not boot code).
So, to sum up...
* Allow I2C EEPROM boot - 2pin, quick and easy to test for pullup on CLK (& SDA), and can be shared with boot FLASH or SD, other I2C devices, and other devices. Only read 4KB and execute this will allow for 24C32 and above.
* FLASH SPI 4pin - allows for sharing of pins, even I2C, other SPI devices, and other devices.
* SD SPI 4pin - allows for sharing of pins, even I2C, other SPI devices, and other devices.
* SERIAL - traditional P62/63 as on P1 and/or other modes.
If some radical new chip comes up during the life of the P2, then just use a small I2C EEPROM or SPI 4pin FLASH to boot the new whatever. Should be future proof!!
I would expect that since the card does not get issued with the proper initialisation command sequence that it just wont work.
Why not? You can share the Flash DI/DO pin with the DI pin of the SDcard. The SD-DO pin needs anyway its own pin if the SD card does not support DI/DO tied together.
The SPI driver needs the DO pin to be configurable, as it is anyway the case for the CS pin.
Here the 3 pin Flash connection is even an advantage: You can access the Flash also if the SD-DO pin is not tristated.
Andy
But, we need those pins for QPI flash...
I'm thinking we need to require a flash chip in the hardware. Just like P1 needs eeprom...
Third stage can handle sd and/or qpi flash
Of course you are correct. But will have to remember to go from the P2 end (star formation) and not daisy chain from the SPI end.
Good point.
All this three-pin disagreement really stems from the fact that dual/quad access will be impeded. It's NOT an electrical issue. Well, it's an electro-political issue.
Are you now planning to support both FLASH SPI 3 & 4 pin modes?
I would like to be able to detect 3 vs 4 pin, but I'm worried about capacitive coupling causing false positives.
I think the boot pin check should be on the same pins for both SD card and SPI chip:
CSn
CLK
DI or DI+DO
DO
Is there an obvious way to discriminate between SPI and SD card?
In the FPGA that pullup can be external, but enabled on the final Device. The ROM line would be ignored in FPGA ?
Good idea. I'd like to not disturb pin 58 when checking for 3-pin.
Then you are back to 4-pin SPI...
Yes, 4-pin SPI memory or 4-pin SD card, with a 3-pin SPI memory option to save one pin. Whatever is on those pins gets booted.
Is it possible to run an SD card over 3 pins by using a resistor between DI and DO? I think this would only come up during commands, not reading or writing. Thinking about it, this should always work, because if you are driving DI directly and connecting to DO via a ~1k resistor, you could always drive for DI during the input clock edge (to write) and then float for DO on the output edge (to read). I think that would have to work. During long reads, you should be able to float the data pin continuously and on writes, you would drive it. Unless there are some rules about shifting in 1's to DI while you read DO, this should be quite fast in operation.
If that were possible, we could have three-pin boot options for both SPI memories and SD cards.
http://www.ti.com/lit/ug/sprued4b/sprued4b.pdf
Screenshot attached.
They claim that you don't need CS if only one device is on the SPI bus...
Hey, maybe we could do this with 2-pins?
If you want to share the bus then also connect cs to a prop pin and drive it low.
Their datasheet says this in the CS section:
"After Power-up, a falling edge on CS# is required prior to the start of any command."
Once a solid SD code base is there for 4-pin, this should be relatively easy to check on real cards.
Worth testing, tho the practical use of this depends on if you can also write to a SD card in 3-pin mode.
If you need to connect as 4-pin in order to write to SD, you have actually saved a pin only in SD-Read-only-Boot cases.
Even in reading, you must have a two-way chat, right?
It is very likely users will be writing to SD cards, so this should be picked up in 4P & 3P connection testing.
Please don't try this!
I don't know anyone who has tried it.
The DO failing to release "could" cause a problem with the prop outputting an initialisation sequence ( /CS=1 + DI=1(fm P2) + 74*CLKs) if the "fix" that I found has not been applied to the SD Driver. All drivers suffered from this, and it is not written about in any of the SD writeups that I googled.
I share all 4 SD SPI pins (yes, even /CS with a 6pin decoder chip).
If you are so obsessed (apologies for being so blunt) with a minimum number of boot pins, then you should really think about adding 2 pin I2C EEPROM boot code because these pins can be shared without problems because we have done this on P1.
IMHO you should support both 3 & 4 pin SPI FLASH too, or just 4pin.
I would still like to know the ramifications of a minimum of EEPROM/FLASH/OTP on the P2 die. It would solve all these issues, and be more like a mainstream micro from the booting point of view.
Well, hold on a minute...
Let's say that 2 RC periods are plenty to get us beyond logic thresholds.
Capacitance should be well under 50pf, but we'll use 50pf. So, C = 5e-11.
At 25 MHz, T = 4*10e-8, or 40ns.
We need to know what R would have to be. T = RC, or R = T/C.
R = 4*10e-8 / 5e-11 = 800 ohms. That's for one RC period. Halve that to 400 ohms for two RC periods.
So, let's say we put a 470 ohm resistor between DI and DO and connect DI to the Prop2. That way, we can always drive a good logic level into DI, no matter what DO is driving, and we can make that pin an input to read DO.
At 3.3V, that 470-ohm resistor would have 7mA of current going through it, assuming opposing pins were at the rails, which they wouldn't be. It might be more like 5mA. So, would an SD card get upset if it was sinking or sourcing 5mA through its DO pin? That is maybe the only question. Remember, we can always drive a good logic level into DI and we can always float our pin to read DO. Would the card have issues with 5mA currents on its DO pin? I think that determines it.
Imagine a 3-pin scheme for booting either SPI memory or SD cards!!!!
We could accommodate 4-pin, as well, but it would be really neat to do either one in only 3 pins.
It's neat, but is it really worth it?
I'd be OK with a plain 4-pin SPI that first checks for flash and then for SD.
That sounds complicated enough...
Otherwise, it's rather more of a drop-dead situation to the users.
You can test 3P first, without any pin disturbance on the 4th pin, and then only if that fails to detect, you try 4 pin.
Agreed.