• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 46 subscribers
  • Views 554 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DAC60508: Cannot Read Device ID or Any Other Registers; SDO is Seemingly Random

DAC60508: Device ID Can't Always Be Read; Different Behavior Depending on Master uC Despite Correct SPI Mode, Etc.

Drew Bernard
Prodigy 30 points
Part Number: DAC60508

I had an issue reading the device ID a while ago, and was able to fix the issue by simply switching from nRF52840 to an STM32. However, I still want to figure out why SPI communication did not work with the nRF52840, despite sending the exact same command, and AFAIK obeying all of the timing requirements.

This first capture is from the STM32, getting a proper address echo and Device ID read back.

This second capture is from the nRF52840, with the exact same Read request sent. The DAC fails to echo or read back the Device ID in the subsequent access cycle.

In both cases, the chip is soft reset prior to the Device ID read attempt, as follows:

Any assistance would be greatly appreciated, thank you!

  • 0
    TI__Mastermind 42113 points

    Hi Drew, 

    Can you share an oscilloscope shot of both writes. The logic analyzer doesn't capture any edge timings and may miss other spikes that the DAC could be registering as clocks or data bits. 

    Are the logic levels on both controllers the same? Are you able to write to the DAC with the nRF52840? 

    Best,

    Katlynne Jones 

  • 0 in reply to Katlynne Jones
    Prodigy 30 points

    Hi Katlynne,

    Thank you for your quick response. Here are the oscilloscope captures

    STM32 (P-Nucleo WB55):

    nRF52840dk:

    Logic level for both should be 3.3V or close to that. SPI is running at 500kHz in both instances. nRF spec specifies VDD-0.4 to VDD. I have not been successful with writing to the DAC using the nRF52840.

  • 0 in reply to Drew Bernard
    TI__Mastermind 42113 points

    Hi Drew, 

    The screenshots of the nRF52840dk

    In the second shot (below), it looks like the MISO line is echoing some data back. Is this the DAC trying to echo the SW reset write command in the previous shot? It looks like this is the same data that you read back on the logic analyzer, so you are getting some consistent (but incorrect) data back. Is there anything else driving the SDO line during this time? Also, why do the SDO and SDI lines slowly ramp down towards the end of the sequence. That does not happen on your STM32 sequence. 

    Best,

    Katlynne Jones  

  • 0 in reply to Katlynne Jones
    Prodigy 30 points

    Hi Katlynne,

    Nothing else is driving the SDO line. I created an isolated testing setup with just the microcontroller, breadboard, and DAC module. While it appears as though the DAC could be trying to echo the SW write command, I think it might be unintended behavior or is erroneous. I reset the microcontroller many times with no deviation from what's seen above in the scope, never seeing anything closer to an echo. The STM32 also lacks a SW reset echo, after which it operates as expected. I'm not sure why the nRF52 SDO and SDI lines ramps down like that. The DAC is wired straight into the nRF52840 dev kit, with a breadboard for breaking out the signals. I also tested with a ublox BMD360 eval kit with the same behavior, albeit only with the SDO line. See below:

    Is there anything else that could be causing this behavior? I could also take this over to nordic forums, but I just want to eliminate the DAC as the potential culprit before I do, especially if there's something notably different between the two uC SPI traces that could be pointed to as causing the DAC SPI communication to breakdown.

  • 0 in reply to Drew Bernard
    TI__Mastermind 42113 points

    Hi Drew, 

    Thanks for testing on an isolated setup, that would have been my next recommendation. I'd like to focus a write command. If you can't write, then you wouldn't be able to read anyway. Can you send a zoomed in screenshot of a write command to power on/off the internal reference? And double check that you see the reference respond to that command. It's hard to see the timings in the zoomed out screenshot. 

    It shouldn't be anything on the DAC end if you are able to write to it with the other controller. But maybe you can send a zoomed in screenshot using the nRF52840 and one with the STM32 so I can compare those with the same command. We should see some difference between the two. 

    Best,

    Katlynne Jones 

  • 0 in reply to Katlynne Jones
    Prodigy 30 points

    Hi Katlynne,

    Thank you for your patience. I've tested writing to the CONFIG register to turn off the internal reference since it is on by default.

    nRF:

    The preceding reset command:

    The nRF produced no change from the default ON state of the internal reference:

    The STM32:

    The preceding reset command:

    The STM32 however did respond as expected, shutting off the internal reference:

    I still am unable to discern what could be causing the differing responses from the DAC.

  • 0 in reply to Drew Bernard
    TI__Mastermind 42113 points

    Hi Drew, 

    It looks like you shared the STM reset command instead of the nRF reference disable command for the first screenshot. 

    I do notice there is a small glitch on SDI in the nRF reset command (pink arrow). Is there any chance there is a similar glitch in the nRF reference disable command? 

    The only other difference I'm seeing is that CS has a longer fall time on the nRF, but it looks like the rise time on the STM is also pretty slow so I'm not sure if that is a deciding factor. Can you share the register disable command for the nRF. I'll ask my colleagues if they have any additional comments. 

    Best,

    Katlynne Jones