Part Number: DAC161S997
a question from our customer regarding DAC161S997 used in conjunction with STM32 MCU (STM32l476RG) on the DAC161S997EVM (with MSP430 unsoldered).
SPI was configured according to documentation, but in no cases they observed a correct SPI communication link between DAC and MCU (also checked what mentioned in Figure 14 in datasheet).
Are there any specific things to look into to troubleshoot this? Eventually they'd like to communicate from STM32 via usart (synchronous uart).
To clarify, they do not see any SPI signals between the MCU and the DAC? Or do they see correct communication and the DAC does not respond?
Ultimately, I think the best place to start is to share the EVM schematic that has been annotated to show their new connections. Generally, issues like this are caused by incorrectly connected the two systems, or one of the systems is not powered correctly. This is hard to debug with an accurate schematic.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Paul_Frost:
thanks for your feedback, I've shared with you the schematic offline.
The DAC is responding on SPI communication, but not according to the protocol described in the datasheet.
In reply to Bart:
I am not sure what you mean when you say " DAC is responding on SPI communication, but not according to the protocol described in the datasheet.". Can you share a scope shot of what you are seeing? Moreover, it is important to remember that the DAC161 is a loop-powered device, so it requires a floating supply loop for L+ and L-.
I mention this because I do not see a ground connected in your schematic from the new MCU and the device. It is important that the MCU's ground is connected to the COM ground of the DAC161, and also that that ground is not connected to the L- node of the loop. The COM ground potential is higher than L- at all times. If the loop supply is not floating, it is possible that the L- is connected to the same ground as the microcontroller (earth-ground, through the MCU's USB power supply, for example).
we don't yet have the scopeshot (might get it), but to explain this first - looking at Fig. 14 in the datasheet, in the second part of the data (7th, 8th and 9th byte) should we receive the same data that we send in 4th, 5th and 6th?
In case when we save data to DACCODE register, reading in the next step the data from that register (respectively increasing and decreasing the written value), we see similar effect in the read: In the second packet of data (when reading data as in fig.14), the first two bits from this packet are completely not correct, whereas the the third one increases or decreases in accordance to the written data in prev. step.
The board and STM32 were connected to ground with COM and not with L- (this is not shown on the schematic). The board is powered with L+ and L- from a 9VDC power supply.
Is it possible that his is just a software issue? Have you configured your SPI master to correctly return all three bytes? If the first two are wrong and the third is correct, then I suspect that you have some array indexing issue. Most SPI modules on MCUs require you to stipulate how many bytes you want to read back.
A quick test for this would be to short the MISO and MOSI lines together. The MISO line should have the exact data that the master is sending out. Using a data analyzer or scope would also verify this quickly.
What is the voltage difference between COM and L-?
What is the ERRB voltage?
we have SPI configured as master and to send 3 bytes and receive 3 bytes.
After shorting the MISO and MOSI, we do receive the same exact data that was sent from master.
The volrage difference between COM and Loop- is 168mV.
The ERRB voltage is 0V.
What do you think?
I want to pick up from where Paul left off. The DAC161S997 always repeats outputs the previously written 24 bits (3 bytes) on SDO, synchronized to CSB. The only exception to this is if the previous SPI command was a read address operation. For your test case, can you detail a sequence of write commands that you're sending to the device? And are you using the protected write mode feature of the device?
The voltage difference between COM and Loop- looks okay to me. ERRB at 0V indicates there is a fault and you have to readback the status register to determine the fault. Note that the DAC161S997 by default requires continuous SPI communication otherwise it'll indicate a fault.
In reply to Reza Abdullah:
what does it exactly mean that it requires continous SPI communication, do you mean using NOP register and sending the information to it in between the sequences? If we send 24 bits and after a while another 24 bits, would the response be correct?
We tried with Protected Write Mode and without, with the same result. Our sequence is - trying to write the data to DAC161_ERR_CONFIG_REG (comenda, msb, lsb, nop_reg, 0x55, 0x55), read of the status (comenda, 0x55, 0x55, nop_reg, 0x55, 0x55), DACCODE (comenda, msb, lsb, nop_reg, 0x55, 0x55), read of DACCODE (comenda, 0x55, 0x55, nop_reg, 0x55, 0x55).
Understood that if we don't read or write any data to the register, DAC needs to receive the data to NOP register that has no practical use?
After power up, the DAC ERR_CONFIG register is configured to report SPI timeout errors and such errors with drive ERRB low. To avoid this, there should always be SPI communication on the bus within a period defined by the SPI_TIMEOUT bits also in the ERR_CONFIG register. This acts as a watchdog timer to trigger an alarm when communication from the host processor is lost. This feature can be disabled in the ERR_CONFIG register by writing '1' to bit 0.
Your general sequence of SPI operations should work. Can you provide details of what 'comenda' represents for the different commands? Also, at this point it would help if you can provide oscilloscope screen captures of your SPI for further inspection. In particular I am looking for how the CSB edges line up with your 24-bit frames.
Any update on this issue? Are you now able to readback data on SDO correctly?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.