This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DDC264: Pin DAVLID don't act normally like Figure 28 show

Part Number: DDC264

  Good day,TI expert,

  I found the DAVLID goes active high not low and it not goes active after CONV toggled all the time.

  I have connneted the analog input pin in series with 10KΩ resistor and GND,as follow:

but I recevie random data in "test  mode off".

all zero in "test mode on".

  I just act DCLK after DAVLID move when my customer send command to take the data.

  Is it the problem?

  If not,what would make DAVLID output abnormal?

Thanks for your reply.

  •   Good day,TI expert.

      Now,the DVALID act normally,follow the datasheet.

    But I recevie "all 0xFF" in "test  mode off" with connneted the analog input pin in series with 10KΩ resistor and GND.

    Configuration as follow:

    Range = 150pC

  • HI,

    I will get back to you around 6/22

  • Hi,

    I'll let Chien dig on further details but just few things:

    1. It's not completely clear to me what you changed from the first post to the second post, to make DVALID come right. Just in case, in the past, I've seen the DVALID signal looked like it is inverted when the timings are not set properly. Can't recall the exact case but I think it may have been if the data is not read in time before the next CONV edge, for instance. The DVALID goes down but as not read, stays down and briefly goes up right at the end of the next conversion, when the ADC finishes, to go down again. Don't quote me 100% as I don't recall the details but it was something again with wrong timing (not enough time to do the data conversion, not reading it out, etc.). 
    2. In your second post, second picture, you show about 130us reading the data (DCLK length), which would be about right for a 8MHz DCLK. Is that your DCLK?
    3. Somehow on your last picture I can see DVALID go down and up after DOUT has started coming out. That is weird... DOUT should follow the falling edge of DVALID and DVALID go up as you start reading the data. Also there the duration of the DOUT looks longer here, about 140us. Am I missing something?
    4. The 10KOhm to ground at the input is kind of risky. If you want to have no input, the best is to leave it open. If you connect a resistor to it, the input bias voltage of the device (something around 0.1mV) will create a current going out (negative swing) through that resistor. If the resistor is small, that current may saturate the device to all zeros. That doesn't explain why you get all ones, though.
    5. Test mode should be giving you something close to code 4095.

    Hopefully some of this helps you find the issue,

    Edu

  • Good day,TI Expert Eduardo Bartolome.

    Thanks for your suggestions and let me describe my problem more clearly and add some details.

    1.At first I thought DVALID would act normally no matter what state of DCLK so I just moved DCLK when I want to send data to PC software,untill I saw 8.1 Overview.Then I started to move DCLK after DVALID goes low every time.It make DVALID come right.

    2.Yeah,it is DCLK as label shown in the second post,second picture.

    3.Do you meant DVALID should go down and up before DOUT has started coming out? And DOUT action should last 1024*(1/8MHz) = 120us?

    For that,I need to check it out.

    4.My analog input design part as below.The SW1 to SW64 would be closed when the sample comes.I connneted the analog input pin in series with 10KΩ resistor and GND.

    Because 10.1 Power-Up Sequencing says "Before device power-up,all digital and analog inputs must be low".

    According to your suggestion "The 10KOhm to ground at the input is kind of risky",I should just remove it or disconnect it after the power supplies have stabilized?

    5.code 4095?sorry,I don't have information about code 4095.

    Thanks for your reply.

  • Hi,

    We will get back to you around 6/22.

    Thanks

  • Hi Jieyin,

    On #1, that certainly explains it. 

    On #2, just to be sure, my question was if DCLK=8MHz?

    On #3, yes, the usual steps are DVALID goes down, then you send DCLK, then DOUT starts coming up and DVALID goes up. But in the picture, DOUT starts coming out even before DVALID comes down?

    And yes, in the picture the DOUT last longer than in the other picture. If, per #3, your DCLK is 8MHz, then yes, it should be 64x16/8MHz.

    On #4, oh, I'm sorry for the misunderstanding. Yeah, no need to connect the analog inputs to GND with anything ever. You only need to connect your detector. If the analog inputs are not connected, during power up, it is fine. In fact the inputs are always close to gnd as they have the internal diodes already. The meaning should say more like, don't connect them to some voltage... (floating ok)

    On #5, it is not obvious but if you check the DS, in the electrical characteristics table, it says that the "negative full-scale range" is -0.4%. It means that the logical output zero actually is a current input of -0.4% of FSR. In codes, that is about 2^20 x 0.4% = ~4095. I.e., when the output is ~4095 code (+/- offset error), the input is actually zero current.

    Please let me know if this makes sense... Hope it helps!

    Edu

  •   Good day,

    <1>  yes,DCLK = 8MHz.

    <2>  I received zero when analog inputs floating.

    <3>  And I have checked on #3,it is weird.

    DOUT will start coming up before DVALID goes up in some situations,as follow:

    /////////////////////////////////////////////////////////////////////////////////

    //////////////////////////////////////////////////////////////////////////////////

      The first piece DDC264:

    ///////////////////////////////////////////////////////////////////////////////////////////////

      When float analog inputs:

    ///////////////////////////////////////////////////////////////////////////////////////////////////////

      When connnet the analog input pin in series with 10KΩ resistor and GND.Except IN20,21,23,24,25:

    /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

      When connect to sample.1:

    /////////////////////////////////////////////////////////////////////////////////////////////////////////////

      When connect to sample.2:

    ///////////////////////////////////////////////////////////////////////////////////////////////////////////////

    //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

      The second piece DDC264:

    //////////////////////////////////////////////////////////////////////////////////////////////////////////////////

      When floating:

    //////////////////////////////////////////////////////////////////////////////////////////////////////////////////

      When connect to sample.1:

    /////////////////////////////////////////////////////////////////////////////////////////////////////////////////

      When connect to sample.2:

    ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

  • Hi,

    Actually I think everything is fine now. I was confused but my colleague pointed out to me that the DDC264 actually sets the very first DOUT bit to be transmitted ahead of bringing down DVALID (please see figure 23) and stays there till DCLK comes in. So, if the first bit is a zero, you will not see any transition on DOUT till the first DCLK comes in... But if it is a one, it'll switch ahead of DVALID and stay there till DCLK comes in. Hence all the figures you sent seem right.

    The length of the DOUT looks about right too: 16 x 64 / 8MHz = 128us. Last figure shows 138us, so a bit of an error, but maybe your 8MHz is not exactly 8MHz?

    Other than that, I think you are set on the data transmission side of things.

    The "only" thing remaining looks to me that is your output codes:

    1. With no input (#2), it should not be zero but more like 256 (4096 in 20bit --> 256 in 16b mode).
    2. With the resistor, if anything, should be saturating to zero, not to all ones.

    Some questions:

    • Is this your board or our EVM?
    • Do you put it inside a shielded box? The inputs are so sensitive that can detect any noise coupled to them. Still, I don't think that would show up as zero.
    • Can you show an output plot with test mode?
    • Why you attach 4 plots for the 10k case? Are they all the same?
    • What are you changing from sample to sample? I mean, sample zero looks stuck, but sample 1 looks like toggling (with small output codes), and sample 2 looks toggling too (but with very large). How come you are getting such a large changes with nothing connected to the input? And even more weird, behavior looks the same for the 2nd device. How come? Are the two devices independent?

    Regards,
    Eduardo

  •   Good day,Eduardo

    Actually I think everything is fine now. I was confused but my colleague pointed out to me that the DDC264 actually sets the very first DOUT bit to be transmitted ahead of bringing down DVALID (please see figure 23) and stays there till DCLK comes in. So, if the first bit is a zero, you will not see any transition on DOUT till the first DCLK comes in... But if it is a one, it'll switch ahead of DVALID and stay there till DCLK comes in. Hence all the figures you sent seem right.

       Thanks for your reply.I just noticed figure 23.

    The length of the DOUT looks about right too: 16 x 64 / 8MHz = 128us. Last figure shows 138us, so a bit of an error, but maybe your 8MHz is not exactly 8MHz?

      <1>The blue is DCLK,it's frequency data in the lower left corner of the figure.The cursor is about DOUT,and it switch ahead of DVALID and stay there till DCLK comes in,so it shows 138us.

    With no input (#2), it should not be zero but more like 256 (4096 in 20bit --> 256 in 16b mode).

      <2>I don't understand what you meant.But 16bits is 65535 in DEC?

    With the resistor, if anything, should be saturating to zero, not to all ones.

      <3>I didn't see it should be saturating to zero or all ones in datasheet.But I got zero in the test mode.

    Is this your board or our EVM?

      <4>it's not EVM.

    Do you put it inside a shielded box? The inputs are so sensitive that can detect any noise coupled to them. Still, I don't think that would show up as zero.

      <5>I don't put it inside a shielded box.Sometimes I will get data output about hundreds.

    Can you show an output plot with test mode?

      <6>As <3>

    Why you attach 4 plots for the 10k case? Are they all the same?

      <7>It just a display format for looking clear and neat.

    What are you changing from sample to sample? I mean, sample zero looks stuck, but sample 1 looks like toggling (with small output codes), and sample 2 looks toggling too (but with very large). How come you are getting such a large changes with nothing connected to the input? And even more weird, behavior looks the same for the 2nd device. How come? Are the two devices independent?

      <8>My customer want to check the state or quality of the sample which behaves like a capacitor. I call it C. So they will charge C for a while and switch to DDC264 analog input to see how much power can charge to C.The sample 1 may be a bad C or not be charged enough power.

      The two devices is independent.

    Regards,

    jieyin.

  • <1> clear now, duh! Slight smile

    <2> With no input (input disconnected, floating, zero current input), the output code in 20bits would be about 4095 (I explained that in a previous post). But you are using 16b, I believe, so, it would be more like code 256.

    <3> It is not specific to the datasheet. Basically if you place a resistor between the input and ground, as the input will have some residual positive voltage respect to the ground, there will be a flow of current OUT of the pin, which is basically in the negative direction. Hence it'll saturate to all zeros.

    Test mode should not be all zeros. It should be near code 256. We probably owe to focus on this as that isolates a lot of stuff. Can't think what would be that you are doing for this to happen, though. Can you share an schematic? You can do that directly to my email, if you want. Let's PM. Got to go now but will reply to the rest tomorrow. 

    Cheers!
    Edu

  • Hi again,

    Basically, if I was to summarize the situation, based on <8> we don't know if anything is wrong (could be right) during normal operation, but in test mode, something looks wrong. Do you agree? Is that your concern?

    You are getting all zeros instead of something close to 256. Looking at the config read data, it looks like you are reading the configuration right (0x2681), and one can see that you are indeed programming the test mode. Don't know how you can get that effect.

    But let's check if the device is converting properly in normal mode. Can you connect a resistor of say, 1 or 10MOhm, between one input and a DC source, and apply a voltage with the DC source? Then check the output code to see if it matches your expectation? For instance, apply 0.1V with 1MOhm --> input current will be 0.1uA. If you use a CONV of 1ms, input charge will be 100pC, which should produce about 23k output code in 16b mode. Play with DC source voltage to see that the output is what you would expect...

    Just a final thing, can you confirm what frequency is your CLK?

    Thank you,
    Edu

  •   Good day,Edu.

      Sorry for replying so late.

    <1>

    On #5, it is not obvious but if you check the DS, in the electrical characteristics table, it says that the "negative full-scale range" is -0.4%. It means that the logical output zero actually is a current input of -0.4% of FSR. In codes, that is about 2^20 x 0.4% = ~4095. I.e., when the output is ~4095 code (+/- offset error), the input is actually zero current.

      I think I know what you mean.you mean the actual range is -0.4%FSR ~ FSR (when -0.4%FSR,output zero;0%FSR,output 2^16 * 0.4% = 261,100%FSR,output 65535).

    But FSR is full-scale range

     .

    I mean if I choose Range3

     ,

    the FSR is 15pC(157.5-142.5).

    so the actual range is 142.44~157.5pC

    And when not current input,it's 0pC lower than 142.44pC.It make output zero reasonable.Am I right?

    What makes me think that is when test mode

       output zero.

    And even it has noise,the noise looks too stable and deliberate to be noise to keep output zero.

    <2>

    But let's check if the device is converting properly in normal mode. Can you connect a resistor of say, 1 or 10MOhm, between one input and a DC source, and apply a voltage with the DC source? Then check the output code to see if it matches your expectation? For instance, apply 0.1V with 1MOhm --> input current will be 0.1uA. If you use a CONV of 1ms, input charge will be 100pC, which should produce about 23k output code in 16b mode. Play with DC source voltage to see that the output is what you would expect...

      It's good idea,I will try it.

    <3>

    Just a final thing, can you confirm what frequency is your CLK?

      CLK is 4MHz.

    <4>

    Test mode should not be all zeros. It should be near code 256. We probably owe to focus on this as that isolates a lot of stuff. Can't think what would be that you are doing for this to happen, though. Can you share an schematic? You can do that directly to my email, if you want. Let's PM. Got to go now but will reply to the rest tomorrow

      It is beyond my authority to send you the whole schematic.But I could post part of schematic about DDC264 later.

    <5>

      By the way,my customer want redesign DDC264 Board.Could you give some suggestions about layout and other things.

      Thanks for your reply.

      Regards,

      JieYin

  • Hello,

    On <1>, this is basically right: actual range is -0.4%FSR ~ FSR:

    When -0.4%FSR,output zero;

    0%FSR,output 2^16 * 0.4% = 261

    100%FSR,output 65535

    Nevertheless, the second part of <1> is not right. All what that table says is that when you select Range 3, the actually FSR (full-scale range) will be somewhere in 142.44~157.5pC. I.e., the charge that will saturate the converter when setting that range 3 will be in that range.

    On <3>, that looks too low... I believe you select clock divide by 4. So, converter is expecting 20MHz clock input. If you use 4MHz, everything slows down by 5x respect to the normal times listed in the DS. So, conversion of the ADC will take much longer to come up. May be fine if your integration time is long too. Please check.

    <4> No worries. If you get authorization, please send to my email (I believe I sent you a note there)

    <5> DS has some guidance. Another source is to look at the EVM layout. We do not have any other document but we can discuss over the phone if needed.

    Regards,
    Edu

  •   Good day,Edu.

      I have sent you a brief part of schematics about DDC264.

      By the way,I found my customer connnected the DIN pin with SPI_MOSI pin in MCU.I have confirmed SPI_MOSI pin keeps low(0V)  all the time.

    But I do not know will it influence the conversion?

  • Hi Jieyin,

    So, if I get it right, the DDC264 has a zero all the time at DIN. I see no problem with that.

    I'll check the schematic...

    Regards,
    Edu

  •   Good day,Edu.

      Do you have DDC264EVM?If you could try it,it will solve my confusion when I set test mode receive zero.

      Regards,

      jieyin.

  • Sorry, not sure I follow… We do have an EVM but what exactly you want me to test? If we set test mode, we will not receive zero, we will see what I mentioned above (code about 0.4% of FSR). We do not get all zeros.

    Maybe there is some issue with the grammar/English. What do you exactly mean by "when I set test mode receive zero"?

    Regards,
    Edu

  • Good day,Edu.

      <1>I have tried to connect a 1.8KOhm between one input and 0.002V DC source.When CLK = 10Mhz tIN = 40'000us DCLK = 16MHz,test 64 times,got these numbers.

    It seems unstable.

    <2> And about test mode, I have no idea.I think when set test mode,input will be disconnected from DDC264.So no things could effect the DDC264 "real input",right? Is it the power supply influence the "real input"?

  • Hi Jieyin,

    The DC experiment is too tight... I mean, ideally you don't want to play with such a small voltage (2mV) as the source may not be very precise. One other issue is that the other side of the resistor is connected to the input of the DDC which voltage is not exactly zero either. In the DS is called DC bias voltage and typically is 0.1mV for low input currents (worst case 1mV), but can increase with larger currents (as the input impedance of the device is not zero), although I don't see that an issue here. Anyhow, to remove all this uncertainty and avoid having to look at 2nd order effects, try applying at least 10's if not 100's of mV.

    The other issue is using such a small resistor (1.8KOhms). I just saw that you are using 40ms integration time, isn't it? That means that your maximum current can only be 150pC/40ms=3.75nA. Using 1.8KOhms, you would have to use uV sources. I would say to use a 10MOhm. That way, your voltage would be <37.5mV, say 30mV, to avoid saturation. The other approach is to reduce the integration time, but I guess that's your operation point, what you want to check, so, leave it there and just try a larger resistor.

    On #2, you are right. Test mode should completely disconnect the inputs. You may still have some leakage but you should be getting something non-zero. I.e., 0.4% of 150pC / 40ms = 15pA which is bigger than the input leakage current.

    I am going to suggest that if you do <1> and still stuck, we jump into a call. Feel free to email me whenever you feel that would be a good step.

    Regards,
    Edu