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.
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
Could you please check your DVDD power supplies are stable? Once confirmed, we can look into this further for you.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
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.
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.
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 ENABLEDWRITE: 0x01 WRITE: 0x18 WRITE: 0x80 /CS DISABLED/CS ENABLEDWRITE: 0xFF READ: 0x80 READ: 0x09 /CS DISABLED/CS ENABLEDWRITE: 0x81 READ: 0xC0 READ: 0x04 /CS DISABLED
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:
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 ENABLEDWRITE: 0x01 WRITE: 0x18 WRITE: 0x80 /CS DISABLED
The third command read it back incorrectly:
/CS ENABLEDWRITE: 0x81 READ: 0xC0 READ: 0x04 /CS DISABLED
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 ENABLEDWRITE: 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 2 (read):
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.