Communicating with DAC via SPI

[Guest0527211403]

Hello everyone,

I'm using a Microchip MCP4922 DAC (dual output, 12 bit, SPI communication) connected to a dsPIC 30F6010A. The two outputs of the DAC will feed back to two pins, Vref+ and Vref- on my dsPIC to set my voltage references for my sensor and allow me to "window" the dsPIC's ADC in on a certain range. I need to do this for a few sensors so I want to do it "on the fly", hence my use of a DAC over a static voltage divider.

I'm limited in the number of output pins that I have, so I opted to go for a DAC that communicates via SPI, in this case the MCP4922. Another reason for this choice was the fact that this is what I had on hand.

I've managed to set up SPI in the dsPIC, and I can write to and latch one of the DAC outputs (DAC B), but I cannot seem to latch the other (DAC A).

As far as I can tell, all the MCP4922 needs me to do is change my most significant bit (i.e. bit 15) from a 1 to a 0 to write to DAC A. When I do this, however, the output changes on DAC B but nothing happens to DAC A. That is: what I think I should be getting on DAC A ends up on DAC B (and no change to DAC A).

I've checked the SCK and SDO lines on the scope, and everything the dsPIC is sending seems to be correct. My /LDAC pin on the DAC is tied low, which should mean that the DAC should latch its outputs as soon as my /CS pin goes high, but unfortunately it's not working out.

So now I'm wondering if anyone's encountered something similar before, and if there is something that I could have missed in diagnosing this problem.

Thanks in advance.

 

[itsmoked]

I encounter &*(@%^$ like this all the time..

Sure you don't have a 4921? LOL

You say you've scoped the data and clock and they look OK, with the correct data?

The most common trip ups on SPI are:

1) You are going too fast for the external part. You set the the processor up to run at whatever and the result is you may exceeding the SPI speed limit. You only get 3 choices of divisor. Check and make sure this isn't it. I generally start at the slowest possible SPI speed and when everything it working crank it up.

2) Sampling point. Since you can talk to one half this is probably not it.

3) Marking position. The polarity of idle. If it's wrong the first bit may be mis-interpreted.

4) Same with clock edge selection. Gotta be the correct one or the bit can be shifted.

Otherwise. Are you correctly raising CS after each transmission?

Increase the time between CS-low and sending data.

Make sure you aren't stomping on A's transmission with B's.
This is very is easy to do on PICs.

Alter the code to talk only to A in both of your transmissions.

Be very careful of Microchips' errata for your processor. READ THE ERRATA SHEET. They have lots of errata with respect to their SPI and I[sup]2[/sup]C peripherals.

Get back on your results.








Keith Cress
kcress -

http://www.flaminsystems.com

 

[Guest0527211403]

Thanks itsmoked. I'll let you know how it goes in the morning

 

[MacGyverS2000]

Polarity is what always gets me on SPI...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[Guest0527211403]

Well, it seems like I had my glasses on upside down on sunday. It turns out that I'm getting output on DAC A and NOT getting output on DAC B, even when I'm only sending the command to write to DAC B.

So what this is telling me is that my first bit is always coming in as a zero. (Or there's something wrong with my DAC?)

I've tried all of the combinations of CKE and CKP with no success. I've also tried to wait a few hundred ?s between sending /CS low and transmitting, also with no luck.

Sorry I didn't get back sooner. I'll post back once I figure out what the actual problem is.

Regards
Mark

 

[itsmoked]

Have you set up your scope with one channel on the clk and one on the data? You should see exactly what you are sending. If you have more than two channels include CS and use it as the trigger.

Are you raising CS between channels?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[Madcow]

I rember something like that when I used that DAC.
I think it had something to do with not toggling the CS signal between the two commands.
Also if the CS goes high before the 16th bit it aborts the command.If you switch which commands you send first does the other output work?

http://www.microchip.com/forums/tm.aspx?m=413429&mpage=1&key=&#413937