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.

DAC38RF97: SPI Non-Reactive - Not taking writes

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
SPI>
SPI>[0xff r r]
/CS ENABLED
WRITE: 0xFF 
READ: 0x80 
READ: 0x09 
/CS DISABLED
SPI>
SPI>[0x80 r r]
/CS ENABLED
WRITE: 0x80 
READ: 0xC0 
READ: 0x04 
/CS DISABLED
SPI>
SPI>[0x81 r r]
/CS ENABLED
WRITE: 0x81 
READ: 0xC0 
READ: 0x04 
/CS DISABLED
SPI>
SPI>[0x82 r r]
/CS ENABLED
WRITE: 0x82 
READ: 0xFF 
READ: 0x00 
/CS DISABLED
SPI>
SPI>[0x83 r r]
/CS ENABLED
WRITE: 0x83 
READ: 0xC0 
READ: 0x04 
/CS DISABLED
SPI>
SPI>[0x84 r r]
/CS ENABLED
WRITE: 0x84 
READ: 0xFE 
READ: 0x00 
/CS DISABLED
SPI>
SPI>[0x85 r r]
/CS ENABLED
WRITE: 0x85 
READ: 0xFE 
READ: 0x00 
/CS DISABLED
SPI>
SPI>[0x86 r r]
/CS ENABLED
WRITE: 0x86 
READ: 0xFF 
READ: 0x00 
/CS DISABLED
SPI>
SPI>[0x87 r r]
/CS ENABLED
WRITE: 0x87 
READ: 0xC0 
READ: 0x04 
/CS DISABLED
SPI>
SPI>[0x88 r r]
/CS ENABLED
WRITE: 0x88 
READ: 0xFC 
READ: 0x00 
/CS DISABLED
SPI>
SPI>[0x89 r r]
/CS ENABLED
WRITE: 0x89 
READ: 0xFC 
READ: 0x00 
/CS DISABLED
SPI>
SPI>[0xff r r]
/CS ENABLED
WRITE: 0xFF 
READ: 0x80 
READ: 0x09 
/CS DISABLED
SPI>
SPI>[0x01 0x00 0x1f]
/CS ENABLED
WRITE: 0x01 
WRITE: 0x00 
WRITE: 0x1F 
/CS DISABLED
SPI>
SPI>

  • Hi,

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

    -Kang

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

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

  • 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

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

  • 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

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

  • 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


  • Hi Rolf

    Could you confirm you are doing the following?

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

    Rolf Wendt said:
    [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:

  • 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:

  • Kang,

    I have tried this now on multiple boards, so the issue is consistent.  There is something different between reading 0xff and the rest of the address.  It is clear that the flash farm is working fine as indicated by address 0x7f (0xff command).

    What is different from this address and all other addresses?  I try to read a couple of registers.  See the following:

    1) Write Address 0x01:

    WRITE: 0x01
    WRITE: 0x18
    WRITE: 0x80

    2) Read 0x7F:
          
    WRITE: 0xFF
    READ: 0x80
    READ: 0x09

    This is expected...

    3) Read 0x01:   

    WRITE: 0x81
    READ: 0xC0
    READ: 0x04

    THis doesn't match!!!!

    4) Read 0x09:

    WRITE: 0x89                                                             
    READ: 0xFC                                              
    READ: 0x00

    5) Write 0x09 (set to page 2 just for kicks:

    WRITE: 0x09
    WRITE: 0x00
    WRITE: 0x02
              
    6) Read back 0x09 to check:

    WRITE: 0x89                                                             
    READ: 0xFC
    READ: 0x00

    This doesn't make sense... that while 0x7F works fine, none of the others seem to work at all.  We did some experiments using ATEST as well, and it doesn't appear as if the device is taking writes.

    I believe all clocks are working.  100MHz on DACCLKSE and DACCLK
    DACCLK_N, and 200MHz on SYSREF. 
    TRST is low
    TESTMODE is low
    SLEEP is low
    RESETB is high after around 500mSec

    I have triple checked the pinouts and voltages.

  • While I have been testing, it appears during my testing as if SDO is always an active signal after reset regardless of the state of SPI4_EN.  Please confirm.

  • Hi Rolf,

    I have asked another engineer who are more familiar with this device to look into this. We will get back to you later half of next week. 

    -Kang

  • Hi Rolf,

    SDO has a weak internal pull up so it will be HIGH after device reset.

    Thanks,

    Eben.

  • This is not the problem.  It appears that the SPI bus cannot handle 3 bytes of data... but rather we need to have a continuous clock of 24 bits.  This was implemented in the FPGA and fixed the problem.  The multi-millisecond clock pause, I believe, is the source of the problem.  We are moving on past this issue.