@"David Betz" - once the card has been initialised after cmd0 etc it stays in spi mode, there is no such thing as putting it back into spi mode. The flash and sd that we have mixed on the same pins do work well as long as we can decouple the sd data out pin since it does not float after chip enable is deselected as we normally expect from spi bus chips.
Will it work if I have both a SD card and a SPI flash chip connected with an SD card in the socket but I want to boot from the SPI flash? It seems to me that if it tries to boot from the SPI flash before initializing the SD card the SPI flash boot will fail. So my question is, will it initialize the SD card before it tries to boot from SPI flash?
Strange. I thought when I looked through some of the SD card info a while back you were meant to be able to reinit a card to get into SD mode from SPI mode, by clocking in CMD 0 with CS held high. Does that not remedy the issue? I know it is of no use to the P2 ROM revA we currently have there for SD/flash but if it works that might be useful going forwards...
Update: Actually now I think I am remembering wrong and the only way to return to SD mode is actually a power cycle. So no use.
If Cluso99's SD booter code can't find legitimate data to boot, it would be good if he did a command to release the SD DO (if such a command exists). The resistor fix will let us boot from SPI flash after a failed SD boot, but that SD DO line will be contentious, causing an ongoing current draw.
If Cluso99's SD booter code can't find legitimate data to boot, it would be good if he did a command to release the SD DO (if such a command exists). The resistor fix will let us boot from SPI flash after a failed SD boot, but that SD DO line will be contentious, causing an ongoing current draw.
His comments suggest there is some possible SW/BUS fix, but less clear is if that would resolve the separate issue David Betz mentions ?
The anti-contention resistor sounds useful to have in any case.
If Cluso99's SD booter code can't find legitimate data to boot, it would be good if he did a command to release the SD DO (if such a command exists). The resistor fix will let us boot from SPI flash after a failed SD boot, but that SD DO line will be contentious, causing an ongoing current draw.
His comments suggest there is some possible SW/BUS fix, but less clear is if that would resolve the separate issue David Betz mentions ?
The anti-contention resistor sounds useful to have in any case.
We added the resistor today to the P2 Eval board. The board will be done today, but we are a week out on building them.
.. it has bitten me on circuits I've built when I have an SD card connected but am not using it for a particular program and then have trouble communicating with other SPI devices on the same pins.
What was the power supply & Vcc rise time on those circuits ?
I don't know. It was a Propeller C3 board that I got from Parallax. It wasn't actually a circuit I designed myself.
The C3 uses a shift register, or maybe a counter and demux to generate the CS. Maybe the CS was pulsed for the SD card, and it got into a state that interfered with other SPI devices.
.. it has bitten me on circuits I've built when I have an SD card connected but am not using it for a particular program and then have trouble communicating with other SPI devices on the same pins.
What was the power supply & Vcc rise time on those circuits ?
I don't know. It was a Propeller C3 board that I got from Parallax. It wasn't actually a circuit I designed myself.
The C3 uses a shift register, or maybe a counter and demux to generate the CS. Maybe the CS was pulsed for the SD card, and it got into a state that interfered with other SPI devices.
Purely an SD card issue, that's how they operate in SPI mode with the output enabled. The C3 used a really awkward method of SPI bus CS that didn't seem to take into account just how awkward that would be in software. I'm glad that didn't repeat that method on other boards.
The SD card and SPI Flash can co-exist on the same 4 I/O we have them on now as long as we decouple the SD data out through a resistor. There is not an ongoing issue with current draw since the SPI Flash floats its data out when its chip select goes inactive. The current draw through the resistor only occurs when the SPI Flash is outputting a low when it is being read. I am going to try some higher values at 30MHz SPI bus rates to confirm that all is good.
If there is an SD card, and there is NO pullup on P59, the boot ROM will attempt to read from the SD card. BINGO, DO is made an output. I have seen this before on P1, and fixed it in code by giving it some clocks. I just need to search the code for the fix - I documented it on the various SD card drivers. I share all the pins on my RamBlade with SRAM so the fix works.
In reality, if there is an SD card, and you want to boot from it, then code should be loaded and this code can supply the fix for the first silicon. Currently the workaround is to power down if you also want to access the FLASH as well as the SD card ie both cannot be accessed in the same boot.
If there is an SD card, and there is a pullup on P59, the boot ROM DOES NOT TRY THE SD CARD, so everything is fine until you access the SD card. Thereafter (for now) the FLASH doesn't work unless there is a serial resistor in play from the SD card.
Hmm, could DO behaviour depend on the particular SD card? I have SPI RAM and an SD card sharing pins on my P1 board. The EEPROM program uses fsrw and tries to mount the card immediatly and usually succeeds, unless the card has just been inserted or on a cold boot (in those cases, a second try works). However, when I upload code over serial (thereby not properly unmounting the card) that uses the RAM (but has no SD card code), it works just fine. So either my RAM is strong enough to fight the card for bus supremacy or the card releases DO on its own.
If there is an SD card, and there is NO pullup on P59, the boot ROM will attempt to read from the SD card. BINGO, DO is made an output. I have seen this before on P1, and fixed it in code by giving it some clocks. I just need to search the code for the fix - I documented it on the various SD card drivers. I share all the pins on my RamBlade with SRAM so the fix works.
In reality, if there is an SD card, and you want to boot from it, then code should be loaded and this code can supply the fix for the first silicon. Currently the workaround is to power down if you also want to access the FLASH as well as the SD card ie both cannot be accessed in the same boot.
If there is an SD card, and there is a pullup on P59, the boot ROM DOES NOT TRY THE SD CARD, so everything is fine until you access the SD card. Thereafter (for now) the FLASH doesn't work unless there is a serial resistor in play from the SD card.
So you're saying that just the presence of the SD card will not interfere with booting from the SPI flash? I mean, what if the boot ROM knew nothing about SD and only tried talking to the SPI flash with the SD card also connected. Would that cause a problem?
Just test 240R in series with the SD data out and it still works at 30MHz SPI bus so it seems that this is the simple solution. The only time "loading" occurs is when there is an SD card inserted that has been initialized AND when the SPI Flash is reading data that is a LOW. Then the peak I/O current is around 12ma but obviously even if the SPI Flash was being read continuously that would probably average 6ma but the reality is that Flash is not used that way either. Given that the eval board has 3A regs for both the 1.8V and 3.3V supply it seems ludicrous to even worry about the peak current of 12ma on this line.
If there is an SD card, and there is NO pullup on P59, the boot ROM will attempt to read from the SD card. BINGO, DO is made an output. I have seen this before on P1, and fixed it in code by giving it some clocks. I just need to search the code for the fix - I documented it on the various SD card drivers. I share all the pins on my RamBlade with SRAM so the fix works.
In reality, if there is an SD card, and you want to boot from it, then code should be loaded and this code can supply the fix for the first silicon. Currently the workaround is to power down if you also want to access the FLASH as well as the SD card ie both cannot be accessed in the same boot.
If there is an SD card, and there is a pullup on P59, the boot ROM DOES NOT TRY THE SD CARD, so everything is fine until you access the SD card. Thereafter (for now) the FLASH doesn't work unless there is a serial resistor in play from the SD card.
Cluso99, it would be great if, when your in-ROM booter attempts to boot SD, but fails for any reason, it would issue whatever command sequence gets it to stop driving DO.
Seems like you guys are just ignoring David Betz specific question/case.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
Seems like you guys are just ignoring David Betz specific question/case.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
So no matter how many times now and in the past we have tested this and I even post terminal shots, nobody actually pays heed to the answer? Seems like everyone loves having a problem to discuss without really worrying about the solution or workaround.
SPI Flash boots with SD in. SD boots with Flash in. But if SD is accessed with a card in it will lock out Flash due to data output contention.The workaround is fixed using a resistor.
There is no problem with having these two devices actively sharing the same pins as long as we use a resistor.
There is no command sequence that releases the DATA OUT line once the card has been initialized into SPI mode. Only power cycling will release the data out. While there is a CMD7 with address 0 that will release the DAT line, it cannot be used in SPI mode.
Seems like you guys are just ignoring David Betz specific question/case.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
As Peter said, these are actual results with a real P2D2 and OnSemi silicon (one of the 10 chips). How many times do we need to say this!
Here is a pic of my setup. The resistor on the right is a 5K pullup on P59. There is an RGB LED on the left. My PropPlug also provides 5V from the USB.
With this setup TAQOZ will read the FLASH correctly unless I initialise the SD card using the ROM Monitor.
Seems like you guys are just ignoring David Betz specific question/case.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
As Peter said, these are actual results with a real P2D2 and OnSemi silicon (one of the 10 chips). How many times do we need to say this!
Here is a pic of my setup. The resistor on the right is a 5K pullup on P59. There is an RGB LED on the left. My PropPlug also provides 5V from the USB.
With this setup TAQOZ will read the FLASH correctly unless I initialise the SD card using the ROM Monitor.
Seems like you guys are just ignoring David Betz specific question/case.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
As Peter said, these are actual results with a real P2D2 and OnSemi silicon (one of the 10 chips). How many times do we need to say this!
Here is a pic of my setup. The resistor on the right is a 5K pullup on P59. There is an RGB LED on the left. My PropPlug also provides 5V from the USB.
With this setup TAQOZ will read the FLASH correctly unless I initialise the SD card using the ROM Monitor.
Seems like you guys are just ignoring David Betz specific question/case.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
As Peter said, these are actual results with a real P2D2 and OnSemi silicon (one of the 10 chips). How many times do we need to say this!
Here is a pic of my setup. The resistor on the right is a 5K pullup on P59. There is an RGB LED on the left. My PropPlug also provides 5V from the USB.
With this setup TAQOZ will read the FLASH correctly unless I initialise the SD card using the ROM Monitor.
Ah yes, I did look for that information but didn't find it before posting.
Well, if someone is designing a system where access to both is important, and they are concerned about the contention current, they may need to include the tri-state buffer and control it from a 'non-boot' pin, or set up an entirely new set of pins for a storage only SD card as was suggested during the quad SPI discussions.
Cluso, I had not seen anyone say specifically that they had tested the specific situation David Betz was asking about (and clearly he had not, since he was still asking), so it wasn't clear and you needed to say it clearly once more.
The picture says nothing, btw. It's the specific access order/situation that mattered.
No. As I said, if there is a pull-up on P59, accessing the SD is skipped, and everything is fine.
That's why it taken a while to discover this.
IMHO, I think this was quite clear that this is the result of testing, not theoretical.
As usual, the thread has become polluted rather than just waiting for the solution
As I said, I will look at my fixes I've used in P1 and test that on P2. The SD card is supposed to release the DO pin but it has to be forced to do it.
SPI Flash boots with SD in. SD boots with Flash in. But if SD is accessed with a card in it will lock out Flash due to data output contention.The workaround is fixed using a resistor.
Actually now that SPI flash is known to boot with SD in, do we also know the time it takes for boot the P2 from flash now? I know it's unrelated to this topic directly but I'm just curious to know if it all is working okay. Assume a full 512k image usage.
Actually now that SPI flash is known to boot with SD in, do we also know the time it takes for boot the P2 from flash now? I know it's unrelated to this topic directly but I'm just curious to know if it all is working okay. Assume a full 512k image usage.
The SPI Flash still uses a signature and 2nd stage loader which is why I was asking elsewhere if we could also have the option of simply telling the bootloader what kind of system we've got so that it doesn't need what I consider a extra level of complication. I can load a full 512kB in under 200ms once I can switch in the PLL with a known.
BTW - regarding theory vs practice, opinions vs facts is the reason my very first line of this thread started off by saying:
Starting a new thread for this particular problem - hopefully it won't get buried with guesses and question after question. We just need solutions from those who can test this out
Comments
Update: Actually now I think I am remembering wrong and the only way to return to SD mode is actually a power cycle. So no use.
His comments suggest there is some possible SW/BUS fix, but less clear is if that would resolve the separate issue David Betz mentions ?
The anti-contention resistor sounds useful to have in any case.
We added the resistor today to the P2 Eval board. The board will be done today, but we are a week out on building them.
The C3 uses a shift register, or maybe a counter and demux to generate the CS. Maybe the CS was pulsed for the SD card, and it got into a state that interfered with other SPI devices.
Purely an SD card issue, that's how they operate in SPI mode with the output enabled. The C3 used a really awkward method of SPI bus CS that didn't seem to take into account just how awkward that would be in software. I'm glad that didn't repeat that method on other boards.
The SD card and SPI Flash can co-exist on the same 4 I/O we have them on now as long as we decouple the SD data out through a resistor. There is not an ongoing issue with current draw since the SPI Flash floats its data out when its chip select goes inactive. The current draw through the resistor only occurs when the SPI Flash is outputting a low when it is being read. I am going to try some higher values at 30MHz SPI bus rates to confirm that all is good.
If there is no SD card, obviously no problem.
If there is an SD card, and there is NO pullup on P59, the boot ROM will attempt to read from the SD card. BINGO, DO is made an output. I have seen this before on P1, and fixed it in code by giving it some clocks. I just need to search the code for the fix - I documented it on the various SD card drivers. I share all the pins on my RamBlade with SRAM so the fix works.
In reality, if there is an SD card, and you want to boot from it, then code should be loaded and this code can supply the fix for the first silicon. Currently the workaround is to power down if you also want to access the FLASH as well as the SD card ie both cannot be accessed in the same boot.
If there is an SD card, and there is a pullup on P59, the boot ROM DOES NOT TRY THE SD CARD, so everything is fine until you access the SD card. Thereafter (for now) the FLASH doesn't work unless there is a serial resistor in play from the SD card.
Cluso99, it would be great if, when your in-ROM booter attempts to boot SD, but fails for any reason, it would issue whatever command sequence gets it to stop driving DO.
Have you actually tested booting from SPI flash with an SD card plugged in but not initialized in any way? You keep saying "the ROM does x" but have you actually tested it?
There may be an issue trying to do that when the SD card (not in SPI mode) interferes with the SPI flash access. So please, stop saying what you think will happen, and actually test it.
So no matter how many times now and in the past we have tested this and I even post terminal shots, nobody actually pays heed to the answer? Seems like everyone loves having a problem to discuss without really worrying about the solution or workaround.
SPI Flash boots with SD in. SD boots with Flash in. But if SD is accessed with a card in it will lock out Flash due to data output contention.The workaround is fixed using a resistor.
There is no problem with having these two devices actively sharing the same pins as long as we use a resistor.
There is no command sequence that releases the DATA OUT line once the card has been initialized into SPI mode. Only power cycling will release the data out. While there is a CMD7 with address 0 that will release the DAT line, it cannot be used in SPI mode.
As Peter said, these are actual results with a real P2D2 and OnSemi silicon (one of the 10 chips). How many times do we need to say this!
Here is a pic of my setup. The resistor on the right is a 5K pullup on P59. There is an RGB LED on the left. My PropPlug also provides 5V from the USB.
With this setup TAQOZ will read the FLASH correctly unless I initialise the SD card using the ROM Monitor.
What if you have both an SD card and a flash?
I was still wondering about it like Roy was, though.
So, thank you for resolutely summarizing the situation.
And for anyone still worried that the contention current is going to be 'too high', there's the option of fitting a tri-state buffer between the SD card and DO, gated by CS:
https://dorkbotpdx.org/blog/paul/better_spi_bus_design_in_3_steps
But on the P2, SD CS is also SPI CLK.
Ah yes, I did look for that information but didn't find it before posting.
Well, if someone is designing a system where access to both is important, and they are concerned about the contention current, they may need to include the tri-state buffer and control it from a 'non-boot' pin, or set up an entirely new set of pins for a storage only SD card as was suggested during the quad SPI discussions.
The picture says nothing, btw. It's the specific access order/situation that mattered.
IMHO, I think this was quite clear that this is the result of testing, not theoretical.
As usual, the thread has become polluted rather than just waiting for the solution
As I said, I will look at my fixes I've used in P1 and test that on P2. The SD card is supposed to release the DO pin but it has to be forced to do it.
Well, this isn't relevant to just the eval boards, but I don't disagree on how unlikely this is to cause a problem.
I was actually trying to head further concern off at the pass.
Actually now that SPI flash is known to boot with SD in, do we also know the time it takes for boot the P2 from flash now? I know it's unrelated to this topic directly but I'm just curious to know if it all is working okay. Assume a full 512k image usage.
So boot time depends on...
The clock frequency
The length loaded
And the first stage loader code
It's similar to the SD concept although SD is slower.
Have not done any timing for FLASH. To get the best performance we will need the first stage loader.
The SPI Flash still uses a signature and 2nd stage loader which is why I was asking elsewhere if we could also have the option of simply telling the bootloader what kind of system we've got so that it doesn't need what I consider a extra level of complication. I can load a full 512kB in under 200ms once I can switch in the PLL with a known.
BTW - regarding theory vs practice, opinions vs facts is the reason my very first line of this thread started off by saying:
Starting a new thread for this particular problem - hopefully it won't get buried with guesses and question after question. We just need solutions from those who can test this out