ADS5400-SP: Sleep Issue

Connor,

This is not a know issue. When you are taking this device out of sleep mode, are you also setting bit 0 = 0 and bit 5 = 1 when writing to this register per the comments in the data sheet ? Does a read of address 0x05 after writing to it to take it out of sleep mode verify the correct register setting was sent? 

After setting bit 6 = 1, is there any toggling on the data output bits?

Is only one part out of at least 15 showing this issue? If so, you may need to request a failure analysis report be done on this part.

Regards,

Jim 

Register 0x05 is set as per the datasheet: 0xE8 in sleep, 0xA8 in wakeup.

I am working to get direct ADC output access.

When in sleep, I do not see continual bit toggling. 

I have a VHDL bit change detector on the clock and data lines with a 1.5ms detection window that is checked at a couple of key points.

I do however have data appear in one of the two FIFOs, which is tightly coupled to the ADC inputs. I believe the clock associated with the A bus for that specific ADC may be producing a spurious pulse. It could also be EMI related, but the traces are short. Are the clock lines asserted low while in sleep, or tristate?

I have found a very strange mitigation. If I write register 0x05 with 0xE8 (what it is already set to) and then with 0xA8, everything seems to work. If I write 0xA8 alone, it does not.

Hi Connor,

Jim Seton retired this week. Sorry for the delay.

Can you please let me know how you have the ADC setup?

What is the sampling rate frequency you are using?

Thanks,

Rob

Here's the complete register configuration:

REG 00: FF

REG 01: F8

REG 02: 00

REG 03: 01

REG 04: 0D

REG 05: A8

REG 06: 04

External reference is used and set via pin.

It is paired with Xilinx Virtex 5QR.

Sample rate is 560.4MHz.

The SPI bus is running at at 2.34MHz clock.

Hi Connor,

Thank you for the information, one last question, are you using the TI EVM setup or your own board design?

Thanks,

Rob

This is our own board design with three identical ADC layouts per board, only one ADC of which behaves differently on one of five boards.

Hi Connor, 

I'm setting this up in the lab same way you did. I'll run it and see if we find the same issue. I will get back to you by tomorrow.

Best regards,
Ikram

In testing I have seen my flag pop up to indicate that the clocks ADC 3 have toggled in sleep mode.

One second after putting the ADCs to sleep:

ADC0_A Clock Frequency : 39935 KHz
ADC0_B Clock Frequency : 39935 KHz
ADC1_A Clock Frequency : 39935 KHz
ADC1_B Clock Frequency : 39935 KHz
ADC2_A Clock Frequency : 40083 KHz
ADC2_B Clock Frequency : 39935 KHz

30s after ADCs sleep:

ADC0_A Clock Frequency : 39935 KHz
ADC0_B Clock Frequency : 39935 KHz
ADC1_A Clock Frequency : 39935 KHz
ADC1_B Clock Frequency : 39935 KHz
ADC2_A Clock Frequency : 40170 KHz
ADC2_B Clock Frequency : 39936 KHz

These numbers come from a clock counter process, i.e. triggering a count from my main clock domain, counting in the target domain and transferring the count over to the main domain. Expected behavior with no active target clock is a frozen counter (as observed for ADC0 and ADC1), however ADC2 has counts appearing on both clocks. 
Also of note, these counts are kHz, or 1000 ticks of the target clock. 
From these data I can infer that ADC2_A ticked ~87000 times and ADC2_B ticked ~1000 times. 
I have a lot more data showing A ticking a lot and B ticking a little. The other ADCs don't budge.
The ticking is not at a consistent frequency as far as I can see, but I only have 1 second resolution.

Hi Connor, 

I ran the same setup as you and I saw that low power mode and waking up requires only setting the 0x05[6] as seen in the datasheet, which is same as what you did. None of the mitigation steps that you mentioned (toggling, and full reset using 0x01[2])  were required.

Since your last reply, I also checked the clock output CLKOUTBP/N (pins 26/27), and they stop outputting when set to low-power/sleep mode. This is the same pin you tested for ADC2_A Clock Frequency right? It seems that pin should stop outputting when in low-power mode.

When you tested the other boards (presumably with the same design), does this occur for the same ADC in the design? Is there anything different for how each of the ADCs are designed or SPI writes?

There are three identical ADCs on this board with identical schematics and VHDL interfaces, as well as several other boards with 3 ADCs on each. The only difference with this board is the part grade - all other boards use EM parts while these are flight grade.

The ADCs are written identically with replicated SPI interfaces.

Only one of the three ADCs on this board shows clocks that don't appear to be fully shut down when in sleep mode. We have not seen this issue on other boards even with the same bitstream. 

After further testing I believe the multiple writes solving the issue may have been a red herring that just lined up with lucky interactions.

The fault I'm seeing with this part is exacerbated by my VHDL which assumes data will not be present when the parts are in sleep mode. As one of the ADCs has a clock that slowly fills up an internal FIFO, my design will fail to come out of sleep as the three ADC state machines are no longer in lockstep and the system faults. This is partially conjecture, I am still pinning down exactly how the state machine is locking up from this issue.

When in sleep mode, are the ADC clock lanes driven to a defined level, or tristated? 

Connor, could you please verify the SPI writes when setting to powerdown and waking up.

After you set it to power down, could you
- measure the current drawn ( it should be much lower than normal operation)
- read the register map and make sure that 0x05 is in correct state
- probe the 3 SPI lines into the ADC with an oscilloscope
- check the data clock output with an oscilloscope or with your counter setup as you already have

We suspect that this could be an issue with SPI writes and timing could be off. Let us know what you find

Power draw drops by the same amount as each ADC is powered down independently. Typically they are powered down simultaneously, but I ran that test pretty early on under the suspicion that the ADC was not powering down at all. Power is indeed significantly lower.

I write 0xE8 to sleep and 0xA8 to power up. 

I have read back the registers and I can confirm that they are correct. 

Here are the ADC registers while in sleep (multiple ADCs 31:24 0x00, 23:16 ADC 0 15:8 ADC 1 7:0 ADC 2)

ADC REG 00: 00FFFFFF
ADC REG 01: 00F8F8F8
ADC REG 02: 00000000
ADC REG 03: 00000001
ADC REG 04: 00CCC60D
ADC REG 05: 00E8E8E8
ADC REG 06: 00040404
ADC REG 07: 00000000
ADC REG 08: 00646564
ADC REG 09: 00000000
ADC REG 17: 00000000
ADC REG 18: 00000000
ADC REG 19: 00000000
ADC REG 1A: 00000000
ADC REG 1B: 00000000
ADC REG 1C: 00000000
ADC REG 1D: 00000000
ADC REG 1E: 00000000
ADC REG 1F: 00616161

And when it is operational:

ADC REG 00: 00FFFFFF
ADC REG 01: 00F8F8F8
ADC REG 02: 00000000
ADC REG 03: 00000001
ADC REG 04: 00CCC60D
ADC REG 05: 00A8A8A8
ADC REG 06: 00040404
ADC REG 07: 00000000
ADC REG 08: 00686A69
ADC REG 09: 00000000
ADC REG 17: 00000000
ADC REG 18: 00000000
ADC REG 19: 00000000
ADC REG 1A: 00000000
ADC REG 1B: 00000000
ADC REG 1C: 00000000
ADC REG 1D: 00000000
ADC REG 1E: 00000000
ADC REG 1F: 00616161

I cannot probe the board as it is conformal coated, staked, torqued and sealed in a box. If I had access I would be investigating the clock lines directly to see what is happening on those lanes.

I can confirm that the ADC functions entirely correctly while in the powered up mode, and incorrectly while in sleep mode. If it were simply not powering down, I expect I would see data coming in as if it were still running. I would also see the expected clock reading of 140103kHz instead of a slowly incrementing pseudo cycle-counter.