AD7793 error?

[jmariano]

Dear All,

I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using an Aduino Due (SAM3X8E) connected to the ADC through SPI with CS permanently tied low. I use the Arduino's SPI library to control the SPI UART and AD's library (available on-line) to access the ADC.

After correcting a couple of bugs in both libraries, I'm able to read the AD7793 on-chip registers but something wired happens. From two of them, I don't get the values sated on the datasheet. Were's what I get (power-on defaults):

Register Datasheet I get
-----------------------------
ID 0xXB 0x4A <- datasheet states that ID code for 7792 is 0xXA
STATUS 0x88 0x48
IO 0x00 0x00
MODE 0x000A 0x000A
CONF 0x0710 0x0710
OFFSET 0x800000 0x800000
FULLSCALE 0x5XXX00 0x54BB00

Do you thing this could be a mistake on the datasheet or is something wrong in my code? (I really don't have a clue!)

Regards

jmariano

[rickman]

I think there is something wrong with your post. Your data table shows
the actual value read as 0x4A and you are complaining that it should be
0xXA according to the data sheet. But the datasheet column shows 0xXB
for that value. Do you have your columns mixed up in your post perhaps?

--

Rick

[Phil Hobbs]

On 7/25/2014 2:50 PM, jmariano wrote:

Good news: you just misread the datasheet. The AD7793 is supposed to
respond "0xXB".

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

[rickman]

Ah, I just saw what you are talking about. You are saying the return
value you are reading corresponds to a different part! I missed that
before.

Check the data sheet for the 7792 and see if the status value matches.
Maybe a part was mislabeled somehow or maybe these parts are the same
die tested to different specs using a laser trim to set the ID code?

--

Rick

[jmariano]

Hi,

Thanks for the help.

The 7792 is basically the same as the 7793, the only difference being the number of bits - 92 is 16 and 93 is 24. The datasheet for both parts is actuality the same.
At first I was convinced that I was having a timing error since the difference from A to B is the LSB, but if this is true, I don't understand why i'm reading 0x48 instead of 0x88 on the status reg (now the difference is on the two MSB) and all the others are being read correctly.

On the other hand, if this is an error on the datasheet, AD would have switched the ID codes for both parts (so 92 would be B and 93 A) and wrongly stated the default value of the status reg (should be 48 instead of 88).

So, before I plunge into the code armed with a scope, my question for you more experienced guys is: do you think this could be just an error on the datasheet?

Regards

jmariano

[John Larkin]

We use the AD7793 in several products, over 3000 pieces so far, and
they work great. But we just read the analog value and ignore the ID
and status registers. The 7792 and 7793 are probably the same chip
inside, with some bits zapped or something.

ADI is making more errors on their data sheets than they used to, and
seldom corrects them. Just got burned on the ADR363.

Why are mixed-signal part data sheets so terrible?


--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

[Maynard A. Philbrook Jr.]

In article <gjq5t9do42boqbhpp...@4ax.com>,
jla...@highlandtechnology.com says...

They're just testing the audience to see how many actually read them!

Jamie

[rickman]

I don't have the data sheets here so I can't keep up with the values and
part numbers. But I believe you are saying your ID matches the '92 and
not the '93 while the status value does not match either part. I'm not
clear on the status reg when you say the "default" value. What is the
meaning of the bits that are different?

It has been a while since I've used SPI, but I seem to recall there is a
signal that controls the framing. Isn't that the CS? There is a clock,
data in and data out then the CS strobe says all the data has been
shifted in so latch it, no? You say you aren't using CS, does that work?

--

Rick

[Steve Goldstein]

On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin
<jla...@highlandtechnology.com> wrote:

>
>Why are mixed-signal part data sheets so terrible?

IMO it's because the parts can be very complicated, and the datasheets
are often not written by the designers but by apps people, frequently
younger engineers, who just aren't as familiar with their intricacies.
Designer reviews are often cursory because many designers think this
work is boring or beneath them and don't take it seriously. And these
are _all_ engineers, who often lack technical writing skills.

I've been working on a datasheet for a fairly complex mixed-signal
product for much of the last two months, and intermittently for
several months before that. It's now at 112 pages, and still only
covers internal stuff we need to guide the design team, like register
and functional definitions. It doesn't yet include the required
customer-facing things like detailed specifications, applications
data, and performance plots (that have to wait for silicon). It's
based on several successful prior product generations, so I can re-use
parts of those earlier datasheets, but *every* section so far has
required extensive data table and text changes to cover the expanded
functionality of the new product; it's safe to say that I've had to
modify every paragraph for content, clarity, and accuracy. The public
datasheet will be a bit shorter because I can remove the proprietary
internal and DFT stuff. I *am* the (lead) designer, and still find
errors during reviews of what I thought were completed sections.

Writing a good datasheet is surprisingly hard work. It's a pity that
more companies (and engineers) don't recognize the importance of the
task and treat it with the respect it deserves.

[k...@attt.bizz]

On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein
<sgol...@alum.mit.edu> wrote:

>On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin
><jla...@highlandtechnology.com> wrote:
>
>>
>>Why are mixed-signal part data sheets so terrible?
>
>IMO it's because the parts can be very complicated, and the datasheets
>are often not written by the designers but by apps people, frequently
>younger engineers, who just aren't as familiar with their intricacies.
>Designer reviews are often cursory because many designers think this
>work is boring or beneath them and don't take it seriously. And these
>are _all_ engineers, who often lack technical writing skills.

More likely, they're overworked and have other fish to fry. Checking,
particularly other people's work, is the first thing to go out the
window.

>I've been working on a datasheet for a fairly complex mixed-signal
>product for much of the last two months, and intermittently for
>several months before that. It's now at 112 pages, and still only
>covers internal stuff we need to guide the design team, like register
>and functional definitions. It doesn't yet include the required
>customer-facing things like detailed specifications, applications
>data, and performance plots (that have to wait for silicon). It's
>based on several successful prior product generations, so I can re-use
>parts of those earlier datasheets, but *every* section so far has
>required extensive data table and text changes to cover the expanded
>functionality of the new product; it's safe to say that I've had to
>modify every paragraph for content, clarity, and accuracy. The public
>datasheet will be a bit shorter because I can remove the proprietary
>internal and DFT stuff. I *am* the (lead) designer, and still find
>errors during reviews of what I thought were completed sections.

Processor architecture documents are similar. A few thousand pages is
certainly not unusual. The public datasheets that large are common.
Ours were written by the architects, then rewritten by the designers,
and again by the verification engineers.

>Writing a good datasheet is surprisingly hard work. It's a pity that
>more companies (and engineers) don't recognize the importance of the
>task and treat it with the respect it deserves.

Apparently, it's often done after the part is cooked. That never
works out.

Anyone else notice that Asian and European datasheets are particularly
bad? Content free. It's not just the translation (but that's a part
of it).

[John Larkin]

On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein <sgol...@alum.mit.edu>
wrote:

The analog parts of things like ADCs and DACs are usually pretty good. It's the
digital sections, like the SPI interfaces, that can be really awful.. both in
design and in documentation. The timing diagrams are often horrors.

We use one ADI chip that has an SPI command to change which clock edge the SPI
interface works on! I have a product that used a Burr-Brown ADC, which TI has
replaced with a "drop-in equivalent." Except that I used to use \CS to select
the chip, and now the appnotes all ground \CS.

Writing a good manual is hard work, too. Lots of examples, rather than
abstraction and meta-expressions, helps. A "quickstart" example would be great:
"To make this DAC work like a DAC, do this...". Hey, how about a Windows program
that asks you what you want to so, and furnishes the exact data (and waveforms)
that will do it? I've done things like that for some of our products.

112 pages is impressive, but it suggests that the part is very complex. In some
mixed-signal parts, like ADCs, they are way too complex. I don't need an ADC to
have a complex internal calibration subsystem; I will do calibrations in the uP
or FPGA. It's crazy to have a DAC that has pages and pages of (typically
confusing) documentation about dozens of internal registers.



--

John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation

[John Larkin]

The NXP ARM chips are good, but the documentation is often terrible. I think
lots of chips nowadays include purchased IP blocks, like Ethernet or ADCs or
whatever, that come with their own style and quality of documentation.

How much current does the ADC in that ARM chip use? Nobody knows. And you futz
with the queued SPI interface until it works.

[Andy Bartlett]

"jmariano" <jmari...@gmail.com> wrote in message
news:95516264-0d30-4a8c...@googlegroups.com...

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


If you have (n)CS permanently low on an SPI link the device cannot
synchronise. I assume you are trying to use a gated burst on the SPI clock?

Normally the device synchronises on the first edge after the nCS line drops-
otherwise you effectively have the devices input and output shift registers
potentially misaligned to your expected data.

Andy

[k...@attt.bizz]

I was thinking about NXP (and ST) in particular when I included the
Europeans. Their datasheets are, um, skimpy.

>How much current does the ADC in that ARM chip use? Nobody knows. And you futz
>with the queued SPI interface until it works.

If you think that's bad, try their RF chips. They intentionally hide
the innards so they have to do pretty much everything. TI has been
known to have undocumented registers, too. The designers don't even
know what they do ("try all the combinations").

[Tim Williams]

<k...@attt.bizz> wrote in message
news:lfb7t9pd3f0mldv7k...@4ax.com...

> Anyone else notice that Asian and European datasheets are particularly
> bad? Content free. It's not just the translation (but that's a part
> of it).

Here's an amusing example I ran across recently:
http://www.adafruit.com/datasheets/WS2812B.pdf
Note the power supply voltage: remind you of a certain Sandra Bullock
movie? What happens when it drops below ...

The formatting is just janky, clearly a novice writing in Word.

The mech / layout drawings have text going every which way; the "VDD 5
DOUT" with the 5 backwards, especially.

Good luck with those timings.

Tim

--
Seven Transistor Labs
Electrical Engineering Consultation
Website: http://seventransistorlabs.com

[Tim Williams]

<k...@attt.bizz> wrote in message
news:fjp7t956dub6gpcii...@4ax.com...

> If you think that's bad, try their RF chips. They intentionally hide
> the innards so they have to do pretty much everything. TI has been
> known to have undocumented registers, too. The designers don't even
> know what they do ("try all the combinations").

Most people boggle their mind over the NSA/GHCQ's demilling of The
Guardian's laptops (the ones they had Snowden docs on), the obscure chips
they ground away -- PSU controllers and stuff.

Doesn't seem strange to me. Many of those have low-functionality
registers (i.e., poking bits into them doesn't put 5V on the CPU core or
something drastic like that), that are easily acessible (via SMBus, etc.),
which could be used to store information in a somewhat obscure way. Not
much of course, but enough for a key at least. And taken over the whole
system, probably enough for a message.

As for undocumented registers, certainly there are things the
manufacturers put in there for their own purposes; whether they're locked,
invisible, functional or what, who knows; but it's likely the NSA has some
ideas.

Easily possible the NSA even has them synthesizing extra bits, or
allocating otherwise-unused corners of array memory, for clandestine
purposes.

Even if they don't have design information from the manufacturer (or from
decapping and inspecting the chip), it's probably enough that it's a
possibility, even if they don't have it as a capability.

As for destruction, even if the registers are SRAM or DRAM, they can
retain info between power cycles, so they might go out of their way to
destroy anything stateful, just in case.

[rickman]

On 7/26/2014 9:40 AM, k...@attt.bizz wrote:
> On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein
>

>> Writing a good datasheet is surprisingly hard work. It's a pity that
>> more companies (and engineers) don't recognize the importance of the
>> task and treat it with the respect it deserves.
>
> Apparently, it's often done after the part is cooked. That never
> works out.
>
> Anyone else notice that Asian and European datasheets are particularly
> bad? Content free. It's not just the translation (but that's a part
> of it).

I was working with one of the Atmel MCUs and realized they had no spec
on the crystal. So I had nothing to provide to the crystal company to
make sure I got a crystal that would work. I asked the FAE for info on
this and it ended up with some data added to the data sheet. However,
they gave the info for four specific frequencies in the range without
specifying which values should be used between those frequencies. lol

Once they made a change to the data sheet, I guess it was enough work
that they weren't going to fill in the blanks. They probably have to go
through a review process that means a 5 minute change to the document
takes many man hours of work.

--

Rick

[Jasen Betts]

On 2014-07-26, Tim Williams <tmor...@charter.net> wrote:
><k...@attt.bizz> wrote in message
> news:lfb7t9pd3f0mldv7k...@4ax.com...
>> Anyone else notice that Asian and European datasheets are particularly
>> bad? Content free. It's not just the translation (but that's a part
>> of it).
>
> Here's an amusing example I ran across recently:
> http://www.adafruit.com/datasheets/WS2812B.pdf
> Note the power supply voltage: remind you of a certain Sandra Bullock
> movie? What happens when it drops below ...
>
> The formatting is just janky, clearly a novice writing in Word.


> The mech / layout drawings have text going every which way; the "VDD 5
> DOUT" with the 5 backwards, especially.
>
> Good luck with those timings.

"VDD DOUT" are pin labels "5" is a dimension (5mm)




--
umop apisdn


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[rickman]

On 7/26/2014 6:18 PM, Jasen Betts wrote:
> On 2014-07-26, Tim Williams <tmor...@charter.net> wrote:
>> <k...@attt.bizz> wrote in message
>> news:lfb7t9pd3f0mldv7k...@4ax.com...
>>> Anyone else notice that Asian and European datasheets are particularly
>>> bad? Content free. It's not just the translation (but that's a part
>>> of it).
>>
>> Here's an amusing example I ran across recently:
>> http://www.adafruit.com/datasheets/WS2812B.pdf
>> Note the power supply voltage: remind you of a certain Sandra Bullock
>> movie? What happens when it drops below ...
>>
>> The formatting is just janky, clearly a novice writing in Word.
>
>
>> The mech / layout drawings have text going every which way; the "VDD 5
>> DOUT" with the 5 backwards, especially.
>>
>> Good luck with those timings.
>
> "VDD DOUT" are pin labels "5" is a dimension (5mm)

The point is that you turn your head one way to read the dimensions and
turn your head the other way to read the labels. The convention is to
turn the text counter clock wise or not at all, not to turn anything
clockwise. Some times this happens because an image is drawn the
correct way but then rotated to fit on the page better. The choices
then are to have some text rotated clockwise or to have some text upside
down. I guess the clockwise text is preferred. In this case the labels
did not need to be rotated at all. Also the dimensioning lines are not
drawn properly... I expect this was drawn by someone inexperienced using
conventional drawing tools.

--

Rick

[k...@attt.bizz]

On Sat, 26 Jul 2014 15:10:16 -0500, "Tim Williams"
<tmor...@charter.net> wrote:

><k...@attt.bizz> wrote in message
>news:fjp7t956dub6gpcii...@4ax.com...
>> If you think that's bad, try their RF chips. They intentionally hide
>> the innards so they have to do pretty much everything. TI has been
>> known to have undocumented registers, too. The designers don't even
>> know what they do ("try all the combinations").
>
>Most people boggle their mind over the NSA/GHCQ's demilling of The
>Guardian's laptops (the ones they had Snowden docs on), the obscure chips
>they ground away -- PSU controllers and stuff.
>
>Doesn't seem strange to me. Many of those have low-functionality
>registers (i.e., poking bits into them doesn't put 5V on the CPU core or
>something drastic like that), that are easily acessible (via SMBus, etc.),
>which could be used to store information in a somewhat obscure way. Not
>much of course, but enough for a key at least. And taken over the whole
>system, probably enough for a message.
>
>As for undocumented registers, certainly there are things the
>manufacturers put in there for their own purposes; whether they're locked,
>invisible, functional or what, who knows; but it's likely the NSA has some
>ideas.

Undocumented, sure. We had registers the users knew nothing about but
none were user accessible. That's not what I was talking about,
though.

>Easily possible the NSA even has them synthesizing extra bits, or
>allocating otherwise-unused corners of array memory, for clandestine
>purposes.
>
>Even if they don't have design information from the manufacturer (or from
>decapping and inspecting the chip), it's probably enough that it's a
>possibility, even if they don't have it as a capability.
>
>As for destruction, even if the registers are SRAM or DRAM, they can
>retain info between power cycles, so they might go out of their way to
>destroy anything stateful, just in case.

All completely irrelevant.

[Tim Williams]

"rickman" <gnu...@gmail.com> wrote in message
news:lr1dl7$emv$1...@dont-email.me...

> The point is that you turn your head one way to read the dimensions and
> turn your head the other way to read the labels. The convention is to
> turn the text counter clock wise or not at all, not to turn anything
> clockwise. Some times this happens because an image is drawn the
> correct way but then rotated to fit on the page better. The choices
> then are to have some text rotated clockwise or to have some text upside
> down. I guess the clockwise text is preferred. In this case the labels
> did not need to be rotated at all. Also the dimensioning lines are not
> drawn properly... I expect this was drawn by someone inexperienced using
> conventional drawing tools.

Yes, clarity would include a leader to indicate the connection between the
number and the dimension. And calling it "5.0" would be even better --
makes it obvious it's not a pin number or something.

I don't actually mind the colors, but the traditional complaint would be,
they won't always come through e.g. on photocopies (yes, those things
still exist). If it's clear in monochrome, you don't have to worry about
anything else.

[Steve Goldstein]

On Sat, 26 Jul 2014 07:20:49 -0700, John Larkin
<jjla...@highNOTlandTHIStechnologyPART.com> wrote:

...snippage...

>
>112 pages is impressive, but it suggests that the part is very complex. In some
>mixed-signal parts, like ADCs, they are way too complex. I don't need an ADC to
>have a complex internal calibration subsystem; I will do calibrations in the uP
>or FPGA. It's crazy to have a DAC that has pages and pages of (typically
>confusing) documentation about dozens of internal registers.

Yes, it is a complex part, two chips in a single package that play as
one from the customer's view. Both die are accessible via the
(single) SPI, and there is situation-dependent information exchange
between them. There are no ADCs, but a lot of interesting pure-analog
functionality, quite a few DACs, and registers and state machines to
control it all. The die are not small.

Often nowadays you _do_ need an ADC to have a complex internal
calibration subsystem, though you may not realize it. Modern ADC
architectures, especially those using fine-line processes, are often
not even usable without a lot of internal self-calibration. This
requires intimate knowledge of their powerful internal magic that the
manufacturers are not about to divulge. Fortunately, transistors in
these processes are small and cheap, so the cal engine can be put
on-chip. Given everything else the cal machine does, the incremental
cost of gain and offset calibration is often trivial. Of course, such
calibration often only takes care of the ADC errors alone and you're
still left with the rest of the signal channel to worry about, so I
can understand why you don't value the cal engine very highly.

As far as DACs and other things with a bazillion registers, the
economics of chip design and manufacturing often come into play. You
want to make a few parts that will capture as many sockets as
possible; development cost is now too high to do otherwise. I agree
the manufacturers certainly could spend a little more time and money
(a pittance in the grand scheme of things) to de-confuse datasheets
and make them actually useful. This has been my personal crusade
since I first got hosed by a datasheet back around 1985. You can bet
that the datasheets for my parts are as clear, accurate, and
well-written as I can make them, whether I do the actual writing or,
more usually, a significant amount of rewriting. It's what I would
expect if I were the customer.

[koder]

jmariano, could you upload your corrected SPI and AD`s library?

[John Larkin]

On Thu, 15 Dec 2016 11:55:29 -0800 (PST), koder
<ptmis...@gmail.com> wrote:

>jmariano, could you upload your corrected SPI and AD`s library?

The SPI interface of AD7793 is hopelessly trashed. Use ADS1247.

--

John Larkin Highland Technology, Inc

picosecond timing precision measurement

[Phil Hobbs]

On 12/15/2016 04:11 PM, John Larkin wrote:
> On Thu, 15 Dec 2016 11:55:29 -0800 (PST), koder
> <ptmis...@gmail.com> wrote:
>
>> jmariano, could you upload your corrected SPI and AD`s library?
>
> The SPI interface of AD7793 is hopelessly trashed. Use ADS1247.
>
>

I notice that you're piling in the extra chromosomes there. Kudos.

Cheers

Phil Hobbs

[John Larkin]

If there are enough bad google links, maybe they will actually fix the
stupid part.

(But we know they won't.)

--

John Larkin Highland Technology, Inc

lunatic fringe electronics