Searching \ for '[EE]: Bug in LTC2400 SPI interface' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serial/spis.htm?key=spi
Search entire site for: 'Bug in LTC2400 SPI interface'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: Bug in LTC2400 SPI interface'
2000\11\04@083702 by Morgan Olsson

picon face
This week we proved a stupid bug lurking in the SPI interface in the well-known LTC2400 analog to digital converter from Linear Technology.
(tested chips produced week 41, 1998)
Anyone else noticed?

We would really appreciate any experience input.
(first read all below of course)


*Short description*
The error occours when using the polled mode, i.e activating the CS (Chip Select) to read the EOC flag (End Of Conversion) that LTC2400 then as response outputs in the SDO pin, then if it is ready we read out the result, if it is not we deactivate CS and later test again.

It then, very rarely, and not in all implemetations, happen, that the 32 bit data comes in one bit too early.  Very funny, eh?

First we thought the failure was due to hardware or software error made by us, as it is a little complicated with multiple interrupts, and other SPI devices on the same pins.
We found after two weeks of lurking, redesigning both hardware and software, looking for every kind of pulse glitches, ringiging, SPI device queing, made separate test setups, blabla etc,........ that:  If, when EOC is signalled by the LTC2400, and we deactivate CS anyhow, and later activate CS and read out, that the data stream comes out one bit early.

We normally read data out as soon as it is ready, but in reality, when the PIC selects the LTC2400, read ther LTC2400 is not ready, but then LTC2400 get ready before the PIC releases chip select again, then the LTC2400 erroneously shifts the data.

What fooled us for a while was that in the original prototype we only got erroneous results when other parts of the system interrupted the PIC, but that was because the interrupts introduced timing jitter so the above scenario was fulfilled.  We used timer ticks to drive the SPI and without other interrupts we happened to never ask close in time to when the LTC2400 got to end of conversion.

We can even restart the conversion by pulsig the -CS high to times after detected EOC, with clock low all time, also that behaviour is against the datasheet.

We have this week contacted LT, but they don´t recognise the problem, but mentioned in a uclear way that there exist a timing constraint on hte CS signal of, to be sure 100µs.  Even with the test program at 100µs between every signal change the problem is the same.

We have recieved new samples, but must now rush on with this and other delayed  projects, have no time to evaluate them right now.  Anyway, if the problem is fixed in later versions, we might get old stocked parts in production, so we better make the design work with bogous parts also, and it seem to work reliably just we do not poll the LTC2400, but use an dedicated timer as described above instead.
We are now sending a very detailed report to LT, which the chip designer will look into.

The bogous LTC2400 we have tested have the following markings:
Top:
(LT-logo)841  (mfg year 1998 week 41)(got them as samples a year ago)
2400

Bottom:
N73
957

I will post updates on this subject to this list.

This is the third in row ADC we have been bitten by: first a never documented bug in earliest versions of PIC14000 (A/D clock select locked to internal osc, problem gone without notice in later versions), then MAX110/111 non-exitable undocumented test modes that it could get stuck in after random noise in SPI bus, and now the LTC2400 polled mode bug.
I thought the digital side is the easy part of an A/D converter...
Spooky feeling!
Why the ¤$#@%! don´t theese companies document severe lurking problems?
Maybe they think erratas scare customers, but don´t we trust companies giving erratas more, than those trying to hide the problems, which then wrecks our products?  Or do they think it look bad to stock traders?

From now on we´re really gonna hard test any digital cirquit before we put in our design, not trust any data sheet, assuming there might be a bug anywhere, in some mode, from any angle, some timing, etc, and demand always getting the latest samples even if there are no announced bug.  And never in production use elder parts than the samples.

Time consuming, but our products must be reliable.

We probably need to go back to design more using analog parts and simple logics.  Never had any problems there.  Only had problems with hardware in converters and controllers...
Back to basics :(
Madness!
AARGH!
/Morgan
Morgan Olsson                   spam_OUTmorgans.rtTakeThisOuTspamtelia.com
Morgans Reglerteknik, Hällekås, 277 35 KIVIK, SWEDEN
   tel +46(0)414-446620, fax +46(0)414-672324

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\04@110145 by Dan Michaels

flavicon
face
Morgan Olsson  wrote:
>
>*Short description*
>The error occours when using the polled mode, i.e activating the CS (Chip
Select) to read the EOC flag (End Of Conversion) that LTC2400 then as
response outputs in the SDO pin, then if it is ready we read out the result,
if it is not we deactivate CS and later test again.
>
>It then, very rarely, and not in all implemetations, happen, that the 32
bit data comes in one bit too early.  Very funny, eh?
............
>

Hello Morgan,

I am not sure this pertains to what you are seeing, but the LTC1400/1404 chips
have the following constraint on CS and Sclk timing:

"If the time from CONV signal to CLK rising edge is less than
t2, the digital output will be delayed by one clock cycle".

t2 is spec'ed at 80 nsec minimum - should not be a problem with a PIC, even
running 20 Mhz.

There are also some constraints on how long the CS pulse can be - as
related to accuracy of the final result.

regards,
- Dan Michaels
Oricom Technologies
http://www.users.uswest.net/~oricom
===================================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\04@133427 by Dan Michaels

flavicon
face
Morgan Olsson  wrote:
>
>*Short description*
>The error occours when using the polled mode, i.e activating the CS (Chip
Select) to read the EOC flag (End Of Conversion) that LTC2400 then as
response outputs in the SDO pin, then if it is ready we read out the result,
if it is not we deactivate CS and later test again.
>
>It then, very rarely, and not in all implemetations, happen, that the 32
bit data comes in one bit too early.  Very funny, eh?
............
>

Hello Morgan,

I had a couple of other thoughts - that again may have no relationship
to your problem - but may give you some ideas. You may possibly have
a layout/grounding/ringing problem.

I have been using the LTC1404, 12-bit, 600ksps A/D. Like the LTC2400,
it has only 8-pins and does not have "separate" analog and digital gnd
pins. I use it on a pcb where it is driven alternately by a PIC and
Scenix. The SX can run the chip at max SPI rate of 6.5 Mhz, while
the PIC cannot. Unfortunately, the SX tracks are about 2.5" [7 cm]
long - I cannot get the layout any better.

Well, on "some" pcbs, SX control has been a little flaky. I suspected
ringing, but every time I put the scope probe on an A/D pin, the problem
would disappear. I found several ways to deal with it, but each "fix"
would work on some pcbs only, but not on others:

a) RC filter in the sclk line at the A/D - 330 ohm, 27 pF.
b) 2.2K termination on the conv line at the A/D.
c) placing finger on the A/D SPI pins - [not field-installable].

Since I have separate analog and digital supplies and gnds on the
pcb, single-point-connected back at the power entry point, and
since the LTC1404 does not have separate analog and digital gnd
pins, I thought there may be large inductive loops related to the
SPI tracks, so I also tried:

d) locating the single-point analog-digital gnd connection directly
  under the A/D, rather than at power entry.

You are probably running a much slower clock than I am, but maybe
my experiences will give you some ideas.

[BTW, I just figured out what the problem with "my" pcb is - very
embarassing too - at least this thread helped one of us].

best regards,
- Dan Michaels
Oricom Technologies
http://www.users.uswest.net/~oricom
===================================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\04@150853 by Morgan Olsson

picon face
Dan Michaels wrote:
{Quote hidden}

So to be safe, we need a delay of minimum of what t2 may be maximum.

>t2 is spec'ed at 80 nsec minimum - should not be a problem with a PIC, even
>running 20 Mhz.

But what is t2 maximum?
(Or maybe I did not understand your explanation?)

I have there tried a ridiculous 200 cycle delay @ 4MHz Xtal= 0,2 milliseconds - and experience no difference from using just a few cycles.

>There are also some constraints on how long the CS pulse can be - as
>related to accuracy of the final result.

On the LTC2400 it shold not matter, according to design.


Thanks for the quick input

Experiences of LTC2400 in polled mode, anybody?

Maybe the bug is gone in later produced chips?
Then the question is, from which date... (to make sure we do not buy the elder bogus ones.)

Now, I have on my table two LTC2400 manufactured 1999 week 31, I´ll try to find time to test them the coming week.

Regards
/Morgan

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\04@163726 by Morgan Olsson

picon face
Dan Michaels wrote:
>I had a couple of other thoughts - that again may have no relationship
>to your problem - but may give you some ideas. You may possibly have
>a layout/grounding/ringing problem.

Negative. for testing I even put only the LTC2400 and PIC on a small PCB one cm apart, signals parallel to GND, good decoupling on VCC.  Exactly the same.

Good point though.

-snip-

>driven alternately by a PIC and
>Scenix.

Nice :)

{Quote hidden}

Try impedance matching the sender instead: putting an resistor in series with the driver of equal resistance as the line impedance, makes the incident wave travelling down to the reciever have half the voltage step, but the moment it reaches the reciever it is full step.

Assuming a theoretical open end at reciever.
No overshoot, no ringing, low EMI.
Incident wave theory: (I learnt on a seminar some time ago)


1) Initial:
Sender side
 5V 2.5V                          Reciever side
 0V ------------------------ 0V


2) Sender change fom 0V to 5V, driver resistance = line impedance make the step change by the driver only half of that.  The pulse (incident wave) start travelling with the "speed of light"
Sender side
 5V      pulse travels->
2.5V -------.                 Reciever side
 0V         '--------------- 0V


 5V      pulse travels->
2.5V -------------------.     Reciever side
 0V                     '--- 0V

3) The chande at the "open end" seen by the wave at the end of the transmission line make the pulse mirrored, this creating a 2x2,5V = 5V step!

2) Pulse mirrored at the theoretically "open" reciever side
Sender side
 5V                       ,- 5V
2.5V ---------------------´   Reciever side
 0V      pulse travels <-
Sender side
 5V   ,--------------------- 5V
2.5V -´                       Reciever side
 0V   mirrored pulse reaching sender


4) Now at first, the current in the sender is zero.
The wave coming back has the same voltage as the sender, thus no ringing,
everything stable.
Sender side
 5V ------------------------ 5V
2.5V                          Reciever side
 0V
Now, if we could measure impedance exactly, know every capacitance, zero losses etc, life would be simple...
         
But in practice exact matching is difficult, and the reciever at least have a few pf capacitance, so practical solution I believe is to have the driver series resistance slightly lower than line impedance ( = slight overdrive), and a very light damping at the reciever consisting of a resistor of about 2x impedance i series with a few pf to GND?

I have tried this on longer lines, and it worked, but I have not been able to veryfy exactly why as my oscilloscope is too slow.

>c) placing finger on the A/D SPI pins - [not field-installable].

Mix some carbon dust with rubber mixture and pour over...?

(joke of course)

-snip-

>[BTW, I just figured out what the problem with "my" pcb is - very
>embarassing too - at least this thread helped one of us].

Nice to hear :)

Explaining problems to other often helps oneself seeing what one have done.

Best regards
/Morgan

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\04@192802 by Dan Michaels

flavicon
face
wrote:

>>a) RC filter in the sclk line at the A/D - 330 ohm, 27 pF.
>
>Try impedance matching the sender instead: putting an resistor in series
with the driver of equal resistance as the line impedance, makes the
incident wave travelling down to the reciever have half the voltage step,
but the moment it reaches the reciever it is full step.
>

That is in there too.
============

>>c) placing finger on the A/D SPI pins - [not field-installable].
>
>Mix some carbon dust with rubber mixture and pour over...?
>
>(joke of course)
>

Got to be either R(finger) or C(finger) - I doubt my finger has
much inductance.
==============

{Quote hidden}

Alright - turns out after making my first post to your problem,
I went back and looked at my Scenix code. Sclk changes exactly
33.33nsec after Conv - far less than 80nsec. Add in a little
capacitance in the 7mm track, and ---> flaky ops. I now see that
the behavior I was observing was related to when the 1st bit was
sensed by the Scenix.

Your problem reminded me of the timing thing - which I had obviously
forgotten when I wrote the code. Haven't tried it yet, but I am sure
this is the problem.

Thanks for finding my error :-).
- danM

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\04@192818 by Dan Michaels

flavicon
face
Morgan Olsson  wrote:
........
>>
>>"If the time from CONV signal to CLK rising edge is less than
>>t2, the digital output will be delayed by one clock cycle".
>
>So to be safe, we need a delay of minimum of what t2 may be maximum.
>
>>t2 is spec'ed at 80 nsec minimum - should not be a problem with a PIC, even
>>running 20 Mhz.
>
>But what is t2 maximum?
>(Or maybe I did not understand your explanation?)
>
>I have there tried a ridiculous 200 cycle delay @ 4MHz Xtal= 0,2
milliseconds - and experience >no difference from using just a few cycles.


I imagine t2 "minimum" is spec'ed because you might otherwise get
a race condition inside the chip. Controls when the 1st bit is
processed by the successive approximation logic and sent out the
SPI port.

- danM

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\07@112711 by Tom Handley

picon face
  Morgan, thanks for sharing that! I've been using a couple of LTC2400s in
a PIC-based DAQ system that has been running about a year. In my case, I use
the External SCK/Single Cycle mode rather than the polling the EOC Bit. I
don't know what your requirements are but it's a lot easier to monitor EOC.
You simply do the following:

     - Set SCK Low.
     - Set /CS Low.
     - Wait for SDO to go Low.

  As far as timing, I'm using a 16F877 at 20MHz. Assuming EOC is complete
and SDO is Low, there is a 1us delay from the falling edge of /CS to the
rising edge of the first SCK pulse. The SCK pulse-pulse delay is 2us. This
was added during testing and I never tried to speed it up.

  - Tom

At 02:34 PM 11/4/00 +0100, Morgan Olsson wrote:
>This week we proved a stupid bug lurking in the SPI interface in the
>well-known LTC2400 analog to digital converter from Linear Technology.
>(tested chips produced week 41, 1998)
[Bug description snipped]


------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu




2000\11\07@141806 by Morgan Olsson

picon face
Tom Handley wrote:

>   Morgan, thanks for sharing that! I've been using a couple of LTC2400s in
>a PIC-based DAQ system that has been running about a year. In my case, I use
>the External SCK/Single Cycle mode rather than the polling the EOC Bit. I
>don't know what your requirements are but it's a lot easier to monitor EOC.

It is, but I am saving pins for future use, and have to time-interleave a few SPI devices on the MSSP module.  The SPI communication wil intruduce a slight noise based error on the measuremet, but we do not need extreme precision.  Maybe just a few designers use the polled mode because of the introduced noise, and therefor the bug has not been detected?

-snip-

>  As far as timing, I'm using a 16F877 at 20MHz. Assuming EOC is complete
>and SDO is Low, there is a 1us delay from the falling edge of /CS to the
>rising edge of the first SCK pulse. The SCK pulse-pulse delay is 2us. This
>was added during testing and I never tried to speed it up.

I have experimentally run at 1MHz clock, no problem. That was the highest speed "Xtal/4" i could get in the MSSP module at my 4MHz Xtal. I am normally running it at /16.

>At 02:34 PM 11/4/00 +0100, Morgan Olsson wrote:
>>This week we proved a stupid bug lurking in the SPI interface in the
>>well-known LTC2400 analog to digital converter from Linear Technology.
>>(tested chips produced week 41, 1998)
>[Bug description snipped]


Not yet any response from LT on my bug description.
I plan tomorrow to test if the bug is till left in a newer chip revision.

Regards
/Morgan

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu




More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...