TLV2548: TLV2548IDW lock-up problem after power-up

Hi Stephen,

There are no known conditions which can cause the bad state.

1) We can get to the root cause of the issue if you could share the logic state of SCLK, CSTART#, PWDN#, FS, CS# during power-up (i.e. when supply is ramping up)?
2) Are any of these digital input lines toggling in sync with the supply (i.e. changing their logic state when supply is ramping up)?

I've attached 2 scope captures, one showing timing of ADC SPI input signals relative to VDD at power up, and the other showing timing of PWDN and REFP relative to VDD at power up. Note that we are not using PWDN nor FS (both pulled-up to VCC).

Hi Stephen,

Thanks for providing the scope shots.

I do not see any particular discrepancies with the power-up sequence of the ADC. As you mentioned in your query, this is a rare event which can be recovered by resetting the processor. I am thinking if the processor is the one which needed the reset.

1) Is the same processor handling the other functioning ADCs in the system?
2) When you encounter the bad state, could you probe the device CS, SDO and SLCK and capture a scope shot?
3) If the SPI interface of the host is working fine in the bad state, could you write 8000h to the device as mentioned in the "hardware/software power-down mode" section of the device. Does the device-host interface recover after that?
4) In the bad state, could you please try recovering the ADC by using the PWDN pin (without resetting the processor).

If (2), (3) and (4) do not work, does a software reset to the host processor recover the device-host interface?

As this event is rare, I am putting out all the possible angles of looking at it in one go. So that we can use that one occurrence to the fullest extent to understand the root cause.

(1) Yes, the processor is handling the other TLV2548 ADCs in the system just fine, albeit they are on different boards. All are on the same SPI bus, just different chip selects.
(2)(3)(4) - the ADC in question is buried deep in our system and so probing it is not possible. We don't have a way at this time to write 8000h to the ADC for a software power down; we'd need to write special code.

Hi Stephen,

As it is not possible to probe the device when a bad state is encountered, could you try the following -

1) Swap the device from board 1 with another device on board 2. Would the failure still continue to occur on the same board?
I am trying to ascertain here whether the problem is with the device or the board on which the device is populated.
2) When you swap the devices, please connect board 1 and board 2 in their original positions (i.e. same power plug, cabling etc). This will ensure that nothing but device position was changed.

As I mentioned, the ADC is buried deep in our already assembled system and so unfortunately I will not be able to do the device swaps that you are recommending, however, we have replaced the device in the past when this has happened on another unit and the problem went away. The reason we are concerned is that we have seen this with multiple devices on different boards so we want to see if there is anything about the use of the part that is causing a problem. I just want to go back for a moment to the first screenshot from 1/23 that captures the SPI signals relative to VCC during VCC ramp up. As you can see, the SPI signals are coming up before VCC and are greater than the device max. spec of 0.3v above VCC (the scope capture shows 0.8v above VCC) during the ramp-up period. From your 1/23 response you didn't see any particular discrepancies with the power-up sequence but I'm not sure that you noticed this and may want to comment further.

Hi Stephen,

I did notice the diodes on digital pins turning on during supply ramp up. This is not a recommended scenario because current through the diodes can be destructive to the device. However, all other ADCs in the system wake-up this way. Hence I asked for a digital write based recovery which would establish that there was indeed a sensitivity to IO logic during wake-up.

If a piece of debug code can be written on the host -

1) Power up the device the way it is shown in the oscilloscope shot in your previous post.
2) Power up the device with digital IOs held low during power up.

This experiment too requires reproducing the bad-state with some degree of repeatability.

I should mention that not every TLV2548 in our system powers up in the same manner as the one in question due to our power distribution architecture. The scope capture shows the most extreme case, which is for the ADC that is exhibiting the problem. The other ADCs do not have the same voltage violation because they are on different power legs.

Our processor I/O ports are defaulted to have weak pull-ups enabled during power-up and this cannot be programmatically changed. The weak pull-ups ultimately cause SPI signals at the TLV2548 to be high during power ramp-up. Because the processor’s weak pull-ups, writing code to force SPI signals low won’t help. Instead, we can add pull-down resistors to the signals in question on our processor board to prevent the VCC+0.3v signal level violation during power ramp-up. After power-up, the processor will configure its ports for SPI and drive the SPI signals to their proper levels by which time the TLV2548 on the other board will have its VCC already up. We experimentally tried this on a prototype system and it worked without any repercussions. However, we don’t know if this really solves the problem until we do extensive power-cycling, but I think that this is a step in the right direction.