S/W SPI works, H/W SPI doesn't

[spamiam]

I got my disposable SD/MMC card back and I have it working properly. At the very least, I get valid results from card initialization commands.

To the best of my ability, the two interfaces are exact duplicates. One big difference is that the H/W bus must be shared, so the card loses /CS between card accesses, but on the S/W bus, the card never loses /CS until all operations are finished.

When I try to initialize the card with the H/W interface, all I ever read is zero.

One issue with interfacing the card is that it runs at 3.3V. Therefore the MISO pin only sees 3.3v at the most, maybe less. This does not seem to be a problem for the S/W driven interface, but it might be when operating at 10x that speed on the H/W bus, this becomes a problem.

Does this seem like it is a possible source of the problem?

If so, is there any simple way to get the 3.x volt MISO card output to have a 5 volt output? I have some NPN transistors, various logic gates, diodes, resistors easily at hand.

I was worried that if I use a simple pull up resistor on the MISO signal from the card to the ZX-24 I will either mess up the ZX's own SPI communication, or I will damage the card.

Any suggestions?

-Tony

[dkinzer]

[spamiam]

[dkinzer]

[GTBecker]

FWIW, I'm using 3.3v SPI from a PNI compass on a BX-24p with only
dropping diodes for power to the compass, resistive voltage dividers on
MOSI, SCK and /CS, and a direct connection for MISO.


Tom

[spamiam]

[spamiam]

OK!

I got it working.

I was right about the card not sharing the SPI bus happily.

I decided that I need to implement a separate /CS to the MMC card, so it would never be dropped, except when I wanted it to be dropped.

Therefore I had to prevent the signals on the SPI bus from getting through to the card except when it was being addressed specifically.

I solved this with a quad AND gate, and an inverter gate.

The SPI channel's SSEL goes to the inverter to get inverted. Now SSEL is HIGH when selected.

This signal goes to 3 of the 4 AND gates. The other signals to the AND gates are the SPI SCLK, MOSI, MISO. This is how the MISO signal gets level translated.

Now, the SCLK, MISO and MOSI signals only get to/from the card when the cards SSEL is selected.

It works!!!!!!!

I was just about to give up and let someone else figure it out!

I did the development with the SPI speed set to the slowest (F/128) to make up for the poor bandwidth of the 4000 series logic gate I am using. I don't have any high speed AND gates.

Once it was working, I turned up the speed on the SPI bus, and I found that the AND gate (or the resistor dividers, i guess) crapped out at above F/8, I.E. above about 1 MHz.

In my next order for electronic parts, I will get some higher speed logic parts. (actually my inverter is adequate, it is in the 74HCT family)

-Tony

[dkinzer]

[spamiam]

[JC]

Hi Tony,
I do not have my notes before me...
I was data logging GPS data, mixed with some other inputs, and storing it on an MMC card. I used my own bit banged (slooow) interface, which I believe is posted on the forum.
The SD/MMC requires a 512 byte block of data to write to the card, one can not write an arbitrary (smaller) number of bytes with one write command. Setting the Block Length does not change this minimum.
One can, therefore, buffer the data, and write a full buffer; or read in 512 bytes, update what you want, and re-write it back.
I did not wish to do either of these, so I start a write, and send small packets of data at 1 second intervals, within the single MMC write command. After sending all 512 of the data bytes, over a period of ~15 seconds, I complete the write command, and issue a new one, awaiting the next packet of data. It works fine.
With the ZX's multitasking, I can write the data in the background, and speed is no longer an issue.
JC

[spamiam]

I have not tested writing less than the full 512 bytes, but what happens if you drop CS befoire completing the full 512?

I would have thought that this would allows only a partial sector to be written.

-Tony

[dkinzer]

[JC]

The first time I worked with MMC cards was several years ago, then it sat on back burner until I nneded it again.
I tried extensively to do single byte and < 512 block writes without success.
The San Disk manual was contradictory in this regard.
A table implied that it was possible, the text, and a later manual addendum made it clear that it was not.
JC

[spamiam]

I will try writing on my OLD OLD OLD SD/MMC card. When I tried partial block writes in previous testing, it seemed to work OK, but I was not specifically checking the reliability.

It was relatively up to date when I got it. It is an 8Meg card. THat tells you how old it is. I have no idea what brand it actually is. Something weird. Maybe it will not adhere to the Sandisk standard the way newer cards will. For instance, I can get a "valid" read on the Card ID structure, but it is gibberish. Either I am not getting a good read off the card, or the CID is not quite according to the SanDisk literature I have been reading.


More on interfacing to the hardware SPI bus:

As I read the SanDisk standards, it says that the CS must remain low for the entire Command-Response-Data sequence.

The only successful method I have had to get the response is to poll the card. I tried to use SPICmd() to send the command bytes, then read back a ton of bytes. None of them registered a "good" response. Without getting (and understanding )a valid response byte, you do not know when to start looking for the data, nor when to stop reading the data.

When I poll the card it works.

So, I do not see any feasible way to use "standard" SPI techniques to keep the Comand-Response-Data atomic (as far as the CS signal is concerned) other than having the CS signal separately controlled from the SPI signals.

Don had previously said that an SPI device that does not adhere to SPI standards is pointless. I agree. I suppose the SD/MMC card designer had envisioned a bus dedicated to the memory cards only. In this way, there is no need to interleave other SPI accesses between the Command-Data-Response elements. Or else the Firmware understands that MMC card accesses are diffeent from other devices and will hold the CS signal until it is appropriate to release it. This is not something that a general-purpose SPI interface should be expected to handle.

I suppose that there could be an "extended" SPICMD(), where there is an extra argument. It defaults to ZERO. If set to "1", the interface will not release SSEL. until an SPICmd() is received with a zero as the last arg.

Of course, this is not compatible with the ZX architecture, unless the user program is not run on SPI-based EEPROM. (maybe on a larger CPU the bootloader, VM, and the user program can all be stored in flash).

-Tony