AnsweredAssumed Answered

Never get DOUT/RDY# low on AD7194 to read data

Question asked by Dr.Lightning on Jun 30, 2012
Latest reply on Jul 3, 2012 by MaryMc

I'm talking to an AD7194 with a PSoC5.  I can write and read config and mode registers just fine.  I'm setup for continuous conversion.  But when I try to read the data reg, I poll the DOUT/RDY# line and it never goes low.  Please help me figure this out.

 

 

Among other things, I've beat on my software to the point that I now have a single subroutine that incapsulates in a nutshell stuff that should work, but isn't.  I'll summarize the code here:

 

 

1) In the beginning of this function, I re-read Config and Mode registers.  I get Config=0x0004F058, Mode=0x00040007.  So I know they're correct.

 

 

2) I wait for any prior SPI activity to go idle, then I have a PSoC5-internal circuit to force CS low and hold it low for the duration.  (This begs question #1 below.)

 

 

3) Added later, after the function was already not working, I added this:  Just in case prior code or something messed up the interface, I send 48 one bits.  Of course, the Config and Mode reads worked (added after the 48 one bit reset was added).  But neverthless, it's in there now.

 

 

4) Next I write 0x58 to the communication register.  Remember, CS is being held low the whole while.

 

 

5) Take this time to note that the pins on the chip are small and I don't have any good test points for my scope.  My config and mode reads succeed, so MOSI and MISO must be working in general (DIN and DOUT/RDY#, respectively).  I do have a tiny wire and scope lead on CS, and I can see it doing what I assert.  I have another tiny wire on DOUT/RDY# and I know it's NOT doing what it's supposed to do... It's always high while I'm polling and CS low.  But it is going low during other read operations, both seen on scope and evidenced by 0 bits in read-back Config and Mode registers.

 

 

6) So now I check the MISO pin (DOUT/RDY#).  I loop indefinitely.  I watch the scope.  I stop and single step.  DOUT/RDY# won't go low.

 

 

7) I move the isntruction pointer back to the top and read Config and Mode again.  They're reset (duh!) to Config=0x00000117 and Mode=0x00080060.  Well, this is still continuous mode, so it ought to still work.  That is, DOUT/RDY# should go low.

 

 

8) Is there anything ELSE I need to do to kick start this fellow converting?  Maybe it's never started?

 

 

9) I modify my function again, addign my intended write to Config and Mode (in that order) *AFTER* the 48 one bit reset.  This doesn't help.  Immediately after the Mode write, I stop on a breakpoint and scope confirms CS low, DOUT/RDY# high.  I step over 0x58->Comm function, DOUT/RDY# still high.  I move instruction pointer to read Config and Mode again... they're good.  Try writing 0x58->Comm again, DOUT/RDY# still high.

 

 

Question #0: What am I possibly doing wrong????

 

 

Question #1: "FAQs for the AD719x family" at http://www.analog.com/static/imported-files/faqs/AD719x_FAQ_Instru_Conv.pdf says, "The serial interface is independent of the sampling process."  So letting CS go high between accesses should have no impact.  Nevertheless, datasheet Figure 25 holds CS low, so I'm trying it in this function.

 

 

Question #2: Datasheet Figure 25 shows CS going low, followed by DOUT/RDY# going low, both PRIOR to sending 0x58 to Communications register.  CONTRARY to that, the FAQ says to write 0x58 to the communication register and THEN poll DOUT/RDY#.  So which is it?  I've tried both ways and neither works for me.  Obviously, I must have some other problem, but I'd still like to know about this.  For my existing code and program structure, it would be easier to poll and see DOUT/RDY# go low and then AFTER that send 0x58 to the Communications register.  This way, I can keep all my 24-bit register reads, preceeded by Comm write, in some tightly bound support functions.

Outcomes