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 6280 points
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.

  • Hi Bart,

    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.

    Thanks,

    Paul

  • Hi Paul,

    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.

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

    Thanks,

    Paul

  • Hi Paul,

    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?

    Thanks,

    Paul

  • Hi Paul,

    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?

    Thanks.

  • Hello Bart,

    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.

    Regards,

    Reza

  • Hi Reza,

    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? 

    Thank you.

  • Hello Bart,

    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.

    Regards

    Reza

  • Hello Bart,

    Any update on this issue? Are you now able to readback data on SDO correctly?

    Regards

    Reza

  • Hi Reza,

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

    KR

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

    Regards

    Reza

  • 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

  • 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