I still think the best solution is to just put one thing there and don't try to share the pins with SD card.
Sounds like it will work that way every time.
But for testing various boot options, sounds like the resistor will work.
To say "best solution" would not be correct because that flies in the face of the facts that these two components can co-exist on the same 4 I/O which is especially important for flexible yet minimum boot configurations. All it needs is a resistor as opposed to trying to use another 4 I/O and not gaining any advantage. I brought up this issue because Chip is trying to get the eval board finished and out to all those who requested them and I'm sure that everyone would expect and want the one or both boot options working, both during boot, and after.
People over in the P1 forum have had difficulty for years trying to share SD bus...
I think it's just a lot simpler not to do it...
If none of us could get it working properly I might agree that it would be a "lot simpler" not to do it. But when it is working properly after finding an extremely simply resistor solution, then how could not doing it be a lot simpler? This sounds more like those people that I try to help that refuse help because "it is too complicated" when there is nothing for them to do but say yes so that I can press a button. Wouldn't you just agree that despite the difficulty that some may have had in the past, that using a resistor is just plain and simple, and it works?
FWIW, I am using this and I can switch between them easily and reliably after boot running at 300MHz. Anyway, the eval board has both together as does the P2D2.
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.
Thank you for your answer. I guess there was something wrong with the code I was using on the C3 that cause it to fail. I'm glad there isn't really an issue here.
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.
Thank you for your answer. I guess there was something wrong with the code I was using on the C3 that cause it to fail. I'm glad there isn't really an issue here.
Do you still have the C3 setup ? - It could be useful to confirm that the added resistor fix does actually solve your problem, which you could do with a failing system, then add the resistor ?
With P2 Silicon, testing can now cover Power supply ramping, and brownout scenarios, which could not really be done in FPGA.
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.
Thank you for your answer. I guess there was something wrong with the code I was using on the C3 that cause it to fail. I'm glad there isn't really an issue here.
Do you still have the C3 setup ? - It could be useful to confirm that the added resistor fix does actually solve your problem, which you could do with a failing system, then add the resistor ?
With P2 Silicon, testing can now cover Power supply ramping, and brownout scenarios, which could not really be done in FPGA.
That would involve modifying the C3 board itself since the SD card and SPI flash are onboard.
Here is the fix for forcing the SD card to release the bus (DO output)...
'' Reset SD Card for DO bug
CON
_CLOCKFREQ = 30_000_000 ' rcmax
delay5us = _clockfreq / 200_000 ' 5us
spi_cs = 61 ' pin SPI memory select (also sd_ck)
spi_ck = 60 ' pin SPI memory clock (also sd_cs)
spi_di = 59 ' pin SPI memory data in (also sd_di)
spi_do = 58 ' pin SPI memory data out (also sd_do)
DAT
orgh 0
org 0
entry or outb, masksd ' SD CK=CS=DI=preset"1"
or dirb, masksd ' SD CK=CS=DI=outputs
mov ctr1, #(96*2)
.count waitx ##delay5us
outnot #spi_cs ' sd_ck 0->1->0
djnz ctr1, #.count
waitx ##delay5us
andn dirb, masksd
here jmp #here
masksd long %1110 << 26
ctr1 long 0
It will be easy to implement as this is the sequence already used to initialise the SD card. I just need to make it a standalone subroutine so I can call it.
Then, if the SD boot fails, or after a file has been loaded and optionally run, I will "reset" the SD card so it relinquishes the bus (DO).
Any code wanting to re-use the SD card can easily re-initialise the SD card.
It is just a slight change over how the SD is being used now from the ROM.
FWIW it is only a problem in the current ROM if you have both FLASH and SD Card fitted, and you initialise the SD card.
From then on, you cannot access the FLASH unless you reset the SD card.
You can run the above code as a file from the SD card either from the Monitor or TAQOZ.
I only have new Sandisk Ultras or plain Sandisk cards, they both exhibit the same behaviour.
I used a 3.3M pulldown on P58 just so I could see whether the line was floating or being driven. If I take the SD clock low with the CS and DI high I can see the line gradually floating low.
60 HIGH 59 HIGH 61 LOW
But hold on, that's not the end of the story because we need to access Flash. Now as I access the serial Flash the contention problem comes back. I will examine this in minute detail after dinner but the series resistor is at least allowing me to use both devices.
But hold on, that's not the end of the story because we need to access Flash. Now as I access the serial Flash the contention problem comes back. I will examine this in minute detail after dinner but the series resistor is at least allowing me to use both devices.
So the SD card is being floated, but then later enabled again ?
Maybe you and Cluso99 can carefully run the same test cases, as he seem to be checking SD->float, whilst you run SD then FLASH ?
Perhaps the fast pulsing of CE on SD (during flash load), enables some SD test mode ? It would not be the first time chip designers have added secondary functions to pins...
Thanks for your efforts Peter and Ray. We're stuck in analog land but at some stage will at least be able to confirm / check with different cards and flash chips.
We make up small dip-8 modules so the flash can be swapped over. Perhaps these will come in handy
In my sample code above, I removed both WAITX instructions, and I bumped the clock to 200MHz. Still works fine on my no-name Mizo 8GB microSD bought on eBay from Europe.
BTW I tried booting the SANDISK 16GB Ultra. It doesn't boot so maybe it isn't getting to the DO problem. I need more testing to find why it doesn't boot but I have to work today.
I'm back at it again and I've gone over some of the older specs that covered SPI timing etc and the output is supposed to float after additional clocks BUT...... the problem is accessing Flash and what happens then.
My test setup:
I connected the SD/FLASH Dout to two 3.3M resistors tied to 3.3V and ground so that the output will float to half supply thus making it easy to identify when looking at the scope. The Dout from the SD is via a 240R resistor so that the serial Flash can still operate but it can only drive the Dout down to 0.5V if the SD is trying to pull it high.
I then connected all 4 I/O to the scope and after ascertaining that SD output is floating I then try a very simple serial Flash operation by checking the status register. But to make sure the signal is relatively clean with the long leads I ran out to the scope I slow the P2 down to 40 MHz for the test with:
40 @MHZ SF? DROP 180 @MHZ
and this is what I got:
So even though the SD Dout is floating it seems that as soon as the Flash CE is asserted while the Flash clock is low, that the Dout back to the P2 goes immediately high, whether this is the Flash or the SD I'm not certain but it seems to be the SD. Then after 8 Flash clocks the Flash responds with a low which is in contention with what must be a high from the SD via the 240R.
This contention remains during Flash access and in the last two divisions of the scope when the Flash clock (SD CE) has returned high I then give the SD clock line a pulse and from the time the clock goes low in the last division the Dout is floating although it takes about 60us to settle back at 1/2 VIO as we saw at the start of the trace.
So it looks like the SD Dout is activated because the SD sees both an active CE and a high to low clock edge (the Flash CE going low). I will look at this in more detail later but suffice to say that the SD code is working correctly but Flash access after an SD has been initialized into SPI mode seems to make the SD immediately assert its Dout when the SD gets a high to low clock edge and even though the SD CE is off and on while the Flash is clocking, the SD won't release its Dout until it sees a clock high to low while it is disabled.
Maybe I could explain it better but basically the SD Dout on SDHC cards becomes active immediately it receives a high low clock while enabled and only releases when it receives a high low clock when disabled. So accessing Flash will always cause the SD card to assert Dout again.
Maybe I could explain it better but basically the SD Dout on SDHC cards becomes active immediately it receives a high low clock while enabled and only releases when it receives a high low clock when disabled. So accessing Flash will always cause the SD card to assert Dout again.
That seems to assert DO.OE on a falling edge, when CS=L, and releases DO.OE on the rising edge when CS=H
ie a very simple, clocked link from CS to DO.OE, but a little unusual in that =\_ is to enable, and _/= is to release.
I wonder what it does if the clk goes hi before CS=1, does it release on the first edge (now =\_), or does it wait for _/= ?
It does indicate a 240 R anti-contention fix is mandatory, but you can idle in a way that avoids contentions.
I'm happy with having a 240R in there anyway but I am modifying my Flash routines to have the clock idle high so that the SD doesn't assert itself. I did a quick test and even though the data coming back from the Flash is off a bit I can already see that the SD is happy and doesn't contend with the Flash.
... I did a quick test and even though the data coming back from the Flash is off a bit I can already see that the SD is happy and doesn't contend with the Flash.
I'm not quite following ? If flash is selecting some SPI mode, I think that is done on the CS falling edge, and that means you can idle in best SD mode, but change CLK to flash-best before CS changes, so it should be possible to get no change as in 'the data coming back from the Flash is off a bit' ?
Here's an update with timing that works although I will still use a resistor. The trick is to make sure that the SD data out (SDDO) floats after active operations and then to prevent the SD activating it again when SPI Flash starts operation since a low clock for the Flash and its CE going low can activate the SDDO. So the clock is normally idling low during any transfer but while CE is high so is the clock. Then the clock idles low just after CE goes low.
Here's a timing capture where I slowed down the CPU to 20MHz for a clean picture and so I could also see where the bias network would pull a floating DO to half VIO. Straight after an SD access I issue a Flash command that reads its JEDEC ID just so I can see the data out swinging high and low.
You can see that at no time is there any contention on DO and the Flash activates its DO after the first 8 clocks of the instruction. The DO line is set to 500mV/div just so we can see how well it swings and before with contention and the resistor the DO line would only pull down to just over 500mV. Checking that low level now it is around 80mV in fact.
Great detective work there Peter. I recall I sort of had a similar issue once when sharing the I2C EEPROM and an SD card on 4 pins of a P1, and had to be very careful to keep clock and SD CS transitions sequenced right so one access type would not mess up the other and vice versa, although being I2C it had different pin mappings to this and the SDA was bidirectional, while you have two devices that can potentially drive the same pin. What you just found with your P2 board should hopefully work well with care during flash and SD accesses whenever they are issued exclusive to one another. Having that resistor there is certainly good for other people's code in cases where they may not be aware or just forget to follow the same rules you do.
At the risk of beating a dead horse, this also works if you want to boot from SPI flash before ever accessing the SD card, right?
Four I/O are shared by both the SPI Flash boot device and the SD boot device. You can have either or both connected.
The pin assignments are as follows:
spi_cs = 61 'SPI memory select
sd_ck = 61 'SD clock
spi_ck = 60 'SPI memory clock
sd_cs = 60 'SD chip select
spi_di = 59 'SPI memory data in
sd_di = 59 'SD data in
spi_do = 58 'SPI memory data out
sd_do = 58 'SD data out
Accessing Flash before SD at boot is NOT a problem.
Accessing SD after Flash is NOT a problem.
Accessing Flash after SD has been initialised is a PROBLEM
The problem is that once an SD card has been initialised into SPI mode is that its Dout pin does not float simply by taking its chip select high like any other normal SPI chip. The SD needs extra clocks to release the Dout pin so that the Flash can drive this line without contention.
By way of comparison the Flash chip is a regular SPI bus chip that floats its Dout as soon as its chip select goes high and doesn't come back on again until it is selected and after it has received a command (look at last scope capture at timing division 3.6 after the first SPI clocks).
By way of comparison the SD chip will activate its data out pin as soon as it is selected and as soon as it receives any clock edge and that data out stays enabled until it is clocked off after being deselected.
Now even though we float the SD data out with extra clocks the trouble is that if the Flash clock is low and then the the Flash chip select is switching either on or off, is that this looks like an SD enable and an SD clock edge which as mentioned in the previous paragraph will cause the SD to turn on its data out pin while we are trying to talk to the SPI Flash. Bad bad bad!
The simple and safe workaround is to current limit the SD data out with a 220R resistor so that the Flash can drive the data out, albeit with contention current of around 10ma whenever the two signals are opposite.
The solution in software is to make sure the clock for the Flash idles high (deselects the SD) in between and prior to Flash accesses and only switch the Flash chip select while the Flash clock is high.
SO: Flash clock high and a Flash CE edge will ensure that the SD's sees a "disconnect clock" and floats its data out.
NOTE: I use "MODE 0" SPI mode where the clock "idles" low since this works with the SD card.
At the risk of beating a dead horse, this also works if you want to boot from SPI flash before ever accessing the SD card, right?
To cover all reset/brownout cases, it would always be a good idea to include the 240R contention resistor.
I think this 'somewhat i2c like' fussiness over the Clock state during CS=H, is related to the Mode 0 / Mode 3 SPI support, and that this dual-bus use is not something the SD suppliers will be testing.
It does seem that CS=H is not the async state reset one might expect.
In the mode where clock idles low, (mode 0) the device has to output some data ready for the next edge, so it drives when CS=L, in mode 3, there is a falling edge that will arrive before data is needed, so that can be used to enable TS drive.
A purist might say a port should not drive until a valid command has been sent, but even there, there are 'tail' situations, like reset during SD load, and brown-out chances where it can be mid-state.
Originally, it was assumed that if an SD was present, then FLASH would not be present. At the last minute, the SD Boot was changed from a complete stop if valid code was not found.
The problem only showed because after the SD was accessed (with no valid boot code), Peter went into TAQOZ and tried to load more code from the FLASH. But it didn't work. I would never have thought to try this as I was concentrating on the SD card once code had booted, or bypassing the SD altogether if I didn't want to boot from SD (using the P59 pullup).
Thanks for tracking down the actual specifics of the problem Peter.
Comments
Sounds like it will work that way every time.
But for testing various boot options, sounds like the resistor will work.
To say "best solution" would not be correct because that flies in the face of the facts that these two components can co-exist on the same 4 I/O which is especially important for flexible yet minimum boot configurations. All it needs is a resistor as opposed to trying to use another 4 I/O and not gaining any advantage. I brought up this issue because Chip is trying to get the eval board finished and out to all those who requested them and I'm sure that everyone would expect and want the one or both boot options working, both during boot, and after.
I think it's just a lot simpler not to do it...
If none of us could get it working properly I might agree that it would be a "lot simpler" not to do it. But when it is working properly after finding an extremely simply resistor solution, then how could not doing it be a lot simpler? This sounds more like those people that I try to help that refuse help because "it is too complicated" when there is nothing for them to do but say yes so that I can press a button. Wouldn't you just agree that despite the difficulty that some may have had in the past, that using a resistor is just plain and simple, and it works?
FWIW, I am using this and I can switch between them easily and reliably after boot running at 300MHz. Anyway, the eval board has both together as does the P2D2.
Do you still have the C3 setup ? - It could be useful to confirm that the added resistor fix does actually solve your problem, which you could do with a failing system, then add the resistor ?
With P2 Silicon, testing can now cover Power supply ramping, and brownout scenarios, which could not really be done in FPGA.
'' Reset SD Card for DO bug CON _CLOCKFREQ = 30_000_000 ' rcmax delay5us = _clockfreq / 200_000 ' 5us spi_cs = 61 ' pin SPI memory select (also sd_ck) spi_ck = 60 ' pin SPI memory clock (also sd_cs) spi_di = 59 ' pin SPI memory data in (also sd_di) spi_do = 58 ' pin SPI memory data out (also sd_do) DAT orgh 0 org 0 entry or outb, masksd ' SD CK=CS=DI=preset"1" or dirb, masksd ' SD CK=CS=DI=outputs mov ctr1, #(96*2) .count waitx ##delay5us outnot #spi_cs ' sd_ck 0->1->0 djnz ctr1, #.count waitx ##delay5us andn dirb, masksd here jmp #here masksd long %1110 << 26 ctr1 long 0It will be easy to implement as this is the sequence already used to initialise the SD card. I just need to make it a standalone subroutine so I can call it.Then, if the SD boot fails, or after a file has been loaded and optionally run, I will "reset" the SD card so it relinquishes the bus (DO).
Any code wanting to re-use the SD card can easily re-initialise the SD card.
It is just a slight change over how the SD is being used now from the ROM.
FWIW it is only a problem in the current ROM if you have both FLASH and SD Card fitted, and you initialise the SD card.
From then on, you cannot access the FLASH unless you reset the SD card.
You can run the above code as a file from the SD card either from the Monitor or TAQOZ.
So, you are saying that, in any case, this will get the SD card to release its DO?
I just tried a SanDisk 16GB Ultra (the smallest I can buy now) and it does not hold DO high at all. I haven't had time to try my 64GB SanDisk yet.
Interesting. Maybe newer cards quit doing this.
I used a 3.3M pulldown on P58 just so I could see whether the line was floating or being driven. If I take the SD clock low with the CS and DI high I can see the line gradually floating low.
But hold on, that's not the end of the story because we need to access Flash. Now as I access the serial Flash the contention problem comes back. I will examine this in minute detail after dinner but the series resistor is at least allowing me to use both devices.
So the SD card is being floated, but then later enabled again ?
Maybe you and Cluso99 can carefully run the same test cases, as he seem to be checking SD->float, whilst you run SD then FLASH ?
Perhaps the fast pulsing of CE on SD (during flash load), enables some SD test mode ? It would not be the first time chip designers have added secondary functions to pins...
We make up small dip-8 modules so the flash can be swapped over. Perhaps these will come in handy
BTW I tried booting the SANDISK 16GB Ultra. It doesn't boot
My test setup:
I connected the SD/FLASH Dout to two 3.3M resistors tied to 3.3V and ground so that the output will float to half supply thus making it easy to identify when looking at the scope. The Dout from the SD is via a 240R resistor so that the serial Flash can still operate but it can only drive the Dout down to 0.5V if the SD is trying to pull it high.
I then connected all 4 I/O to the scope and after ascertaining that SD output is floating I then try a very simple serial Flash operation by checking the status register. But to make sure the signal is relatively clean with the long leads I ran out to the scope I slow the P2 down to 40 MHz for the test with:
and this is what I got:
So even though the SD Dout is floating it seems that as soon as the Flash CE is asserted while the Flash clock is low, that the Dout back to the P2 goes immediately high, whether this is the Flash or the SD I'm not certain but it seems to be the SD. Then after 8 Flash clocks the Flash responds with a low which is in contention with what must be a high from the SD via the 240R.
This contention remains during Flash access and in the last two divisions of the scope when the Flash clock (SD CE) has returned high I then give the SD clock line a pulse and from the time the clock goes low in the last division the Dout is floating although it takes about 60us to settle back at 1/2 VIO as we saw at the start of the trace.
So it looks like the SD Dout is activated because the SD sees both an active CE and a high to low clock edge (the Flash CE going low). I will look at this in more detail later but suffice to say that the SD code is working correctly but Flash access after an SD has been initialized into SPI mode seems to make the SD immediately assert its Dout when the SD gets a high to low clock edge and even though the SD CE is off and on while the Flash is clocking, the SD won't release its Dout until it sees a clock high to low while it is disabled.
Maybe I could explain it better but basically the SD Dout on SDHC cards becomes active immediately it receives a high low clock while enabled and only releases when it receives a high low clock when disabled. So accessing Flash will always cause the SD card to assert Dout again.
That seems to assert DO.OE on a falling edge, when CS=L, and releases DO.OE on the rising edge when CS=H
ie a very simple, clocked link from CS to DO.OE, but a little unusual in that =\_ is to enable, and _/= is to release.
I wonder what it does if the clk goes hi before CS=1, does it release on the first edge (now =\_), or does it wait for _/= ?
It does indicate a 240 R anti-contention fix is mandatory, but you can idle in a way that avoids contentions.
Here's a timing capture where I slowed down the CPU to 20MHz for a clean picture and so I could also see where the bias network would pull a floating DO to half VIO. Straight after an SD access I issue a Flash command that reads its JEDEC ID just so I can see the data out swinging high and low.
You can see that at no time is there any contention on DO and the Flash activates its DO after the first 8 clocks of the instruction. The DO line is set to 500mV/div just so we can see how well it swings and before with contention and the resistor the DO line would only pull down to just over 500mV. Checking that low level now it is around 80mV in fact.
That should be easy to change in my code for the next ROM
Four I/O are shared by both the SPI Flash boot device and the SD boot device. You can have either or both connected.
The pin assignments are as follows:
Accessing Flash before SD at boot is NOT a problem.
Accessing SD after Flash is NOT a problem.
Accessing Flash after SD has been initialised is a PROBLEM
The problem is that once an SD card has been initialised into SPI mode is that its Dout pin does not float simply by taking its chip select high like any other normal SPI chip. The SD needs extra clocks to release the Dout pin so that the Flash can drive this line without contention.
By way of comparison the Flash chip is a regular SPI bus chip that floats its Dout as soon as its chip select goes high and doesn't come back on again until it is selected and after it has received a command (look at last scope capture at timing division 3.6 after the first SPI clocks).
By way of comparison the SD chip will activate its data out pin as soon as it is selected and as soon as it receives any clock edge and that data out stays enabled until it is clocked off after being deselected.
Now even though we float the SD data out with extra clocks the trouble is that if the Flash clock is low and then the the Flash chip select is switching either on or off, is that this looks like an SD enable and an SD clock edge which as mentioned in the previous paragraph will cause the SD to turn on its data out pin while we are trying to talk to the SPI Flash. Bad bad bad!
The simple and safe workaround is to current limit the SD data out with a 220R resistor so that the Flash can drive the data out, albeit with contention current of around 10ma whenever the two signals are opposite.
The solution in software is to make sure the clock for the Flash idles high (deselects the SD) in between and prior to Flash accesses and only switch the Flash chip select while the Flash clock is high.
SO: Flash clock high and a Flash CE edge will ensure that the SD's sees a "disconnect clock" and floats its data out.
NOTE: I use "MODE 0" SPI mode where the clock "idles" low since this works with the SD card.
To cover all reset/brownout cases, it would always be a good idea to include the 240R contention resistor.
I think this 'somewhat i2c like' fussiness over the Clock state during CS=H, is related to the Mode 0 / Mode 3 SPI support, and that this dual-bus use is not something the SD suppliers will be testing.
It does seem that CS=H is not the async state reset one might expect.
In the mode where clock idles low, (mode 0) the device has to output some data ready for the next edge, so it drives when CS=L, in mode 3, there is a falling edge that will arrive before data is needed, so that can be used to enable TS drive.
A purist might say a port should not drive until a valid command has been sent, but even there, there are 'tail' situations, like reset during SD load, and brown-out chances where it can be mid-state.
Originally, it was assumed that if an SD was present, then FLASH would not be present. At the last minute, the SD Boot was changed from a complete stop if valid code was not found.
The problem only showed because after the SD was accessed (with no valid boot code), Peter went into TAQOZ and tried to load more code from the FLASH. But it didn't work. I would never have thought to try this as I was concentrating on the SD card once code had booted, or bypassing the SD altogether if I didn't want to boot from SD (using the P59 pullup).
Thanks for tracking down the actual specifics of the problem Peter.