need help regarding SPI ADC and PIC.

zeeshan ahmed · Joined: 02 Dec 2010 Posts: 22

Hi all, I am new to CCS, I want help regarding interfacing and programming SPI ADC (MAX1416) . I am using pic18f252 micro. CCS version is 4.124

this is what i am doing to configure adc.

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

Start with your SPI setup.
The data sheet description, corresponds to CPOL=1, CPHA=1. Mode3, is standard SPI terminology, which from the following table:

zeeshan ahmed · Joined: 02 Dec 2010 Posts: 22

Thanks Ttelmah for your time.

I made the changes in the code suggested by you.

The problem is still there, still i am getting zero. I checked the data and clock lines with an O scope. but there is no clock and data signal. Confused

I have checked my hardware and it seems ok.

Please let me know if i am doing something wrong.

Thank U.... Best wishes

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

OK.
I'm reading this as you seeing no SCL clock at all out of the PIC?.
If so, then start at a lower level.
First, do a simple 'hello world' on your serial. No SPI at all. Does this work?. If so, you have proved:
1) The PIC is alive - so no clock problem/power problem etc..
2) The PIC is running at the right speed.
Then step along, and do a basic 'toggle' on each of the lines SDO, and SCL. Do these toggle OK?.
If so, you have proved there isn't a short or something stopping these from working.

Come back after these basic tests.

Best Wishes

zeeshan ahmed · Joined: 02 Dec 2010 Posts: 22

I found another problem. I observed using an O scope, that ADC'c Dout line remains in High impedance state all the time. While ADC's CS pin is tied to ground.

Secondly Drdy line continously toggling, which shows that the new conversion result is available. Now Sclk and Din Lines are working properly. But the result is still garbage.

Please Help....
Thanks alot.

zeeshan ahmed · Joined: 02 Dec 2010 Posts: 22

Thanks Ttelmah ...
I have done all the basic tests. PIC is doing Good. I found no problem in hardware. Serial Port test & I/O operation of Spi port is also successful.

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

OK.
Now, if the chip was reset, it should wake up _not_ performing automatic conversions. The fact it is performing such conversions, saya:
1) Possibly the chip is not waking up properly.
or
2) The chip _is_ receiving the SPI packet from the PIC.

So. I'd suggest two things:
First, try having a reset circuit, to hold the chip in reset for a few moments after power is applied. Capacitor on the reset pin, pull up resistor, diode across this to discharge the capacitor when power is removed, and pause the code for a few mSec on start to ensure the chip has time to start. Before you pause, set the SCK line high. This then ensures that the line is high when the chip wakes up, and avoids getting out of sync at this point.

Then just change your code a little. Look at figure11 again, and realise you only have to loop back to checking the DRDY bit, not re-initialise the chip every time round the loop.

Best Wishes

zeeshan ahmed · Joined: 02 Dec 2010 Posts: 22

Thank You Ttelmah...

I did what you told me. But the problem is still there. Sad

I noticed one thing that, whenever I try to read 8 bit register e.g clock register, controller works perfect, and Dout line shows correct data. But whenever I try to read 16bit register i.e Data register, Dout line goes in high impedance. I think this is due to the reason that SPI supports 8 bit data transfer.
Now my code is

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

There is nothing special about a 16bit transfer versus an 8bit one. SPI, is synchronous, so 'synchronises' to the clock it is sent. An 8bit transfer sends 8 clocks without a break, while a 16bit transfer just has a slightly longer clock between the 8th and 9th bit, as the first byte is read, and the second loaded. There is no minimum speed for SPI transfers (there are for some chips, but these are still plenty long enough to pause for a moment like this), so the pause doesn't matter at all.

Now, two things worry me about the data sheet:
The first is which chip is 5v, versus 3.3v. The number of places where the 1415, is listed as the 5v chip is 'scarey'.....
Then the question of CS. If you have got a separate pin available, I'd drive this. So when you see DRDY go low, then drop CS, and perform the transfer, and when you finish the transfer raise CS. Using SPI without a CS, is always very fussy. Problem is that if the chip 'sees' an extra clock transition for any reason at all (noise, timing during power-up, etc. etc.), then the slave device, and the master device _will_ be out of sync. All the timing diagrams in the data sheet show CS being used, though the sheet refers to using the chip in 3wire mode, without it.

As a general comment, the data sheet says the high byte is sent first, so you have your variables reversed in the make16 operation.

Realistically, if it doesn't work with CS to add synchronisation, there has to be a hardware fault somewhere. Your code now corresponds exactly to the data sheet flowchart. When you tested that you could toggle SDO, and SCL, did you test that these were actually toggling at the pins of the ADC?. Similarly with all other connections. Triple check.

Best Wishes

zeeshan ahmed · Joined: 02 Dec 2010 Posts: 22

Many Thanks "Ttelmah"

Controlling the CS line solved the problem. Now I am able to read data through ADC. I also reversed the variables. I am bit banging the spi port to get the data in.

For bit banging I use this function.

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

You don't show in the new code, where you are operating the CS line, when using the hardware SPI?.
This must be raised, before you go back to testing for DRDY.
I suspect what is happening is CS is not being operated correctly, so DRDY thinks the read has not yet completed, and stays low. The code then loops a second time, and reads blank values, since a new conversion has not occurred.

Best Wishes

RF_Developer · Joined: 07 Feb 2011 Posts: 839

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

Yes.
If you look again at the data sheets, you will see that DRDY, is meant to go high, 100nSec after CS goes high on the read. This is why I as saying he does not show what he is doing with CS on the reads. It needs to go high when he completes the reads, or there doesn't seem to be any guarantee it will have gone high when it is next checked, and as you say, this will then result in a second read. I suspect what then happens is after just one clock, the line does rise, but by then the master has started reading, and then just gets the 0 value.

Best Wishes