This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
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).
In reply to Reza Abdullah:
we're checking it, let you know once I have some results.
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 Bart:
Thanks. I'll wait for an update from you then.
thanks for your patience. Below you can find attached the oscilloscope shots showing the writes to daccode register and then reading it.
The communication scheme is: sending 0x04,(2xbyte of data),0x02,0x55,0x55, so it is 6 bytes total. Next, trying to read by sending 0x04,0x55,0x55,0x02,0x55,0x55. As you will see on the scopeshots, there is an effect in 3rd, 4th and 5th byte, depending on what we are trying to write to daccode register.
The configuration is initiated from a reset, then writing a value to err_config register and reading the status. Unfortunately it doesn't change how the device works. If the device is always in a fault state after power supply, it looks more like hardware issue than software.
Looking forward for your feedback.
MOSI - red
MISO - yellow
CS - blue
Thanks for the update. It is very useful to have these oscope screenshots. Can you confirm that the blue trace really is CS? If it is then that may explain the issues you are encountering. CS should be high in between SPI frames and low during the 24-bit SPI frame. Only 24 bits or multiples of that should be sent in a frame other wise a SPI frame error will be reported. The frame length is determined by the number of SCLK cycles happening while CS is low. The CS trace in the scope shots you provided will certainly cause errors.
Can you have CS formatted as shown below and retry? I'd like to see the new oscope screen shots when you do that.
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.