DAC3174: DAC3174 Serial Interface Issue

Chris Burton24

Part Number: DAC3174
Other Parts Discussed in Thread: LMK03328, , DAC3171, SN74LVC1G32, SN74ALVTH16374

Hi,

I have an issue where I write to config0 to switch to a 4-wire (SDO becomes an output). I find that I have to (conditionally see below) have to write repeatedly to the CONFIG0 register (73 or more times) before it changes over to SDO, outputting all '1's until then. This is faithfully repeatable for two devices.

My signals for SDIO, SDENB, SCLK all appear within the electrical specifications, and I have ensured that there is at least 1uS margin between any signal transition and another, using the following signal pattern:

1.SCLK = LOW, SDENB GOES LOW.

2. 10uS delay

3. SDIO set to bit value

4. 1uS delay

5. SCLK set high

6. 1uS delay

7. SCLK set low

8. 1uS delay

9. loop to (3) to complete the 24 bits

10. 10uS delay with SCLK low

11. SDENB goes high

There is excellent grounding and decoupling. TX_ENABLE is high, RESETB HAS been cleanly cycled 100mS after power up and is high during the process above AFTER the DATA_CLK and DAC_CLK are both the same frequency (driven by an LMK03328 - with the DAC_CLK PECL derived from an SI53322B Universal PECL Buffer. The clocks are stable and 62.5MHz. SLEEP is left floating. SYNC is not yet toggled.

After the above write process of 0x0046ED to CONFIG0 - to amongst other things switch over to 4-wire, I do not read the right value for 73 cycles of the above algorithm! I have not timed this, but when I write this just once, breakpoint the code (NIOS2 in Cyclone Vgx) under eclipse (no optimisation, volatile I/O - everything looks in right order etc..) AFTER THE COMPLETE WRITE CYCLE (proven with a scope), and then step over the read - it always reads correctly WITH ONE WRITE.

In both cases (running repeatedly and breakpointing) I capture the write cycles on my storage scope - they are identical.

When just running - after 73 looped attempts (or just one attempt via debugger step) - I finally read the written value coming from SDO. I get the following register dumps from TWO DAC3174s I have in the system. Note- I have never seen it return inconsistently, and CONFIG1 is never returned wrong even though it is only ever written too once.

CONFIG0 : 46ed <<<<<<<< As Programmed
CONFIG1 : 604e <<<<<<<< As Programmed
CONFIG2 : 3fff << DEFAULT
CONFIG3 : 0000 << DEFAULT
CONFIG4 : 28a0 << BITS THAT FAILED DURING IO Test pattern comparison
CONFIG5 : 3f40 << 0011 1111 0100 0000 FIFO A and B pointer collisions, dataclk_gone
CONFIG6 : 3100 << 0011 0001 0000 0000 : 0011 0001 temerature sensor = 49
CONFIG7 : ffff << DEFAULT
CONFIG8 : 6000 << SHOULD DEFAULTS to 4000, - some non-default reading in the reserved bits!!!
CONFIG9 : 8000 << DEFAULT
CONFIG10 : f080 << DEFAULT
CONFIG11 : 1111 << DEFAULT
CONFIG12 : 3a7a << DEFAULT
CONFIG13 : 36b6 << DEFAULT
CONFIG14 : 2aea << DEFAULT
CONFIG15 : 0545 << DEFAULT
CONFIG16 : 0585 << DEFAULT
CONFIG17 : 0949 << DEFAULT
CONFIG18 : 1515 << DEFAULT
CONFIG19 : 3aba << DEFAULT
CONFIG20 : 0000 << DEFAULT
CONFIG21 : ffff << DEFAULT
CONFIG22 : 2d04 << RESET IS NOT APPLICABLE. LOWER 16bits of the DIE ID
CONFIG23 : a3c4 << RESET IS NOT APPLICABLE. LOWER MIDDLE 16bits of the DIE ID
CONFIG24 : c9a8 << RESET IS NOT APPLICABLE. UPPER MIDDLE 16bits of the DIE ID
CONFIG25 : 87ff << RESET IS NOT APPLICABLE. UPPER 6bits of the DIE ID
CONFIG127 : 0049 << 0000 0000 0100 1001 . ANOTHER DATASHEET MISTAKE - LOOK AT DEFAULT verses register bits
DAC3174 B REGISTERS
CONFIG0 : 46ed <<<<<<<< As Programmed
CONFIG1 : 604e <<<<<<<< As Programmed
CONFIG2 : 3fff << DEFAULT
CONFIG3 : 0000 << DEFAULT
CONFIG4 : 2cff << BITS THAT FAILED DURING IO Test pattern comparison
CONFIG5 : 3f00 << 0011 1111 0000 0000 FIFO A and B pointer collisions. All clocks present
CONFIG6 : 3500 << 0011 0101 0000 0000 : 00110101 = Temperature Sensor = 53
CONFIG7 : ffff << DEFAULT
CONFIG8 : 6000 << SHOULD DEFAULTS to 4000, - some non-default reading in the reserved bits!!!
CONFIG9 : 8000 << DEFAULT
CONFIG10 : f080 << DEFAULT
CONFIG11 : 1111 << DEFAULT
CONFIG12 : 3a7a << DEFAULT
CONFIG13 : 36b6 << DEFAULT
CONFIG14 : 2aea << DEFAULT
CONFIG15 : 0545 << DEFAULT
CONFIG16 : 0585 << DEFAULT
CONFIG17 : 0949 << DEFAULT
CONFIG18 : 1515 << DEFAULT
CONFIG19 : 3aba << DEFAULT
CONFIG20 : 0000 << DEFAULT
CONFIG21 : ffff << DEFAULT
CONFIG22 : 320b << RESET IS NOT APPLICABLE. LOWER 16bits of the DIE ID
CONFIG23 : a3c4 << RESET IS NOT APPLICABLE. LOWER MIDDLE 16bits of the DIE ID
CONFIG24 : c9a8 << RESET IS NOT APPLICABLE. UPPER MIDDLE 16bits of the DIE ID
CONFIG25 : 91ff << RESET IS NOT APPLICABLE. UPPER 6bits of the DIE ID
CONFIG127 : 0049 << 0000 0000 0100 1001 . ANOTHER DATASHEET MISTAKE - LOOK AT DEFAULT verses register bits

Both DACs show FIFO sync errors and one shows a clock issue potentially - although I have not yet sent a SYNC pulse at this time to the DACs so I expect a framing issue. Also, the power sequencing chapter indicates that serial configuration is independent of these clocks (can anyone please confirm - there are some serious issues with this datasheet and I don't trust it)

What would be the mechanism for this 'deaf' characteristic - when further writes and reads all seem to work no problems at all.

Any help appreciated.

over 8 years ago

0 Neeraj Gill over 8 years ago

TI__Mastermind 20541 points

Hi Chris,

We are looking into this question. We will reply with an answer as soon as possible.

Regards,
Neeraj

0 Richard Prentice over 8 years ago in reply to Neeraj Gill

TI__Mastermind 29220 points

Hi,

I have not seen such an issue with the SPI on the EVM. The fact that your system would work with the breakpoint inserted and not work without it would suggest a timing issue, although you describe a system that is running slowly enough that I would not expect there to be an issue. occasionally I would see someone have an issue with getting a rising edge or falling edge SPI clock mixed up, but your timeline describes a clock period that is low-high-low with the data bit driven the whole time, which I what I usually recommend to make the risingedge/fallingedge issue foolproof. And with 1us each for the low-high-low then the SPI clock period is only about 333KHz - shouldn't be an issue.

The SPI GUI that is available on the TI web (for the 1 channel version of the EVM anyway) did not originally support the SPI readback function. I have since created my own SPI GUI for the EVM that added the readback function, so I have this function working. The configuration file that came with the original SPI GUI had the 4-wire register bit set to 0 which didn't matter since it didn't do readback, but when I use it with my SPI GUI I have to set that 4-wire bit in Config0. My SPI GUI does an immediate readback of the register after every write, and I always do see the value of that bit read back properly. My SPI GUI is a Labview program on the PC that controls the SPI pins through a USB connection and a USB chip with 8 general purpose IO pins to drive the SPI, so it is not a very fast interface due to it being software controlled. In there might be the difference.

If I understand your description - your breakpoint is inserted after the entire write to Config0 is done, before then reading Config0. That inserts a lot of time after the write, but before the read. That would imply that the write itself works well even on the first time of writing Config0. It would imply that there needs to be some time allowed to the device for the 4-wire mode of interface to take effect, although I have not seen any need for that. (again, possibly because my SPI GUI is relatively slow being software driven.) But you state a 10uS wait time after completing the write cycle, which I would have expected to be enough. I just spoke with the designer, and there is nothing in the design of the DAC that should take a long time to enable the 4-wire mode. There is nothing that takes the setting of that bit and goes off to do anything before the made can be enabled. It should just be normal enable time of an output buffer.

On my EVM I use 1.8V supply for the CMOS IO, which would include the SDO pin. The datasheet allows 1.8V through 3.3V for the IOVDD. what are you using? What is your timing on the readback portion of your SPI access? When do you latch the value of the SDO pin? And probing the SDO signal between the DAC and your FPGA with the scope - you can definitely see that the FPGA buffer nor anything else on the signal is holding the signal?

By the way, I opened up the design document to check what the reserved bits do for Config8 and Config127. The reserved bits in Config8 did change from default 010 to 011 during the chip design pushing the default value for the register from x4000 to x6000. This was updated in the DAC3171 datasheet and is queued up to be changed in the next DAC3174 datasheet as well. I do not see an issue with Config127 - I am not following you on that one.

Regards,

Richard P.

0 Chris Burton24 over 8 years ago in reply to Richard Prentice

Prodigy 70 points

Hi Richard,

Thanks heaps for looking into this!

I rechecked my signals on an oscilloscope and can reconfirm that they follow the sequence I have indicated.

Also note that with the exact same write/read routine, I do write pattern - read pattern loop tests - and can have it running for ages with no issues reported AFTER configuring

to 4-wire mode. I have a 100Ohm Resistor in series with the SDIO driving signal from an SN74LVC1G32 OR gate (all my testing has been on the output of this OR gate, going directly to the SDIO. The purpose of this OR gate is to control the output going to the SDIO using SDENB. When I sense across this resistor and leave the design in 3-wire mode - I can see the SDIO trying to drive the SDIO bus during the CONFIG0 read process - getting runt levels on the DAC3174 side of the resistor as its overloading the SDIO - but the runt bits look like the default register values. Potentially suggests something happening in the write cycle.

During CONFIG0 write cycle - I have sniffed off both sides of the 100 Ohm resistor and there is no perceivable voltage differential, with correct pattern.

My interface IOVDD voltage is 3.35V.

I have checked the supplies of all associated devices on the pins and none are exhibiting drooping.

The SDENB is being directly driven by an SN74ALVTH16374 with 3.3V Vcc.

Voh(min) = 2V

Vol(max) = 0.2V (100uA)

The SCLK and SDIO are being driven (except SDIO goes through the afore mentioned resistor) by SN74LVC1G32 OR gates. Vcc = 3.3V

Voh(min) = 3.2V

Vol(max) = 0.1V. Note I do see slightly higher than this - but not much. Note sure why.

The DAC3174 spec in my understanding is

Vih(min) = 2.01V

Vil(max) = 0.8375V

The levels shown by the oscilloscope are well over/under the DAC3174 levels.

Scratching head about this one!

Regarding CONFIG127 comment - page 41, 7.6.26 the reset value is given as follows:

7.6.27 config127 Register (address = 0x7F) [reset = 0x0045]

I am returning 0x0049

I would imagine that as this is the versioned, and versioned probably spins out of sync with datasheet revision, that its a simple mistake in the datasheet to claim the bottom three bits are a fixed reset value.

Also note as a datasheet error:

Page 25 under 7.5.2 Serial Interface Description ...

"In 4-pin configuration, both SDIO and SDO are data out from the DAC3174 during the data transfer cycle "

However under Pin Functions: Single Bus Mode (Page 3) and Dual Bus Mode (Page 5) the SDIO description states:

" Bidirectional serial data in 3-pin mode (default). In 4-pin interface mode (sif4_ena [config0, bit 9]), the SDIO pin in an input only. Internal pulldown"

Can you confirm what the internal pull down resistors are typically on the device - and are they in fact pull downs?

Thanks for your help once again!

Regards,
Chris Burton

Data converters

Data converters forum

DAC3174: DAC3174 Serial Interface Issue