MC9s08JM60 and SD card interface

stevec · ‎08-22-2009

Hi,

I'm trying to put together a voice recorder/playback system using an SD card and a bought in FAT16/FAT32 driver from Embedded.com. I am using the SPI interface. I am finding that different cards behave differently under similar conditions, with most of them failing the initialise phase. I am getting responses from the card indicating illegal commands but I can see data in the correct places. Other times I get a response from the card which has been clocked out at the wrong time (e.g 2 clock pulses late). This all seems to point to clocking problems but I am running at about 1MHz after the initial 400kHz stage. I have turned on/off the slew rate limiting. I have tried using the high drive capability on the SPI pins, and combinations of both. Has anyone had any similar problems. At present I have a hand wired board but with very short ( < 1cm) wires to the SD card. I have a pcb on it's way but am running out of ideasif that doesn't sort it.

PeterHouse · ‎08-22-2009

Try slowing down the clock if you suspect wiring line lenght issues.

My personal bet is you have the SPI Clock Phase or Polarity set incorrectly.

1 inch of wire is approximatelt .1ns. A small bit of wire and a littlestray capacitance can cause the SPI to work with the wrong phase or polarity selected as the clock or the data can be delayed just enough to work most of the time.

I fixed a product where the polarity was wrong on the shipping product and it worked pretty well most of the time and died horribly sometimes and occasionally "bricked" the product. Many things were blamed before finding the polarity issue.

You can most easily tell using a good oscilloscope when reading the device and looking at when the SD card is changing data what the data relation is compared to the clock you are providing.

Good Luck,

Peter House

stevec · ‎08-24-2009

Hi Peter,

I can confirm that the data is clocked into the card on the rising edge of the clock. Data from the card changes on the negative edge.

I have just made up my pcb and no change to the symptoms. I have reduced the higher speed card clock to 750kHz and all the cards I have will read the MBR and determine the FAT type correctly. If I up the clock to 1.5 MHz two out of the four cards fail to read the MBR. As an example of 'data slippage' I was expecting a response of 0x00 from the card and it comes back as 0x80,0x7f, in other words the 8 data bits have slipped by one clock as if the card has missed a clock pulse. If I then up the clock again to 3MHz the expected 0x00 comes back as 0xc0, 0x3f, which means the card looks to have missed two clock pulses i.e the data is now two bits late. Very confusing.

I am running with the clock phase (CPHA) = 0. I tried it at =1 and that made matters worse. I'm not sure about the relevance of this bit though.

I am using a decent digital scope to make my observations.

Steve

bigmac · ‎08-24-2009

Hello Steve,

stevec wrote:

I can confirm that the data is clocked into the card on the rising edge of the clock. Data from the card changes on the negative edge.
...
I am running with the clock phase (CPHA) = 0. I tried it at =1 and that made matters worse. I'm not sure about the relevance of this bit though.

This suggests that your current settings are CPHA = 0 and CPOL = 0. When you try CPHA = 1, you might also change the clock polarity (CPOL = 1) and see if this makes a difference.

Regards,

Mac

stevec · ‎08-24-2009

Bigmac,

I've just tried your suggestion. The most noticable affect is that the clock appears to come out as a continuous stream. With both bits zero the bytes appear as discrete packets of 8 clocks with about a few clock cycles between each. The program reaches about the same point in the card initialisation before it falls over. The card response is only one clock pulse late now (instead of 2 as show in the photo). This has to be something simple. The hard problems always are!!

PeterHouse · ‎08-24-2009

The data DOES NOT SLIP unless the slave device, the SD card, is missing clock pulses. Is the SD card rated for 3.3v? I believe there is a pin on some of the SD cards to select 3.3 vs 5v. I have never worked with an SD card but have read about them and worked with a lot of other SPI devices.

You must solve this issue first adn then tackle the CPOL and CPHA issues. Both bits MUST be correct for it towork reliably. Study the data sheet diagram and DRAW OUT ON PAPER what you think a one byte waveform should look like. As I recall, the data sheet should have a pretty clear explanation on these bits and how they effect the waveforms.

Since your data is clocked into the card on the rising edge you must make sure the data is clocked out of the MCU on the falling edge.

Since your data is clocked out of the SD card on the falling edge, you have to make sure the data is clocked into the MCU on the rising edge.

Good Luck,

Peter House

CPOL and CPHA are used to match these edges.

stevec · ‎08-25-2009

Thanks for all your help guys. Turns out it was a corrupt source file. I reloaded the third party files and things started working. I can't say exactly what bit was affected (unless I do a side by side comparison) but it seemed to have a subtle effect. I can now go back to the original problem which has to do with the filing system performance. Another post on the way!

bigmac · ‎08-24-2009

Hello Steve,

If the SD card requires CPHA = 1, it means that the MSB does not appear at MISO (and MOSI) until after the first negative clock edge, and will then be read on the next positive edge (for both master and slave).

In contrast, with CPHA = 0, the MSB state is assumed to be present immediately the SS signal goes low (assuming such signal is present for the SD card - I am not familar with the SD card connections and protocol). This means that the next expected clock edge is positive to read the bit state.

This may well account for a one-bit delay, but not for two bits.

Regards,

Mac

stevec · ‎08-24-2009

Please note that I have one card which works perfectly up to 6Mhz. It initialises and I can read and write data to it. Also a second card gets through the initialisation sequence at 6 MHz. This is with both polarity and phase set to 0. Surely all SD cards work to the same protocol/interface spec?

stevec · ‎08-24-2009

As far as clocking is concerned when I look at command responses from the (working) card the MSB of the response byte is o/p on the negative edge of the previous clocking sequence. This is with polarity and phase bits set to 0 which has been my setting since starting the project.

I started this project by reading a .wav file from the card (put on it by PC) and outputting the data to DAC. This worked fine with the one card I had then. All this problem has occurred since working on the recording to card section and obtaining other SD cards. Luck would have it that the only card that works for playback and record was the original card. If I had had one of the others these problems would have been seen earlier as it affects initialisation.

PeterHouse · ‎08-24-2009

Steve,

If the data is clocked in on the rising edge then the data coming out of the MCU should change on the falling edge which insures it has the full clock time to stabilize. The same goes for the data coming from the SD card - If is changes on one edge, the MCU should clock it in on the other edge. This is controlled by the CPOL and CPHA bits.

I recommend verifying these bits are set correctly using your 'scope. This is probably the most confusing part of SPI with shifting data in and out on the same clock a close second.

Since there are four combinations for theCPHA and CPOL bits you can try them one by one. Make sure to power off reset the SD card between trials to make sure it is starting fresh. Beware using this method as two of the settings usually work but only one will be reliable.

You could post a 'scope trace showing clock, data in and data out, one or two bytes full screen.

Good Luck,

Peter

stevec · ‎08-24-2009

Here are some screen shots of the waveforms. The first is of data from the uP to the card (MOSI), the second is of data from the card to the uP (MISO), the third shows an example of data 'slippage'. I was expecting an 0x00 response byte but it looks like it has slipped by 2 clock pulses. This was one clock pulse at a lower clock rate (1.5MHz) and correct at 750kHz.

DSC_0418p.jpg

DSC_0421p.jpg

DSC_0422p.jpg

Message Edited by t.dowe on 2009-08-31 10:58 AM