Error in response from CMD0 in SPI for mmcard in Proteus

[Mustang1945]

Hi, please i need some help. I am trying just to send the CMD0 command to an mmcard but always the response is 0Xff. I know its a software error because i am wiring exactly as this example from Proteus where i can see what is being sent...
[img]
http://i.imgur.com/OIg5Eyo.jpg

and i know what i am receiving...
[/img]
http://i.imgur.com/bCjhbGM.jpg

The problem is that when i use my code it doesn't work. I am sending the same numbers as in the Proteus sample but i always receive 0XFF.
Honestly i don't know how to configure the SPI. In the Sandisk datasheet i haven't found anything about bauds or bits. Mode 0 i know is needed because I found info about that. If you have a link to learn how to configure these parameters it would be great. Thanks.

[temtronic]

#1 Proteus is WRONG.... your project, if wired as the 'schematic' can never, ever work. Hint....the 4550 is a 5 volt PIC, SD cards are almost always 3 volt devices.

#2 Proteus is WRONG.. your project cannot work with real hardware as shown. There are NO power connections (+3v, gnd) to the SD card slot

#3 Proteus is WRONG.. your project doesn't have power (+5v, gnd) to the PIC and NO cap on VUSB.

There are at least a dozen serious wiring 'issues' with the schematic, any of which will not allow the PIC to communiate with the SD card.

Others may offer help.......
I strongly urge you to get a 1Hz LED program coded/compiled/tested with the PIC. It would be a good necessary starting point.

Jay

[PCM programmer]

1. You setup the #use spi() statement for 16-bits SPI transfers. But, all
the CCS examples for MMC cards, such as mmcsd.c or mmc_spi.c all
use 8-bit transfers. You should change it to 8 bits.

2. You setup the SPI using a #use spi() statement. This method is
intended to use the spi_xfer() function to send and receive SPI data.
Instead, you use the older spi_write() function, which is associated with
the setup_spi() statement. You're not supposed to mix the two methods.

3. You setup a stream in your #use spi() statement, but then in your
code you never reference this stream. If you're going to use a stream,
then you're supposed to enter the stream name as one of the parameters
in each spi function. The CCS manual shows how to do this.
http://www.ccsinfo.com/downloads/ccs_c_manual.pdf

4. There is a bug-fixed version of the CCS MMC/SD routines in the
Code Library forum.

5. You're going to get chastised for using Proteus.

[Ttelmah]

The big one though is to read the sticky at the head of the forum about interfacing an SD card....

The SPI input on a 5v PIC requires the signal to get up to 4v, to be seen as a '1'. A 3.3v SD card cannot do this without a buffer chip. As Temtronic says, Proteus is wrong (the input pin has a different Vih, when used by the SPI peripheral, from when it is used as a conventional input - Proteus can't handle such complexity, so 'assumes' the input has the same sensitivity...).
You need to either switch to using a 3.3v PIC, or add a buffer chip on the incoming signal.

[Mustang1945]

Hi, good morning

PCM Programmer and Ttelmah, thanks for your responses. I think i haven't been clear, sorry, i am not testing in real hardware, it is just a simulation in Proteus. That is why i am trying to do it, because if i am wiring my simulation same as the simulation sample in Proteus (that works) so my simulation must work...

I have a doubt about #use spi, because in setup_spi i can set the clock frequency. I read that the clock for mmcards should be set from 100khz to 400 KHz, but the #use spi doesn't have that option.

[Ttelmah]

Actually it does.

Two methods. The first, select the 'NOINIT' option in #use SPI
Then when you want to set the baud rate, use the command spi_init

spi_init(baud);
or
spi_init(stream,baud);

Or use spi_speed:

spi_speed(baud);
spi_speed(stream,baud);
spi_speed(stream,baud,clock);

However I usually do this a third way.

Specify two streams on the same pins. One using the hardware (force_hw), and NOINIT. The other set to the low rate and using software SPI.

Then to initialise use the slow stream. once you have the card ready to use the high speed, call spi_init for the fast stream, and switch to using this.

The reason this is better is that on many fast chips, the hardware SPI can't actually switch down to the 100KHz rate. Generally it doesn't matter (most cards will initialise even if you clock the line too fast), but if one wants to be really careful the software solution is safer for the initialisation. I prefer this on really fast chips (DSPIC's).

Honestly though , don't waste time with Proteus. You can design the entire project in this, and it then won't work in the real hardware, or transfer a working project into Proteus and it then won't work. As a PIC simulator it is a waste of time.

[Mustang1945]

SOLVED!!!

Thanks Ttelmah, i didn't know that bauds and Hertz's are the same. I decided to use the setup_spi function because i read that #use spi has bugs, but i understood your idea about changing the bauds once the mmcard is initialized. PCM Programmer thanks to teach me about the difference between setup spi and #use spi, really i was lost ... this is my code.

[Ttelmah]

Don't get me wrong, but the best simulator is the hardware.
Now, given that most PIC's now have ICD capabilities, with a cheap ICD unit, and the chip you want to test, you have the ultimate simulator, _including the real hardware bugs_, and it costs less than any commercial simulator is going to be. I have a programmable ICE system. These contain programmable logic that you can setup to emulate almost any chip. However a 'code core' for a PIC for this starts at a few hundred dollars, while the unit itself, runs to many tens of thousands.... Compare to the price of an ICD and a prototype board with the PIC.
Unfortunately also many of the 'little glitches' only appear in the real PIC hardware, when peripherals are used together. 'Design rules' for things like Proteus miss these.

#USE SPI, had bugs when it was first introduced. However it's been out and working well for years now. However it still has the complexity of 'hiding things'. So (for instance), this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=56241>
Illustrates the problems it can bring. The poster is not aware of the capabilities/limitations of the hardware.

Baud, only equals 'Hz', and bps, when there is one signal state on the interface.
So a modem that uses trellis encoding and sends (say) 16 possible states in the trellis, sending data at 2400baud, sends 9600bps. SPI using one wire (all the PIC hardware supports), only sends one state per clock. A 'baud' is a single change in the signaling state. For simple interfaces, 1baud = 1bps = 1Hz.

It's dangerous to use terms like 'CMOS', and 'TTL'. Much better to actually look at the Vih and Vil levels. The PIC's are all CMOS internally. A CMOS gate can still have Schmitt inputs...
So RC3 & RC4 on the 887. Look at 'Block diagram of RC3'. Shows the I/O pin feeding into a Schmitt buffer (This is what the little squiggly symbol means). Then look at D041 in the electrical parameters, where Vih for a Schmitt input, is specified as 0.8*Vdd. Now the Voh of a SD card is specified as Vmmc-0.2 (for all cards with push-pull drivers). So with the card at 3.3v, 3.1v. The Vih using 5v, is 4v.....

Realistically if you look at the sticky at the head of the forum on this, the link to the basic circuit using a buffer, shows the reliable way to connect to a 5v PIC. Alternatively now, it is so much easier to use a 3.3v PIC.

[temtronic]

As Mr. T points out the BEST simulator is hardware in the Real World ! In today's 'world of electronics design', you've got it easy. Inexpensive, full blown computers for a dollar, in-circuit programming and PC compilers like CCS. When I got into this field of fun, you machine coded using pencil and paper, made a paper tape, then fed that into a Teletype 33ASR to program the minicomputer (PDP8), that's AFTER you hand toggled a 'boot loader' into the PDP8 ! Back then you spent a LOT of time crafting your code as the actual downloading was painfully slow. These days you can cut/compile/download hundreds of versions in a day.......
One of the biggest problem with any 'simulator' is their lack of emulating the Real World. They do NOT see EMI, bad ground planes, unsoldered connections or missing xtal caps.....or VDD with high AC content (filter cap too small...) or backfeed from a sensor.....the list is endless, the point is that it's EASY to test in the Real World where you'll get real results.

Jay

[Mustang1945]

Thanks!