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.

  • Resolved

DAC38RF97: SPI Non-Reactive - Not taking writes

Intellectual 460 points

Replies: 15

Views: 321

Part Number: DAC38RF97

We are unable to get the DAC38RF97 to accept writes.  We have a 80MHz signal provided to DACCLK and SYSREF (verified on a scope) and a 100MHz signal provided to DACCLKSE.  We have verified all voltages to be correct.  We have verified that sleep, jtrstb, testmode, dac_gpi0, dac_gpi1 are logic zero (these are driven from an FPGA).     We have also been able to verify that we can manually toggle resetb.  After a resetb, we execute the attached script using a BusPirate SPI master.  The FuseFarm appears to have been loaded, as indicated in read at 0xff = 0x89.  Currently we are looking at ATEST and writing to 0x01 to select and hopefully read voltages as an indication that the SPI is able to write correctly.  We have not been able to write and subsequently read several addresses, including address 0x09.  What may be preventing us from writing?  Help is appreciated...200224_192106 BusPirate capture.txt

  • Hi,

    Could you please check your DVDD power supplies are stable? Once confirmed, we can look into this further for you.

    -Kang

  • In reply to Kang Hsia:

    All supplies are perfectly clean.  Is there a power supply sequencing issue that I should look into?

  • In reply to Rolf Wendt:

    I have also verified that the supplies are stable/glitchless through RESETB. 

    We did observe that The FuseFarm complete bit did not reset until we had implemented SYSREF and DACCLK+/-, although we are running these at 80MHz which might be below specification.  Initially we only had DACCLKSE implemented.

  • In reply to Rolf Wendt:

    Hi,

    Fusefarm loading requires clocks injected to the DAC to allow the fuse loading process to begin. This is expected.

    Please provide scope shot of SCLK/SDENB/SDIO pins of the SPI bus read/wrte.

    It is possible that you are configuring mismatched 3 wire or 4 wire mode. You will need to make sure your SPI bus is matching the 3-wire SPI mode or 4-wire SPI mode, which is being set by register 1, bit 7. With 3 wire mode, the read back is coming from SDIO pin. With 4 wire mode, the readback is coming from dedicated SDO pin. I see you are expecting to use 3 wire mode as you were able to readback upon reset.

    Please also advise how you are handling r/w bit in the SPI instruction. It sounds like you can read correctly but not write. The only difference in command is the r/w bit in the SPI instruction. It is best you probe the exact timing in the scope to find out bit by bit the SPI transactions.

    -Kang

  • In reply to Kang Hsia:

    We are working through an FPGA.  However, right now, we are reading back on SDO all the time and writing to SDIO all the time.  If we are in 4-wire mode, can the SDIO always be driven by the processor, or must it be tristated during a readback.

  • In reply to Rolf Wendt:

    THis shows a sequence of commands.  I added the first to show we are actually in 4 wire mode.

    [0x01 0x18 0x80]
    [0xff r r]
    [0x81 r r]

    The Capture File and scope plots are included.  I zoomed into each plot.  All plots are ordered as follows top to bottom:

    SCLK (black)
    SDEN (blue)
    SDIO (green)
    SDO (red)

    Here is the data:

    [0x01 0x18 0x80][0xff r r][0x81 r r]
    /CS ENABLED
    WRITE: 0x01
    WRITE: 0x18
    WRITE: 0x80
    /CS DISABLED
    /CS ENABLED
    WRITE: 0xFF
    READ: 0x80
    READ: 0x09
    /CS DISABLED
    /CS ENABLED
    WRITE: 0x81
    READ: 0xC0
    READ: 0x04
    /CS DISABLED

  • In reply to Rolf Wendt:

    Hello,

    I see you were not set to 4 wire mode. I see register 1 (from your attached configuration) having bit 7 set to 0. To access 4 wire mode, you need to set this bit to 1.

    In 4 wire mode, you do not have to tristate SDIO. SDO is dedicated readout, and SDIO is dedicated input. 

  • In reply to Kang Hsia:

    I see that I omitted the first command in the scope captures (but I did have it in the command log).  Sorry!  Looks like I am writing it correctly, but when I read it back, it is returned incorrectly.  Quick quiestion on startup... the sequence should be:

    as per Figure 150:

    1. apply clocks, resets
    2. Write 0x01 0x81 0x80 to put it into 4W.
    3. Read 0x7f - check bit 15.  I have observed that the SDO is alway active regardless of (2).
    4. Redo if fail, continue if pass.

    The first command was (note highlight, in first and 3rd command - later in this reply):

    [0x01 0x18 0x80][0xff r r][0x81 r r]
    /CS ENABLED
    WRITE: 0x01
    WRITE: 0x18
    WRITE: 0x80
    /CS DISABLED

       The third command read it back incorrectly:

    /CS ENABLED
    WRITE: 0x81
    READ: 0xC0
    READ: 0x04
    /CS DISABLED


  • In reply to Rolf Wendt:

    Hi Rolf

    Could you confirm you are doing the following?

    1. address= 0x01, register value = 0x1880? 

    Rolf Wendt
    [0x01 0x18 0x80][0xff r r][0x81 r r]
    /CS ENABLED
    WRITE: 0x01
    WRITE: 0x18
    WRITE: 0x80
    /CS DISABLED

    If so, why is the SCLK not continuous? Rather, they are broken up into 3x groups of 8 bits. There should be some FPGA IP that can do predefined SPI bus writes/read without continuous SCLK.

    Also, for the reading back of the 0x01 register, I am not see the read bit being in logic hi. See capture below:

  • In reply to Kang Hsia:

    We are currently not directly managing a state machine through the FPGA, rather we are instead using a PC buffered through an FPGA.  It will operate on a byte by byte basis and cannot be setup to operate with a continuously smooth clock stream, normally acceptable for SPI.  If a continuous clock stream is required, we will implement this, although it may take several days, and does not appear to be a requirement in the datasheet.

    As for the byte sequence, this is the sequence and response:

    Byte 1

    Byte 2 (read):

    Byte 3:

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.