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.

DAC161S997: troubleshooting SPI link with the MCU

Expert 4970 points

Replies: 14

Views: 129

Part Number: DAC161S997

Team,

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). 

Thanks.

14 Replies

  • Expert 4970 points

    In reply to Reza Abdullah:

    Hi Reza,

    we're checking it, let you know once I have some results.

    KR

  • In reply to Bart:

    Thanks. I'll wait for an update from you then.

    Regards

    Reza

  • Expert 4970 points

    In reply to Reza Abdullah:

    Hi Reza,

    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

    scope_shots_24_06_2020.zip

  • In reply to Bart:

    Hello Bart,

    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. 

    Regards

    Reza

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.