More problems with H/W SPI

[spamiam]

I have been plugging away at the hardware SPI communication to an MMC card.

I have the S/W version working properly as far as I can tell.

I have found some odd differences between the H/W version and the S/W version.

For instance, when I ask for the Card ID bytes, I do not get the exact same bytes in both versions. The 7th and 8 bytes are different, then the 15th and 16 bytes are different. I do not know what this is trying to tell me. I always get the same bytes for each version of the interface, but the two are different.

When I try to write a block, it seems to work OK, but when I read it back, it is unchanged. The S/W version works fine.

So, I looked at the SPI signal on my scope. I just wrote, as a single SPICmd() transaction, the array &HAA,0,0,0,0,0,0,0. Looping over and over.

When I send this array on the S/W version, on the MOSI signal, I get a few hi-low transitions (the &HAA), then a steady low until the next loop, This is what I expected

When I do the same on the H/W version, I see a high blip at the end of each byte transmitted. I only have a 2 channel scope, and I am triggering on the CS signal going low, so I can test only one data line at a time, so it is hard to be sure of what the clock signal is doing at the moment of the blip. It appears to be transitioning high-to low on the las bit, but I can't be sure.

Is this blip at the end of each byte expected for the H/W SPI interface? Is it just something on my ZX that is screwy?

Will this blip mess up SPI communication? I have found no other cause for my problems with the hardware SPI interface ALMOST working perfectly.

Note: I am using some extra logic between the ZX and the card. I run the /CS signal thru an inverter to a quad AND gate. The MOSI, and the SCLK get anded with the CS signal so remove the EEPROM SPI signals.

Since the CS remains high throughout the SPICmd() transaction, I do not see how the external logic is to blame. Plus the same logic is used with the S/W version specifically to prevent this from being a variable.

The speed of the H/W SPI is set to the lowest possible.

I include a picture of my scope display so you can see the blips.

-Tony

[twesthoff]

Tony,

[spamiam]

[twesthoff]

Tony,
The CS is fairly slow, you could probably just stick a piece of wire in the BNC center connector and use that for a quick test. I've done it many times...
Of course a shielded BNC is best, just keep the wire as short as possible.

Just a thought, look at the pins before your and gates and see if the pulse is there too.
Tom

[spamiam]

I will try to get to a radioshack tomorrow and get a BNC cable. <y breadboard has some convenient BNC connectors that I can jumper to. So all I need is a BNC patch cord.

I did check the signals coming straight out of the ZX. The blips at the end of each byte are crystal clear.

Of course this is being seen on the MOSI from the ZX, and maybe this signal is working adequately well.

I CAN get the H/W SPI to write data to the card, either perfectly or adequately,

But when I read it back, I get the garbage on the last 12 bits of an 8 byte sequence.

This does not appear to be the card malfunctioning because I do not get this problem with the software interface, which is essentially identical as much as I can make it.

-Tony

[twesthoff]

Tony,
I agree with you that since the blip is on the MOSI and it writes to the card OK, that it may not be a problem. (I still don't like the blip.)

Of course the only way to know for sure is to look at the clock edge as compared to the data lines, and you will be able to do that with the ext sync input.

I'll be waiting to see what you find out.

About a year ago, I was toying wit the idea of building an external hardware SPI interface with a 25MHz clock to see if I could write faster to an SD card. It would use a whole 8-bit port + a few more bits, but I wanted to write as fast as possible. Not sure how fast I would be able to send bytes to the interface from the ZX. Maybe it would be the limiting factor... Hmmm...
Tom

[spamiam]

Tom, By watching the scope very carefully and triggering on the clock pulse, I was able to see that the blip went high as SCLK went low on the 7th bit of the byte. The blip lasted only a fraction of the low portion of the clock, and was low again before the SCLK went high for the last bit of the byte.

I suspect the blip is something about the AVR hardware itself doing this because I am sure that the ZX programming is only using the hardware SPI services. The VM would be loading the next byte and telling it to "go". An interrupt occurs when the byte is done, telling the VM to take the byte and replace it with a new outgoing byte.

I am going to scope the output from the card to see if I can see the weird 12 bits.

-Tony

[dkinzer]

The glitch that you're seeing may be a result of the external logic that you're using. The fact that it doesn't happen when you use the bit-bang interface doesn't rule out that cause because the timing of the signals, although similar, is not identical.

If you can post a diagram or sketch of the circuitry I'll look at the signals on a logic analyzer to see if there is a timing problem.

[spamiam]

I will whip one up right away.

I have a little more info since my last post.

Essentially there are 2 glitches. First is the very odd every 8 byte glitch that really screws up data reads. I wish I could tell if it is coming from the SD card or from the ZX, but I just cant tell well enough.

I had been replicating the function of the bit-banged interface right down to doing individual byte reads off the card even when I planned on reading many more, like a full 512 byte block. In that case I was seeing the 12 bit error every 8 bytes.

I substituted a single read of all 512 bytes, and as far as I can tell, I only get the 12 bit error once per read in the SPICmd() instruction. I have seen the error occur anywhere in the first 8 bytes of a larger read, seemingly depending on the number of reads that occurred after giving the card a command, and then reading its response.

When doing the read of data off the card, the dummy data that is sent to the card is not supposed to be used, but when I send domething other than &HFF, I see the 12 bit errors occur every 8 bytes after the first one.

The other glitch is seen on the scope as shown in the posted picture. This one happens even when nothing is attached to the ZX, and I have decided that it is not an issue for my problem, and it is most likely coming fromt he AVR hardware itself.

A post of the schematic will follow shortly.

-Tony

[spamiam]

OK, here is the Schematic of my interface. As noted in the schematic, the AND gate is listed as a 74HCT series, but I have been using a 4000 series instead due to availability.

The inverter I am using IS a 74HCT14 as listed.

As I wrote the post just before this, outlining my problem (and how it almost looks as if the dummy bytes being sent out to the MMC card during the read process made a difference in the actions of the card) I realized that I was not ALWAYS sending dummy &HFF bytes.

Since I thought the dummy was truely a dummy, it would not matter what its value was. I was starting to question that assumption. In some cases to save time, I was not specifying the value of the dummy defore it was to be sent.

So, I went through and checked every single SPICmd() instruction and made sure that the outgoing byte(s) were initialized to either a desired value or &HFF ONLY.

It appears that this cleaned everything up properly. The initerface to the MMC card still seems less robust than the same with the bit-banged technique, probably due to timing issues as you suggest.

So having a look at my schematic to suggest improvements would be well appreciated.

As I look at it, I see a delay created by the inverter that is not matched on the CLK and MOSI signals. Maybe I need to add 2 inverters to those 2 lines? But I do not see how that tiny delay is going to be a problem because it is the same effect for both the CLK and MOSI, so the relative timing between the two wil be identical.

The MMC_CS signal is software driven in the ZBasic program, so it will be asserted many microseconds even if the very next instruction is the SPICmd(). So I do not think that the need to assert cs a certain minimum time before other SPI actions will be a problem here.

-Tony

[GTBecker]

> ... I have been using a 4000 series...

Maybe it's time to buy some modern parts, Tony. 4000-series CMOS logic
is very slow by contemporary measures. Can that gate meet the risetime
specs of the processor and the card?


Tom

[spamiam]

[GTBecker]