Thank you for your reply. It's at least 100mS after Vcc stabilizes at 3.3V, the host micro starts talking to the DAC. I've experimented with a few different boards, and my issues seemed to be isolated to one or two boards. However, I just experienced a scenario where I was developing code most of the afternoon on the board, and the DAC was responding properly. I then loaded in a new version of FW for an additional test, and I started observing Vout 'stuck' at 2.91V On the surface, it appeared my firmware 'broke the DAC', which seems incredibly unlikely, which is what led to the earlier question regarding improper configurations and potentially damaging the chip. I had a second board which also had similar behavior, except its power on Vout was 3.23V. I can replace the DAC, and the circuit starts behaving again... My first instinct was to stick a scope of the rails and various pins, just to see if I could see any unexpected transients as I power cycle the board. I have not seen any unexpected transients to this point. I guess what I'm asking is a) are there any known issues in the chip or specific pins, that I need to be 'extra' careful in ensuring no transients occur? b) based on the schematic design presented, just from an initial glance, does TI see anything that may be risky with my 3.3V configuration? The reason for that question relates to an observation in the datasheet. Granted, it's regarding the use case where a user would feed the chip a reference input voltage. But I couldn't help but notice a clear distinction of the VREFIO min/max (when I assumed configured as an input), if Vcc is 3.3V. I'm curious if there's some kind of internal threshold where I'm right on the edge 'of something', powering the chip from 3.3V? And if so, would it make more sense to power the chip from 5V, for better reliability? Again, our schematic: Any suggestions would be welcome to help mitigate any damage to the chip that would cause Vout to get 'stuck' at some output voltage.
↧