Boot issue accessing SPI Flash after SD access

Peter Jakacki · 2018-11-06 13:50

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

I've noticed a problem in the past with trying to access the SPI Flash after the SD card has been initialized and read. It seems that the Flash doesn't respond, it just comes back with a constant high. Turns out that once the SD card has been initialized into SPI mode that the D0 pin stays enabled, and usually high because of the response code. Looking at P58 on the scope shows that the SPI Flash is responding and trying to pull P58 low but only as far as about half VIO. For the moment I've put a 22R in series with the SD data out to P58 as a workaround so that the SPI Flash can just override the high enough for it to work but 47R would be better and I should be able to use the series termination resistor I have in my P2D2 revision for this purpose.

There doesn't seem to be any command in the SD specs to disable the DO from the SD card although I have tried issuing extra clocks with and without the SD CE asserted along with its DI set high. It seems that as soon as it responds to the initial CMD0 that it makes DO a permanent output. Normally SPI chips always float their D0 pin once CE goes high.

To test this out on your P2 just put an SD card into your P2D2 without a boot file and then enter TAQOZ and type .SF (print Serial Flash) which will list the JEDEC and manufactuer IDs and serial number of the Flash chip. Without an SD card in there it will respond with something similar to this:

TAQOZ# .SF $EF40_1400 $270B_7025_$E666_5893 ok

But if you leave the card in at boot it will return with FFs instead. However you can pull the card out and put it back in again and the SPI Flash will respond again. Do anything with the SD card or even 0 0 CMD a couple of times and it will lock the D0 pin up again.

Prior to my workaround:

TAQOZ# 0 0 CMD . 255 ok
TAQOZ# .SF $EF40_1400 $270B_7025_$E666_5893 ok
TAQOZ# 0 0 CMD . 1 ok
TAQOZ# .SF $FFFF_FFFF $FFFF_FFFF_$FFFF_FFFF ok

You can see that the Flash still responded even after the first CMD0 but once the card responds then the Flash is overridden.

Rayman · 2018-11-06 14:10

This behavior has been discussed in P1 forum for years...

Here's where Andy suggests putting a 1K resistor in series:
http://forums.parallax.com/discussion/122588/ethernet-and-sd-card-on-same-spi-buss

Cluso says you can just give 16 clocks, but I don't think that always works:
https://forums.parallax.com/discussion/117409/sharing-sd-spi-pins-without-unmounting

He says Lonesock/rokicki also found a solution. Might want to see what they did, if you can find it...

I think it's best to just not share the SD bus, if possible...

Peter Jakacki · 2018-11-06 14:21

We have boot Flash and SD sharing the same 4 I/O pins so there is no easy way around it other than adding in a series resistor but given the frequency I run the SD at it needs a small series resistor but 1k is far too large. This is not a case of clocking the pin since it is very easy to try all this out in TAQOZ which I have, to no avail.

Here's a tiny snippet of me clocking the SD while CE is active but of course I also had CE inactive as well.

TAQOZ# 59 HIGH 60 LOW 1200 FOR 61 LOW 61 HIGH NEXT 60 HIGH  ok
TAQOZ# .SF $FFFF_FFFF $FFFF_FFFF_$FFFF_FFFF ok

cgracey · 2018-11-06 14:32

Our ROM code involves these things. Are we safe the way we are? Should we be adding a series resistor to the eval board?

Peter Jakacki · 2018-11-06 14:41

cgracey wrote: »

Our ROM code involves these things. Are we safe the way we are? Should we be adding a series resistor to the eval board?

I have series termination in SD lines so I am using that to isolate the SDDO from the SPIDO line but certainly a series resistor should be added at least with the best value to be determined although I am looking at a value of between 33 and 47R. If the value is too high then the SDDO would be filtered at higher speeds.

Rayman · 2018-11-06 14:52

You could also just put in a jumper to select SD or flash, but not both.
That might be the best way actually...

Perhaps that jumper would just move the SD MISO to a different P2 I/O pin..

cgracey · 2018-11-06 14:54

Peter Jakacki wrote: »

cgracey wrote: »

Our ROM code involves these things. Are we safe the way we are? Should we be adding a series resistor to the eval board?

I have series termination in SD lines so I am using that to isolate the SDDO from the SPIDO line but certainly a series resistor should be added at least with the best value to be determined although I am looking at a value of between 33 and 47R. If the value is too high then the SDDO would be filtered at higher speeds.

It sounds like the SD card gets terminally hung up in output mode after being used in SPI mode. Is this so?

Nothing short of cycling its power pulls it out of this mode?

Peter Jakacki · 2018-11-06 15:04

Yes, once it is in SPI mode then the DO pin is permanently an output. I've tried different commands at the interactive level but no joy. I was going to add a transistor to control the SD power but I don't won't to tie up another I/O. The resistor is the quick and easy fix and it just looks like a heavy pullup to the Flash chip's DO.

cgracey · 2018-11-06 15:14

Peter Jakacki wrote: »

Yes, once it is in SPI mode then the DO pin is permanently an output. I've tried different commands at the interactive level but no joy. I was going to add a transistor to control the SD power but I don't won't to tie up another I/O. The resistor is the quick and easy fix and it just looks like a heavy pullup to the Flash chip's DO.

Seems like a tall order to expect the SPI DO to overcome such a pull-up. And this situation persists until the SD is unplugged.

It seems we would need a 220 Ohm resistor for the SPI flash to be able to reliably communicate after the SD card holds its DO high.

cgracey · 2018-11-06 15:20

And do all SD cards behave this way, or just some?

David Betz · 2018-11-06 15:25

SD cards are a pain anyway when you try to share pins with other SPI devices. You always have to remember switch the SD card to SPI mode even if you aren't booting from it. I suppose you already have this handled in the ROM but 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.

cgracey · 2018-11-06 15:29

You mean that we should preemptively configure the SD card before attempting to talk to the SPI flash, if both are present? What a pain. Sounds like SPI versus SD needs to be an either-or scenario.

kwinn · 2018-11-06 15:32

Peter Jakacki wrote: »

Yes, once it is in SPI mode then the DO pin is permanently an output. I've tried different commands at the interactive level but no joy. I was going to add a transistor to control the SD power but I don't won't to tie up another I/O. The resistor is the quick and easy fix and it just looks like a heavy pullup to the Flash chip's DO.

If the series resistor is a problem would adding a transistor that is enabled by the SD CE signal on the SD DO line be a practical solution?

cgracey · 2018-11-06 15:38

kwinn wrote: »

Peter Jakacki wrote: »

Yes, once it is in SPI mode then the DO pin is permanently an output. I've tried different commands at the interactive level but no joy. I was going to add a transistor to control the SD power but I don't won't to tie up another I/O. The resistor is the quick and easy fix and it just looks like a heavy pullup to the Flash chip's DO.

If the series resistor is a problem would adding a transistor that is enabled by the SD CE signal on the SD DO line be a practical solution?

How would the transistor be hooked up?

Rayman · 2018-11-06 16:05

You might want to take a look at the FSRW "release" command in the code at the end of this thread:
https://forums.parallax.com/discussion/117409/sharing-sd-spi-pins-without-unmounting

cgracey · 2018-11-06 16:20

Rayman wrote: »

You might want to take a look at the FSRW "release" command in the code at the end of this thread:
https://forums.parallax.com/discussion/117409/sharing-sd-spi-pins-without-unmounting

Thanks for finding that, Rayman.

It looks like Lonesock did something to get over this SD DO problem:

https://forums.parallax.com/discussion/comment/855848/#Comment_855848

Rayman · 2018-11-06 17:07

I just looked at the code and it might not help...
Looks like it just deselects and sends some clocks:

release_DO
        ' we're already out of multiblock mode, so
        ' deselect the card and send out some clocks
        or outa,maskCS
        call #in8
        call #in8
        ' if you are using pull-up resistors, and need all
        ' lines tristated, then uncomment the following line.
        ' for Cluso99
        'mov dira,#0
release_DO_ret
        ret

Unless, maybe it has something to do with "multiblock mode"?

jmg · 2018-11-06 18:38

cgracey wrote: »

Peter Jakacki wrote: »

Yes, once it is in SPI mode then the DO pin is permanently an output. I've tried different commands at the interactive level but no joy. I was going to add a transistor to control the SD power but I don't won't to tie up another I/O. The resistor is the quick and easy fix and it just looks like a heavy pullup to the Flash chip's DO.

Seems like a tall order to expect the SPI DO to overcome such a pull-up. And this situation persists until the SD is unplugged.

It seems we would need a 220 Ohm resistor for the SPI flash to be able to reliably communicate after the SD card holds its DO high.

Yes, if the SD-DO cannot be disabled, then you will need some form of isolation resistor, of a suitable value.

220 Ohms and 10pF is a Tau of 2.2ns, but will add ~13mA of contention current. (Tau is time to 63% of Vcc, so is past the CMOS threshold within that time)
330 ohms is 3.3ns, and adds ~9mA of contention current
390 ohms is 3.9ns and adds ~ 8mA of contention current (etc, 470R is 4.7ns and 6.7mA)

What MHz do users expect SD cards to run up to ?

Another approach is a R//C, ( eg 1k//27pF) which allows higher resistors to be used, but the P2 sees a higher pin capacitance.

David Betz wrote: »

SD cards are a pain anyway when you try to share pins with other SPI devices. You always have to remember switch the SD card to SPI mode even if you aren't booting from it. I suppose you already have this handled in the ROM but 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.

Is this the same effect, or is there something else to worry about too ? Even after reset, & CE=H, can SD card actively drive some pins ?
Does that make the config-resistors a lottery, brand and time dependent ?

jmg · 2018-11-06 19:06

google finds this
https://electronics.stackexchange.com/questions/313361/what-is-preventing-using-a-can-bus-chip-and-sd-card-on-a-shared-spi-interface
which links to http://elm-chan.org/docs/mmc/mmc_e.html

and that claims (with waveforms) that a clock edge is needed after CS=H, to make float stick, but I think Peter has already done this ?

Hmm.. it looks like CS is not really always CS on SD cards, only once it is in SPI mode, is that pin CS, but in other modes it is CD/DAT3.
I see mention of DO becomes CMD I/O Command in and out

Rayman · 2018-11-06 19:41

I see cluso mentioned a lot in these threads...
You might ask him about this...

kwinn · 2018-11-06 19:50

cgracey wrote: »

kwinn wrote: »

Peter Jakacki wrote: »

Yes, once it is in SPI mode then the DO pin is permanently an output. I've tried different commands at the interactive level but no joy. I was going to add a transistor to control the SD power but I don't won't to tie up another I/O. The resistor is the quick and easy fix and it just looks like a heavy pullup to the Flash chip's DO.

If the series resistor is a problem would adding a transistor that is enabled by the SD CE signal on the SD DO line be a practical solution?

How would the transistor be hooked up?

The initial pre-caffein thought was source to DO, gate to CE, and drain to the P2 input pin, but a bit later I realized that would not work. No way for the SD data out signal to pull the line low. It really needs an analog switch unless D0 can be floated via software commands.

After searching the internet and looking at several blogs, forum posts, and articles the following link seemed to have the best description of how to access multiple devices on an SPI bus. The information provided there also agreed with information gleaned from the rest of the sites I visited.

http://elm-chan.org/docs/mmc/mmc_e.html see Consideration on Multi-slave Configuration

Cluso99 · 2018-11-06 20:12

I share the SD pins on many of my P1 boards. I have had to patch all the SD drivers to overcome this problem. Seems I missed this in the current ROM code.
Peter and I discussed this yesterday evening when we discovered it.
I haven't had time to check my P1 code yet. It's solvable but I just need to check the sequence so we can ensure the ROM gets fixed for the next revision. BTW we can use code on the SD card to fix this if we need to. But first I need to work out the fix. I am working today so will not get to it today.

David Betz · 2018-11-06 20:18

Cluso99 wrote: »

I share the SD pins on many of my P1 boards. I have had to patch all the SD drivers to overcome this problem. Seems I missed this in the current ROM code.
Peter and I discussed this yesterday evening when we discovered it.
I haven't had time to check my P1 code yet. It's solvable but I just need to check the sequence so we can ensure the ROM gets fixed for the next revision. BTW we can use code on the SD card to fix this if we need to. But first I need to work out the fix. I am working today so will not get to it today.

The problem that I ran into occurred only when I had an SD card plugged in but I wasn't using it. Then other SPI devices that shared the same pins would fail to work if I didn't first initialize the SD card. Maybe it was a bug in my code but it seemed like the SD card being present but not in SPI mode was a problem.

Cluso99 · 2018-11-06 20:22

No. The problem is when the SD card has been fully initialised (mounted) in SPI mode. The DO becomes an SD driven output.
Currently you need to remove power for the SD to release DO but as I said I have fixed this in the SD drivers before to force the SD card to release DO.
If you have a pull-up on P59 then the boot ROM will not boot from SD and DO remains tristate.

David Betz · 2018-11-06 20:26

Cluso99 wrote: »

No. The problem is when the SD card has been fully initialised (mounted) in SPI mode. The DO becomes an SD driven output.
Currently you need to remove power for the SD to release DO but as I said I have fixed this in the SD drivers before to force the SD card to release DO.
If you have a pull-up on P59 then the boot ROM will not boot from SD and DO remains tristate.

I assume your boot ROM code always tries to initialize the SD card and if it finds one it puts it into SPI mode. Is that correct? And this happens even if it doesn't end up booting from the SD card? I guess what I'm trying to figure out is if I can design a board that boots from flash but has an SD socket that might have a card in it during boot. Will that work?

Cluso99 · 2018-11-06 20:29

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.

David Betz · 2018-11-06 20:33

Is the exact sequence of operations during boot defined somewhere?

Cluso99 · 2018-11-06 20:39

At the end of Chip's P2 documents IIRC.

Or you can check the boot ROM code source.

jmg · 2018-11-06 22:18

Cluso99 wrote: »

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.

That's not quite covering David's specific question, which was an inserted but not-yet-touched SD card, was seen to be disturbing his SPI.
ie their power up state, is maybe not 100% reliable ?

David Betz wrote: »

.. 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 ?

Cluso99 wrote: »

... I have fixed this in the SD drivers before to force the SD card to release DO.

How complex is that step, and can it be safely done before SPI Flash access, as a safety net ?
P2 could even check it can drive DO, with a light drive mode ?

David Betz · 2018-11-06 22:22

David Betz wrote: »

.. 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.

Peter Jakacki · 2018-11-06 22:32

Maybe the old MMC/SD cards had a release command but near in mind we use SDHC as well as SDXC, both being the most common. I can't find anything in the specs about this and I've tried various commands and extra clocks anyway. I will spend a bit more time today checking this but even if there were a command it would still be good to have a resistor in the data out line.

@"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.

Boot issue accessing SPI Flash after SD access

Comments