The DAC081 (we are specifically using the DAC081C085) is an 8-bit DAC. You control its output by writing two bytes to it using I2C.
Writing to is working correctly for us.
But when we read the two bytes back, the first one is correct and the second one is always zero.
We have verified all of the above, writing and reading as described, by watching the bus with a good O'scope.
We had suspicions there might be something wrong with our I2C code. So we have tried reading more than two bytes back. What you would expect happens: the device "wraps around." The first and other "odd" bytes are correct, the even bytes are always zero.
We wonder if this device has ever been read successfully.
Thank you for any feedback and suggestions.
The READ/WRITE functionality is tested on every part at production (Final Test).
Could you give me more detail on your I2C transactions (bit sequence, or even a scope display image for both SCL and SDA), and the slave address (or are you using the broadcast address) you have set on the device?
I will try to reproducde your conditons on my bench... and take it from there.
No scope photo available.
We were using the regular address.
Please take my word for it that all of the writes worked. We were able to write every bit pattern and see the results in the output. That means we understand how the 8 bits are organized in the 16 bits of register space in each device. It also means we understand addressing.
We wrote various bit patterns and read them back. Since always got the first byte back correctly, that's a pretty good clue that we were addressing the device correctly both on the writes and the reads.
And, remember what I said about reading back more than two bytes: the functionality "wrapped around." The odd bytes we read back all matched the first byte we wrote. If there was something wrong with how we were reading bytes, then how is it that we can read the "odd" byte repeatedly? And, remember, we have proven that we can write any bit pattern into the device and see the appropriate results in the DAC's output.
Thank you for trying to reproduce our problem.
It will take me a day or 2 to get my bench up and running --- for one, I don't have the device handy at this moment. But I should be able to share my results with you by Tuesday next week.
Thanks, Tom, looking forward to the results of your test.
I am attaching a PDF with the scope images for 2 subsequent I2C transactions - the link should be somewhere at the bottom of this post.
The device I used was DAC081C085.
I grounded both address pins, giving me address A[6:0]=0001001.
The data payload for the first transaction was 0x08A5.
The first page of the PDF shows the WRITE to Slave operation.
The second page shows the subsequent READ from Slave operation.
Note that DAC081C085 responded with data payload of 0x08A0 - the "5" was lost because this is an 8-bit DAC so the last 4 bits of WRITE transaction have been ignored.
Hope this helps, Bill. If not, please do not hesitate to contact us again.
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. 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 respect to these materials. 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.