ADS114S06: startup timing missing from datasheet

Oh and an additional question:

Figure 83 also mentions that SPI CLK has to be less than half the max (so <5MHz) when polling for RDY during that window.  Why is this?  What would happen if we don't meet this requirement?

-Bill

Hi Bill Argabright

The POR and the RESET are two different things, so comparing one to the other doesn't provide a lot of value. For example, the internal oscillator does not turn off during a RESET, and therefore there is no oscillator startup time after a RESET

I think you alluded to this, but note that td(RSSC) is a minimum time, not a maximum. That means it will take at least 4096 tCLKs before you can communicate to the device after a reset, but it could take more (note there is no max). 

Are you seeing behavior where the devices are never ready after a RESET, or it just takes a different amount of time for different devices? How are determining when the device is ready, are you just sending a command and waiting for a response?

Regarding the SCLK question during POR: like many specifications, this is just the way the device is designed. Violating this spec means you might not get the correct response from the ADC during this time. So the device might be ready but you might not be aware, or you might get a false positive.

-Bryan

Hi Bryan!

So 4096 clk cycles is not sufficient, and there is no maximum - I think that is an issue, then.  td(RSSC) is the time it takes to start communicating with the device after a reset.  It is not the time it takes until the device is ready (RDY bit / STATUS register bit 6 goes low).

The issue we're seeing is that (on 2 of 4 boards) even after waiting ~5000 fclk cycles after a reset (25% greater than the 4096 required), the RDY bit (STATUS register bit 6) is still not ready.  And because we are (likely incorrectly) asserting a reset in between retries, we are never seeing the ADC get ready.  We hacked a fix here by simply waiting longer - 3ms works.  But with no maximum time (4096 fclk cycles is not a guarantee).

So, I am trying to understand what the expected timing is between a reset and the ADC being ready (RDY bit / STATUS bit 6 goes low).

Our preferred path to resolution is, after a reset:

• Wait ~5000 fclk cycles
• Begin polling for the RDY bit (STATUS register bit 6) to be set
• Timeout after ____ seconds (or retries) and issue an error.

How long should we wait while polling for RDY before giving up and issuing an error?

I suspect the 4096 fclk cycles is listed as a minimum in the datasheet because it is telling us we have to wait at least that long.  In other words, it is guaranteed to be ready to communicate within 4096 fclk cycles - aka 4096 fclk cycles is actually a maximum and we therefore have to wait at least that long.  Can you please double check if this is accurate?

-Bill

Hi Bill Argabright,

Thanks for clarifying what is going on. I will note that spec provides the minimum amount of time you must wait for after coming out of RESET until the device is ready, but it can be longer. So I am not sure what you meant by "actually a maximum" in your last post. 

I have reached out internally to see if I can get more information to share with you, if possible. But it is possible we didn't characterize the max time, which is why it is not included in the datasheet. Expect this to take a few days

-Bryan

I'm thinking the 4096 minimum is telling the user (me) how long to wait, rather than describing how the device itself works.

Hi Bill Argabright,

Sure, I think that is a fair statement. It is just not telling you that you need to wait exactly that long, instead you need to wait at least that long

I have reached out internally to get more info, still haven't heard anything yet. I'll follow up next week if I find out more 

-Bryan

Great, thanks!

To reiterate the other question(s) which I need an answer to, too - Figure 83 shows 2 parts of a 2.2ms wait time before the ADC is ready (RDY bit / STATUS bit 6 goes low):

1. How much of the 2.2ms is used by the "Internal Oscillator Startup"?
2. How much of the 2.2ms is used by the "Internal Configuration"?
3. Does the "Internal Configuration" happen after a reset via the reset pin?

As for #3, we believe this is true because waiting for 1.25ms after a reset (~25% longer than the required td(RSSC) delay) is insufficient for 2 of 4 devices we've checked - the RDY bit is still high after this time.

-Bill

Hi Bill Argabright,

Understood, I am working on it. I haven't heard anything as of right now so I will ping them again Monday morning

-Bryan

Hi Bill Argabright,

Two additional questions for you:

1. Can I assume you are using the internal oscillator at all times i.e. you are not providing an external clock to the ADC? This seems reasonable given the questions you are asking, but I want to be sure since I know you cannot share your schematic
2. To clarify, you are only talking about resetting the device using a RESET command or the RESET pin i.e. we are not talking about a power-on reset (POR)? So, when the system first powers up, you wait the 2.2ms before you start communicating to the device and everything is fine. Then, at some later point you send the RESET command or toggle the RESET pin, then after 4096 clocks the RDY bit is still high? And only after waiting maybe 1.5ms to 3ms do you consistently see the RDY transition low? Again, just trying to confirm because at least the original post says 

   Bill Argabright said:

   Simplifying the issue a lot - on 2 boards, the ADC starts up correctly and we're able to talk to it, and on the other 2, it does not.

   Which to me implies a startup (POR) issue, not a RESET by command or pin issue (and the timing is different between the two)

-Bryan

1. Yes I am using the internal oscillator at all times
2. The full power on sequence is something like this:
   • Power is applied
   • The ADC in held in reset while the FPGA gets configured (FPGA outputs are high impedance, and there is a pull-down on the ADC reset pin)
   • ~1.5s after power is applied, the FPGA is configured and tries talking to the ADC (this is FAR longer than the 2.2ms that it says is required)
   • The FPGA releases reset, waits for ~1.25ms, reads the status register for the RDY bit
   • If ADC is not ready (RDY bit is still high), it resets the ADC again and the the above step is attempted again.
   • Try the above 2 steps 3 times, and fail if ADC is still not RDY.

This is most definitely NOT a POR reset issue because we are waiting an effective eternity (1.5s).  So, there MUST be some part of the POR steps from Figure 83 that happens after a "regular" reset (i.e. from the reset pin or reset command) - likely just the registers getting set back to their defaults during 'Internal Configuration".

Otherwise, I don't know how to explain the fact that (on 2 of the 4 boards) the ADC is not ready (i.e. RDY bit still high) even after waiting 1.5s for the POR, and then ~5000 fclk cycles after a reset (25% more than required).

-Bill

Hi Bill Argabright,

Thanks for providing this info

Can you try holding the RESET pin high during power up instead of low and see if this changes the behavior?

Also, once you are able to read from the device i.e. it is ready, you can try toggling the RESET pin to see if the RDY pin drops low after 4096 tCLKs. In other words, try decoupling the RESET pin from the POR and see if all devices respond with approximately 4096tCLKs when you are just toggling RESET

-Bryan

Currently, the direction is to hold the ADC in reset by default until the FPGA is ready.  This way, the FPGA controls everything.

Bryan Lizon86 said:

Also, once you are able to read from the device i.e. it is ready, you can try toggling the RESET pin to see if the RDY pin drops low after 4096 tCLKs. In other words, try decoupling the RESET pin from the POR and see if all devices respond with approximately 4096tCLKs when you are just toggling RESET

I am going to be unable to test this for a while as the boards have been shipped.  If this does work, though, it implies a connection between reset and POR.  Like perhaps the POR functionality is held off until the reset pin goes high the first time after a power-on.

Is there a way for you to confirm this is actually in the design of the chip (and a note should be added to the datasheet)?

This would answer the question for us, and we would simply wait the 2.2ms mentioned in Figure 83 with confidence that this is enough.

-Bill

Hi Bill Argabright,

I'll check with our team to get their feedback since you are unable to try this at the moment

-Bryan

Hi Bill Argabright,

Yes, the person that writes the datasheet has been made aware, and during the next revision this will get updated

I don't know however when that will be

-Bryan