Tool/software:
We have a new product in development, and we are having some trouble getting the DAC8562 to work. Here's the datasheet: https://www.ti.com/lit/ds/symlink/dac8562.pdf?HQS=dis-dk-null-digikeymode-dsf-pf-null-wwe&ts=1740129067155&ref_url=https%253A%252F%252Fwww.ti.com%252Fgeneral%252Fdocs%252Fsuppproductinfo.tsp%253FdistId%253D10%2526gotoUrl%253Dhttps%253A%252F%252Fwww.ti.com%252Flit%252Fgpn%252Fdac8562
From the datasheet we gathered that we could:
- Use a non inverted clock polarity - page 9.
- Expect sampling to occur on the falling trailing edge of the clock cycle. - page 9.
- That 200khz SPI clock would be fine - page 9.
- That grounding the CLR pin permanently is fine - page 9.
- since vout only seems to go low when the CLR goes low, its ok to leave it grounded permanently because it will only go low once. After 24 clock cycles it should not matter. - page 34 paragraph 8.4.5
- That grounding LDAC permanently is fine - page 35
- "In synchronous mode, data are updated with the falling edge of the 24th SCLK cycle, which follows a falling edge of SYNC. For such synchronous updates, the LDAC pin is not required, and it must be connected to GND permanently or asserted and held low before sending commands to the device."
- That simply putting a capacitor on the VREF pin because we will be using the internal reference. - page 34
- And that the first thing we should write to it is the command to use the internal reference and set the gain to 2.
- [0x38, 0x00, 0x01] or 0b00111000 00000000 00000001 - page 38 near the bottom. its the last command.
- That should immediately turn on our VREF. (handful of micro seconds)
We are using the voltage on VREF as our metric of "working". So if VREF goes to 2.5v, then it works, if it stays at 0v, then it does not work.
Here's the schematic that we are using:
I understand that the SYNC pin is not the same as "chip select", but for our intent that going low means that we are talking to it, and going high means that we are not talking to it, it's close enough.
Here's a picture of what we are sending to the chip:
Top yellow: chip select/sync
Green: Clock
Blue: MOSI
Bottom pink: VREF (but scaled up a bit so its easier to see even though its always 0 in this image).
This is the first time after power up that chip select goes low, so nothing else has been talking to it and it should be in a known state.
I would expect that the signals in the picture that were given to that DAC chip would have turned on the VREF. But VREF stays low (even after things have gone to steady state, like multiple seconds after).
Is there something that we are missing? I would love feedback.
---------------------------------------------------------------------------------------------------
Additional info:
- Software SPI (bit-banging) works. I am able to control the DAC by commanding the pins on and off with the main CPU and not the hardware peripheral built into our microcontroller.
- We are using the ATSAME54P20A microcontroller. Heres the datasheet
- We have actually used the DAC8652 before on a older project. Lets call that board "A" and call the new troublesome board that we are working on "B"
- We have hopefully ruled out PCB layout mistakes
- most importantly by using a known good "A" board and joining the SPI lines from the "A" board to the "B" board and the "A" board can correctly control the DAC on the "B" board.
- Let me know if that test makes sense to you or if you want to know more. I have a lot on info on that but dont want to clutter up this post
- The Oscilloscope watched what was being transmitted over these SPI lines without having to disconnect anything (to rule out human error of misplacing things)
- The traces were "Very Very Very" close, meaning that as far as SPI protocol is concerned, they are identical. I have overlaid them on top of each other, so let me know if you want to see them.
- they are so close that they are indistinguishable for 90% of it near the ends.
- I also have csv and excel files of the data from the scope if you are curious and want to analyze it, just ask.
- by checking and double checking continuity for shorts and breaks
- most importantly by using a known good "A" board and joining the SPI lines from the "A" board to the "B" board and the "A" board can correctly control the DAC on the "B" board.
- We have hopefully ruled out incorrect SPI configuration by using all 4 combinations of CPOL and CPHA
- We have hopefully ruled out issues with microcontroller configurations by using the same microcontroller as the known good "A" board
- It "shouldn't" matter but just in case, we also transmitted a "reset" command first to see if that would help. It did not. The command is [0x28 0x00 0x01] on page 38 near the bottom (it is the 7th command from the bottom)
- Putting the DAC onto a breakout board and connecting to it to the board in development via soldering wires. The "A" board was able to control it, but the "B" board still is unable to vie HW SPI
- We've tried lightly pulling the LDAC high instead of grounding it. didnt work. But the "A" board is still able to
- We've tried different SPI speeds. No luck.
- We've scoped all 10 pins to look for anomalies or differences between the "A" board and the "B" board when communicating to the exact same chip (not the same model, but the exact same piece of silicon and plastic without desoldering it) and they were still identical. We had the scope leads as close as we could get them to the DAC.
