ADS8330 NON-A version bug list?

Hi Dennis,

Can you tell me what the actual top side marking on the ADS8330 parts you have is?  The design changed in late 2009 to 'A' to accomodate a potential problem with the power on reset cell.  That change should not have had any impact on your ability to manually select channels.  There really is no 'known bug' list to share with you.  I will send along a copy of the document describing the changes in a seperate e-mail. 

Hi Tom,

Working ADS8330
8330I A
TI 02K
A2JJ

NOT-Working ADS8330
8330I
TI 6AK
DK8H

I have these parts on a daughter card so I'm driving both the working and non-working from the same FPGA and I

seem to be meeting all the timing specs. Yet every one of boards with the non-A markings is failing the same way.

I've had a scope on all the serial signals and they all look clean with both the non-A and the A.

If I change to auto channel change mode there are no problems, if I manually select ONLY ch0 or ONLY ch1 then there

are no problems.

I've tried doing a 4 clock channel select write before the 16 clock sample read and I've tried doing it after

the 16 clock sample read, I've also tried reading out the data while I do the channel select. All these modes worked fine with

the A version and they all fail the same way with the non-A.

I'd switch one of the ADS8330s from the good boards with the bad boards but we're short of boards right now.

Any thoughts?

Hi Dennis,

The ADS8330's with the '6AJ' markings are from October 2006 (6 is the year, A is the month in HEX).  Would you mind telling me where these parts came from?  Are you by chance running with a continuous SCLK or is the communications setup an actual SPI type burst clock mode with your FPGA? 

Hey Tom,

Nope not a continuous clock, I only drive it high when I'm doing a serial transaction and the CSN is already low, the

clock returns low before the CSN goes back high.

As to the source of the parts, I'd have to ask the manufacturing guys as I wasn't involved in the procurement.

Is there a particular question you'd like me to ask them?

Does the fact that they're from October 2006 shed any light on the issue I'm seeing?

If we have to replace all these parts it's probably not the end of the world but I would like some assurance that whatever the

issue is it was fixed and as of which date code (so we can ensure we don't buy any more with the same problem).

Thanks,

Dennis

Hi Dennis,

Can you send me a scope shot of the timing you are using?  The early silicon (pre 2007) had a few issues with the timing.  This detail is noted on page 38 of the data sheet under the Part Change Notification #20071101001.  If you are randomly jumping between channels, this might be your problem.  There was a minimum timing of the falling edge of FS/CS to the first rising SCLK which was 5ns minimum which was removed.

The 'A' silicon is going to carry a date code starting with 9xxx. 

Hey Tom,

I believe I know the timing you're talking about and I think it was actually the max value that was removed, the min value was changed though.

CSF to SCLK1R had a max on the original datasheet which was removed in the revision.

That max only made sense though if you had a constant clock.

Anyway, I originally had 60ns from CS falling -> first rising SCLK then just in case that timing was somehow

violating the max restriction I tightened it up to 15ns (these were both confirmed with a scope) and it had no effect.

FYI: I'm not randomly jumping between channels I'm alternating but I need to be in control because I have multiple 8330s

that need to be sampling the same channel at the same time.

By the way, apparently these parts were samples that came right from TI (but someone is looking into it).

So what date code did the early silicon stop being packaged 7XXX, 8XXX assuming this is related to the early silicon.

Dennis

Hi Dennis,

Found the notes I was looking for.  Part of the PCN from 2007 was in fact related to the MUX change in auto channel mode.  With SCLKs below 20MHz, the mux would not switch reliably.  With SCLKs below 10MHz, the MUX would not switch at all.  The last date code from that 'early' silicon should be prior to February 2008 (82xx).

Hmm,

That doesn't seem to match my conditions.  I'm running at 33.33MHz and I'm running in manual mode, in fact the only time it seems to work correctly is when I switch it to automatic channel mode.  The fact that there was an issue with reliable channel switching though makes me more inclined to believe this is a previously undocumented but related issue with the pre 2008 silicon.

Tom, do you recall if the bulk of users were using manual or auto channel mode at that time? Just curious if maybe manual mode hadn't quite been through the ringer yet at that time.  Do you think it's fair to write this off as a pre 2008 issue even though we haven't found any mention of it specifically, or am I indulging in wishful thinking?

Dennis

Hi Dennis -

I believe you have the latest silicon at this point.  I don't really have details on which mode of operation was/is used most often, but writing this experience off as pre 2008 material is the best way to address the problems you've had.