TLV2556: Corrupted conversion readings from TLV2556 after short power down

Hi Dallas,

Most often, the issues with the TLV2556 are attributed to the power on/start up conditions of the device.  The TLV2556 expects to see an 0xFx command followed by the desired operating mode of the device (see the text below Figure 1 on page 10 of the datasheet).  How is your application code addressing the TLV2556 at power up?

Hi Tom,

Our intent was to write a 0xFD00 (16-bit conversion, MSB first, unipolar) as the first word after a power-up but it looks like there was a bug that resulted in this first transaction never occurring.  We've updated our design and will re-test on Monday.

Thanks,

Dallas

Hi Dallas,

If your initialization went 0xF000 followed by 0xFD00, that would be ideal.  Do let us know how you make out.

Tom,

We're currently just setup for one initialization word (12-bit instead of 16-bit, my message above was incorrect).  With one initialization word of 0xFD0, there is no change.  We're still seeing the same problem.  SPI scope capture is attached.  We'll try the 0xF00 followed by 0xFD0 and let you know if there's any change.

Initializing with 0xF00 followed by 0xFD0 did not resolve the issue.  The failure characteristics are still the same.  SPI capture is below.  Is there any chance the TLV2553 would behave differently with respect to this power up issue?

Hi Dallas,

Can you add EOC/INT to your Saleae plot?  I'm curious to try and understand what is causing DOUT to hold up so long when the /CS line goes high - that should go tri-state when /CS is inactive.

We can work on that.  EOC/INT is not currently connected in our design, but we should be able to wire it in.  We don't have pull-up/down resistors on the MISO line, so could just be the trace/buffer discharge time.   We can add an pull-up/down in the FPGA for the MISO line if needed.  Is that necessary?

After some additional testing it also appears that preceding the 0xFD0 with the 0xF00 makes the issue worse instead of resolving it.  Incorrect readings are now much more common and don't resolve with longer power off cycles.

Here's a capture that includes the EOC/INT line.

Hi Dallas,

You can send me your Saleae capture file if you like, we use them here too.  Can you tell me more about your corrupted data - what exactly is wrong with it?  Can you give me the actual input voltage versus the expected/actual output code?  Also, are the internal test conversion working properly?

Tom,

In the failed state all channels always return 0x7FF (mid-scale) for the conversion result.

It appears that adding the initialization words (0xFD0 or 0xF00,0xFD0) results in the ADC failing always being in the failed state instead of only failing after a short power cycle.

The voltage on the 11 channels is as shown below.  We're not currently reading the internal channels, but can add that if needed.

Hi Dallas,

I suppose the last plot is showing EOC.  It seems like you are sampling at about 1KSPS, what is your I/O clock speed?  Any chance you can send over a schematic and perhaps capture I/OCLK, MISO, MOSI and /CS or EOC with an actual o-scope?

Hi Tom,

Our clock is currently running at 25 kHz to allow more input filter settling time, but we were seeing this issue with a 1 MHz clock as well.  We tried a TLV2553 today and it seems to be working without these issues.  We're going to do more testing with it tomorrow on additional boards and over temperature to see if it resolves the issue.

OK - let us know how you make out.

Hi Dallas,

How are your tests going?

Hi Tom,

We're still doing a little more testing, but changing to the TLV2553 seems to have resolved this issue.