I've been trying to communicate with an ADS1118 over SPI.
From the documentation, it suggests the default Config Register value should be 0x85 0x83.
When reading, I get two bytes 0x00 0x00 (data), followed by 0x05 0x8B. OS being 0, unsurprisingly it does not respond to new values in the Config Register.
Any idea why I would be seeing this value right off the bat?
Welcome to the forum! Can you send us some scope shots of the communication? What are you trying to write to the ADS1118? What you are reading back is the default value plus the pull-up enabled on the DOUT pin.
I have tried writing both actual config and 0x00 0x00 (invalid, so it'll just be a read).
I have also tried it at both 4MHz and 100kHz.
The default also should have OS bit high (can issue a command) but does not -- scoping DOUT does suggest a pullup, so I think it's correct.
The OS bit never seems to change to 0x80.
I'll see if I can get some scope shots. Be "fun" to get separate probes on DIN and DOUT. :)
Actually it sends and receives the same thing over and over again, so I'll just take them separately. Just a sec...
I am using CPOL 0, CPHA 1 as per the documentation. These scopes were taken separately, but the signal is more or less periodic.
It all looks OK to me, honestly, except that OS starts and stays at 0...
Hmm, after some investigation I noticed I'm sending 10 to the NOP. That'd explain why sending 0x00 0x00 gives the same result.
Unfortunately, 01 also gives the same result -- still receiving 0x00 0x00 0x05 0x8B...
Is is possible for you to capture SCLK at the same time as the DIN and DOUT shots so I can see where the actual clock transitions relative to the data?
It does indeed appear that the config is not getting written. I will assume that the CS going low is meeting the required timing requirements. I do notice that DIN is going tri-state. The digital input pins should not float. I'm not sure if this is the issue, but I would add a weak pull-up to the DIN line, and any other pin (CS for example) that might also be floating.
I would try increasing the time between the CS going low and the beginning/end of the transaction. What are you using for communication, ie micro, fpga, etc.?
I'm using a NXP LPC1343. I'll give a try about CS -- it's at about 3X the SPI clock time presently. That should be well above the minimum though, especially since I'm running it at 100kHz vs
After slowing everything way down with no success, I tried instead just swapping it for a different chip. I was measuring straight on the pins, but perhaps MOSI was for some reason not reaching the chip... I am now getting data and it appears to be reading my config settings.
I do have one question though: I am in power-down single-shot mode. CNV_RDY_FL seems to be reflected by High/Low before I send any SPI data. However on the actual register read, I am still getting 0 for OS and 1 for CNV_RDY_FL *at all times*. I have even tried sending all 0s after requesting an earlier conversion, and they never go... Do these bits only work for read in continuous conversion mode?
The CNV_RDY_FL should follow the operation in either mode as it is the same status used for DRDY. I'm not sure how often you are running your loop, but if the OS is set high each time you execute the loop, the device will always be converting, which may be the reason why CNV_RDY_FL is always high. I suggest you start the conversion, then when you poll make sure the OS bit is zero.
Ah ok, I had thought the 'device will ignore conversion requests if already converting' would cover that case, making it a safe way to request both new conversions and verify when they were complete. I will try that... So then, to read the newest status, one has to send a valid config (as opposed to a NOP) in the first two bytes, just with OS bit 0?
I believe that your original understanding is correct. I would use the aforementioned method to verify that the conversion is actually starting and that at some point you know when the conversion is complete and the data is available. Think of it as stepping into the water instead of diving in. I think the question still remains as to whether the configuration register is actually being written. Have you tried to just change the configuration settings (like gain or data rate) and seeing if it is changing?
We've resorted to timing and ignoring the status register readback of OS, as it consistently reads OS=0 whether I wait until I know it's done or not.
Still don't know why. I'm going to see if I can set it up to not need SSEL first and come back to this later if I get the time.
The configuration register is definitely being written -- I am successfully reading all channels, and have done so at 250, 475 and 860 Hz,
as well as the pleasantly surprisingly accurate cold junction temperature...
It's working fairly well in this setup -- with the proper filters installed it's fairly stable using the full 16 bits at +/- 256mV, which is great.
I'll post back if I find out why the OS bit is giving me this trouble.
By the way, on the ADS1118 data sheet, slight bug report...
There is a section for Power-Down Mode (p. 19) which talks about a PWDN bit.
However Registers makes no mention of it at all. Guessing this feature got folded into MODE for this A/D.
I'm experiencing the same "OS always zero" read back. But not only that, also the cnv_rdy_fl stays always hi in my case.
Do you experience that also and what mechanism do you use to determine that the read converter data is then valid?
I would really like to hear your experience for this chip as the datasheet lacks a lot of info.
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.