DAC8775EVM: IEC61000-4 testing

Henrick,

I'm not sure the IEC61000-4-5 tests were run. I wasn't able to find any discussion with it in our internal directories.

This is the design writeup for TIDU216:

http://proddmsvm.itg.ti.com/viewdoc/tiducv6.pdf

In the guide, the writeup talks about IEC61000-4-2, IEC61000-4-3, IEC61000-4-4, and IEC61000-4-6 specifically, but doesn't address IEC61000-4-5. It also mentions at the beginning that the IEC61000-4 tests got Class A results for ESD, EFT, and Radiated emissions, and Class B results for radiated and conducted immunity. There's no mention of surge immunity.

Because of this, I'm not sure if we ran these tests, and really couldn't comment on the surge level expected to pass for that test.

Joseph Wu

Thanks for your reply, Joseph.

We are trying to meet 2.4kV surge between chassis and output. Yes, we are overtesting as part of internal quality requirements. At first design iteration DAC8775 burned at quite lower voltages. Adding unitiy opamps with input resistors at the sense inputs did help. At least in the mock-up we did. Now it appears the output gets fried on the tested channel. Adjacent channels appear to be working. Protection with clamp diodes and TVS are as suggested in the datasheet and ref. design. Plus additional TVS and a GDT between GND and chassis.

The link you posted doesn't work - can you update?

BR Henrik

Henrik,

Sorry, here's a different link to the same document:

https://www.ti.com/lit/pdf/tiducv6

I think you may have already seen this in the TI Design, from this folder:

https://www.ti.com/tool/TIPD216

Joseph Wu

Hi Joseph.

Sorry to open this again, but I need to ask this in relation to the above. During our testing we found in a very few cases, the DAC8775 to survive the surge pulse, but it appears to end up in a reset state and outputs go to 0 V/mA. We came to this conclusion while a re-init restored the outputs, also a power cycle could restore the outputs. Manually resetting DAC8775 leads to the same state. 

Now is there a way to have DAC8775 pull the alarm pin, if it ends up in a reset state or undefined state? Should we use a special register configuration for this - or maybe even an undocumented register?

We know we can use the UBT / UTGL bits to detect this, but as the SPI master system is quite busy, we would rather not have to poll the DAC for reset state or undefined state information.

Please advice - thanks in advance

BR Henrik

Henrik,

I don't think I've heard of this behavior in this device. However, as you've described it, I think it's likely that the device has gone through some sort of reset. With a surge (or negative surge) of the supplies, it's possible that there's been some problem in the power-on-reset and the device has triggered the reset. To be sure, I would just trigger the event and then read back the registers to see that they have been reset back to the default values.

My first suggestion would have been to see if we could protect the device a little bit better to prevent this type of reset from happening. Maybe, increasing the supply capacitance to prevent any dips in supply, or using lower voltage rated TVS, or lower forward voltage Schottky diodes might help. However, I'm just guessing without having seen your schematic.

In some devices a reset is tracked in the register to indicate when the device may have loaded internal registers at the startup. However, that's not the case in the DAC8775. In general, the reset is how you would clear an alarm. As for the read of the UBT/UTGL, writing a non-default value into the user register would probably work fine. I had been thinking about other monitoring flags that might help. If the CRC or WDT were enabled by default, then you'd get the error the first time either of these failed during a reset. However, with neither enabled by default, you wouldn't get the error for either case. Enabling either and then going through a reset would just cause a write error, but I don't think it would get flagged.

Joseph Wu