AD7276 missing codes

Sean,

Sorry for the delay.  My test hardware failed and it took a day to bring up a new system.  There are several screen shots to show. 

The new system is a finished board for our instrumentation development.  For purposes of my tests it consists of an AD7276 with a REF1933AIDDCT providing precision +3.3V

Here's a snip of the schematic.  


This hardware is quite stable, with the SPI pins brought out to a 0.1" header. This attaches to my mother board, which also hosts an Atmel G55 xPlained board that is our host processor.  The ATSAMG55J19 processor is the same we are using in our instrumentation.

The timing diagrams are screen shots from a ScanaQuad SQ200.

My host SPI is configured as follows:

SPI bus speed is 1MHz and we telling the SPI driver to read 14 bits.  

My test code provides control over the number of bits the driver decodes and also can mimic resolution bit size ("conversion bits").  For my testing it's at 12, which means it has no effect upon the result.  "Bit shift" converts the 14-bit result by shifting it right by one bit.  We find with certain SPI mode configurations it's necessary to shift, otherwise the result returned is 2X the actual value!  In present case, we do not shift and returned values are good.

The driver used is ASF3.  Phase and polarity are defined thusly:

I am using "normal phase" according to the chart.

For this test I captured two consecutive reads.  The table below are the results.

And here is a capture of the ScanaQuad analyzer:

Timing:

SCLK:

(CS LOW to CLK HIGH=1uS)

I note that CS goes high and after 45nS goes low, right in the middle of the last bit.    Concern here?


The above does not illustrate our problem, and that is that above around 1.5V we do not get any conversion results that end in either 010 or 101.

Since you asked for timing, the above is a hopefully useful representation.

Thoughts?

ARSK1MGY,

A couple of things.

1) Can you confirm what voltage you put into the data converter when you generated these timing waveforms?  Was it approximately 2.5V?

2) The AD7276 is looking for the clock to idle HIGH and so you probably want to change your SPI configuration to CPOL = 1. 

3)  Data is shifted out of the AD7276 on the leading edge (falling) and the datasheet assumes the hold time of the serial data output is sufficient for you to read the current value on that edge with the controller and thus I would make CPHA = 0 so that the data is sampled on that leading edge.  If you left CPHA = 1 I think you would need to do your BITSHIFT trick.

4) Once you have completed 14 complete clocks the only timing requirement that needs to be satisfied with respect to CS is the minimum high time of 4ns as with your current clock period the converter acquisition time is satisfied.  Thus the narrow nature of the CS as you've shown is okay....in fact it is necessary to initiate the next conversion.

My suggestion is that you try making the code changes to implement the configuration I've mentioned above.   Then for range of DC inputs around the area you had trouble before recollect some data and let me know how things look before and after.

Hope this fixes your issue.

Sean

Very fast and intermittent pulses from a detector are processed through a filter and pulse shaper.  The pulses are presently simulated, and occur about 5 mS apart.  The shaped pulses are 20uS in width and are generally sinusoidal.  (As measuring the original detector signals is impractical, the shaper integrates the detector pulse, presenting it with a smooth rise time and extending its fall time.)  At approx 20% of the max shaped pulse amplitude a comparator fires a trigger signal and we then kick off a series of 14 ADC samples.  Presently these samples begin just slightly prior to the peak, and at 27.5MHz are sufficiently spaced so as to capture the shaped waveform nearly to 0V.

We initialize the SPI and once the interrupt is fired kick off the 14 DMA reads.  

In our test firmware, we enter a loop which waits for a boolean variable to change state.  This variable is set within the ISR that is kicked off.  When we see this, we know that our memory has data to process, and therefore we store this to a file on an attached SD card.  There's sufficient time between pulses to accomplish this task.  We then wait for our boolean to change state and again... 

The loop runs as many times as we like.  In my tests, we run it 30,000 times.  Whether we set our repeat to 2 or 30,000, the first values returned are always 0 or very low.

My suspicion was that the first read, due to some SPI driver housekeeping task that we are unaware of, is taking longer and therefore we miss the pulse entirely or partially.  I haven't seen this in scope captures.

I suppose we could read continuously, but this would not be very efficient.

Maybe when we load our firmware we can fire off a throw-away read long before we start our loop.  I'll give this a go.

@skowalik said:

Assuming (which I did) you set the CS low before your transmission you can use NCPHA = 0 so that you read the leading zero on the first falling edge and thus you should have no data alignment issue....except for the issue with the interface in the processor not being fast enough to capture that state.

CS goes low as commanded through the SPI driver.  I do not have independent control of that line.

Once CS asserts low, CLK starts.  It's the initial state of CLK that seems to be of importance in terms of staying in sequence with the AD7276 ADC.

The ADC will clock out on the rising edge of CLK, correct?  (the CLK falling edge updates the ADC conversion state, as I comprehend from the docs).  Therefore if NCPHA==0, clock starts low (and is low prior even to CS asserting low).  Therefore the first transition of clock (from low to high) commands the ADC to clock out the next bit, correct?  So, we say bye bye to the ADC's bit 16.  Since clock went high, bit 16 which was put on MISO by CS asserting low was never read by the SPI.  What's read is the one that CLK just pushed onto MISO, and that's the ADC's bit 15.

If I have expressed this correctly for MODE 0, then I've found the explanation for why we needed to >>1, and also why results were unstable (the latter as we were reading on the hairy edge of transitions).

Mark,

According to the timing diagrams in the datasheet it is the FALLING edge that clocks out the data.

The reason I think Mode 0 works is that the first leading zero doesn't update until the trailing edge of your first clock giving you plenty of time to sample it into the micro.  In this case you have a whole SCLK period versus whatever minimal hold time you have if the clock polarity is reversed.   Either way it really is just a reality of the fact that the AD7276 timing doesn't mesh perfectly with your controller.   However, I think that the way you have setup the timing makes perfect sense and you should feel comfortable proceeding with your current configuration.

I think I know what is going on with your data access.....By design the conversion result for your current sample (as initiated by CS low)  is being processed during the first transmission in your DMA burst and thus there is a delay of 1 sample for the data to be read back out into the uC.  That is to say that the result from the first CS pulse is read back in the second data transmission slot.  Thus the reason you are reading back zero is the first result shifted out is from the last transmission in your previous burst and thus would be close to 0 based on the pulse waveform!!!   Thus you probably need to do 15 bursts in each transfer and then just use the last 14 like you suggested.    It might be worth verifying this is correct by continuously capturing your current test pulse for 2 or 3 successive pulses just to make sure I'm correct.

Sean

In "The ADC will clock out on the rising edge of CLK, correct?" I meant to say "the processor will read the state of MISO on the rising edge of the CLK"  (while the ADC reads clock rising edge as a signal to do its housekeeping in order to properly set the NEXT bit, which gets clocked out of the ADC on the next falling edge, correct?).

So, I don't believe we have any difference in understanding.  

My MODE 0 works like a charm, so it must be good.

Nonetheless, one more time (as gruesome as this exercise is!):

START of read: CLOCK line is low.  CS is high.

CS goes low to start the conversion.  --> ADC sets MISO line to state of bit 16 (clocks out bit 16)

SPI transaction starts:

CLOCK goes high --> CPU reads in bit 16 which falling CS has placed on MISO.  --> ADC translates rising clock as a signal to convert the next bit  (assuming here that ADC doesn't touch the state of MISO until clock goes low, so it's safe to read)

CLOCK goes low --> ADC sets MISO line to state of bit 15 ("clocks out")

CLOCK goes high --> CPU reads in bit 15 --> ADC is signaled to convert the next bit
... and so on

Plus, from your comment regarding our first read being bogus, I should say above that the full conversion result it that of the prior conversion, not the current conversion (the current moment in time that our CS went low for this transaction).

I made a new diagram:



That's what I understand is happening.  It appears that our read should occur at a safe safe distance such that the line is stable. 

Hopefully after all this, what I describe here is correct!!!  Otherwise I should hang up my spurs and take on simpler work.

(My colleague had this running in mode 3 before, but had to bit shift, ect.. so I think we all suffered from a lack of clarity as to the AD7276's SPI timing.)

--

Regarding losing that first sample, it's somewhat unfortunate as timing is so tight already.  But we are looking at making our trigger more sensitive, and doing other things to satisfy the requirement.

Of course, it would still be sweet to have a device that reads continuously (as noted earlier).

Mark,

I think we're on the same page.....

I did get distracted and forgot about your request for a similar part that if I remember correctly allows you to take advantage of DMA for the data transfer.   

I think what you are essentially asking for is a part that could take your trigger as an enable to something like a conversion start pulse and then transfer the data itself (MASTER MODE) to the micro via a SPI DMA transfer.   Is that correct?  

Sean

Yes, that would be sweet. 

Otherwise, a part that samples continuously from which we can dump the data (upon receipt of our event trigger).  The part would require sufficient onboard memory to capture perhaps 1S of continuous sampling at 3MS/S. 

I'm not up on FPGA's... but is seems others have coupled one to their ADC and thereby produced a sampling system as I roughly described?

--

I am debugging the issue where the first read returns all 0's (or sometimes very low values).  In my test case, we are doing 15 successive reads, and all of these return bogus data.  The issue may be in firmware...  Should I open a new case for this item?

--

ps: I think we can explain the 010 and 101 transition data confusion in our earlier AD7276 testing.  If our SPI performs a read on the SCLK falling edge, whilst the AD7272 clocks out on that edge, would not a potential conflict occur?  Seems to me it would be a fight for "the fastest SPI processing wins".

My colleague reminds me that the AD7276 data sheet shows SCLK starting high.  We want to be certain that in MODE 0, in which SCLK is LOW in its resting state, the AD7276 won't be upset at us.  The last thing we need is an angry device. :)

I note the data sheet specifies time t2 (!CS to SCLK setup time).  Hopefully the polarity of SCLK is of no consequence.

Mark,

Atlernative Parts:

On this topic I can pretty much say for certain that we don't have any discrete ADC parts with on-board storage anything like you are proposing but we may offer uC with integrated ADCs that might do the job.  In the future we'll have integrated FIFOs but probably not anywhere as deep as you are looking for. 

Debugging Issue:

I thought all of this was working with the 14 burst DMA?  How is it that adding 1 more read causes all data words to fail?  Or am I missing something?   

Post Script:

Depends on the setup/hold timing relative to the timing on the uC.  Moving to the rising edge definitely avoids any potential timing issues.

Sean

@skowalik said:

I thought all of this was working with the 14 burst DMA?  How is it that adding 1 more read causes all data words to fail?  Or am I missing something?   

Hello Sean,

That's the weird part.. if I call my 14 reads once, they all return 0 or very low values.  If I call my 14 read process twice, the first is still bogus, but the second works fine.

I think this is on my end... just wondered if you might think it's related somehow to the issue you mentioned earlier where the result of our first !CS sequence gets clocked out on the next !CS sequence.  

     It might be worth verifying this is correct by continuously capturing your current test pulse for 2 or 3          successive pulses just to make sure I'm correct.

I'm planning to run such a test.  I can't locate any mention of a delay in result in the data sheet.  Rather, it says, 

The input signal is sampled on the falling edge of CS, and the conversion is initiated at this point. There are no pipeline delays associated with the part.

So I thought what's clocked out is the ADC value that's present when CS goes low.  Wrong?

--

On the PS: We are good on timing.  The only thing hanging on is my second note regarding starting out with SCLK low.  Is SCLK idling HIGH a fixed requirement?  I'd rather take it from the experts regarding SCLK requirements during CS assertion.. although things appear to be working OK in the present situation.

/m

Sean,  This has been a very interesting journey so far, and we are still working this problem.  One of the angles we are exploring has to do with layout, grounding, and noise isolation.

Regarding layout, and looking at the AD7276 evaluation board docs online, there are no PC board layout files.  We'd like more guidance on "The recommended layout for the AD7276/AD7277/AD7278 is outlined in the evaluation board documentation".  If we can get hard files, such as gerbers or prints in a pdf, that would be fantastic.

Sean,  This has been a very interesting journey so far, and we are still working this problem.  One of the angles we are exploring has to do with layout, grounding, and noise isolation.

Regarding layout, and looking at the AD7276 evaluation board docs online, there are no PC board layout files.  We'd like more guidance on "The recommended layout for the AD7276/AD7277/AD7278 is outlined in the evaluation board documentation".  If we can get hard files, such as gerbers or prints in a pdf, that would be fantastic.

Mark,

I have reached out to a colleague who may have the records you are looking for.   Hopefully he is not yet on holiday.   As you may or may not know ADI will be closed at the end of business tomorrow 12/20/19 and will reopen on 01/06/20.   Hopefully we can get the files tomorrow but if not we can always find out a secure way to have you send me your files and I can have a look for you to see if there isn't anything I can recommend.

Sean

Sean, thanks again.  pdf's of the layout would be just fine, if these can be made available.  We'd prefer to base our layout on what Analog Devices proven design.  

Given our results are now much improved using an evaluation board (despite several versions of our own home-brewed platforms), we're becoming convinced that our issues live in layout, grounding, bypassing, etc.

Mark,

See attached pdf.

Have a great Holiday.

Sean

PDF

Now my colleague is asking for a BOM and schematic :)  Sorry.  Is that available for the Eval?

See attached.

PDF

XLSX