I am trying to communicate with the ADS1241. I am not currently able to receive any information from the device. I was wondering if there are specific commands I need to send (or if I need to reset the device) prior to being able to use it as intended.
My thinking was to try to establish known communications with the device first and then, when I'm sure I have the communication protocol down correctly, to try to read analog inputs. Thus, my first (and currently only) attempt at reading data device has been to try reading the FSR1 (0B hex) register as it has a reset value of (55 hex). This should mean that I get a combination of one's and zero's when I read back the information.
Currently I am using the 4.91MHz crystal as I'd like a sampling frequency of 30Hz. An oscilloscope currently reads a sine wave with a period of 200ns, which equates to a master clock speed of 5MHz, which is at the top end of the data sheet spec. With 3.3V powering the device, I am reading just over 3V as the logic "high" for the clock and master out / slave in line. However, I am getting some unusual coupling on the slave out / master in line. I don't have a screen cap or anything of the o-scope, but I've faithfully redrawn it as follows in paint:
This is the command I am trying to send: The first byte is the read register command (0001) followed by the FSR1 register (1011), followed by the fact that I want to read 0 additional registers (xxxx0000). The slave out line couples with both the clock and master out data transmissions, but the voltages there range from about 0.45V when it's just the clock to about 0.75V when the master and and clock are both high. I'm not a terrific C programmer, so I'm using LabVIEW to run the SPI bus for me. That said, there is a read command that clocks out eight 0's for each byte you state that you would like to read. When I use this command, I get the following:
The coupling is still there, but I'm not getting any response. The data sheet says to wait at least 50 (t_osc), which would be 10us, before attempting to read the data. I have no direct control over the timing here with LabVIEW, but an oscilloscope gives the time difference between the end of the read register command and the start of the dummy bytes to shift data out of the ADC as approximately 220us. The data sheet also states that if I wait three DRDY cycles it will reset the serial interface. However, even at a sampling rate of 30Hz, the DRDY pin should only cycle every (1/30) = 33ms, and I'm well within that limit. Even if it cycles once for each of 8 input channels for every sample, that's still (1/240) = 4ms between pulses, and again, I am well within ONE pulse cycle, let alone three. I am not sure what it is that I'm doing wrong. The device is powered, the DSYNC, PDWN, RST lines are all tied high, grounds are grounded, power supplies are at 3.3V, and everything seems to be working fine on the microcontroller end. The oscilloscope shows what I believe the datasheet is telling me to do, but I have tried two separate ADC's and neither of them are functioning. Again, I'm concerned that there is a startup sequence not specifically mentioned in the data sheet that I'm not using.
Thanks for your help! Chuck Saunders
I would also like to add that I have BUFEN and POL both tied low.
Charles,
You have not stated or shown what you are doing with CS. CS must remain low throughout the entire communication transaction. The noise on the MISO may be because CS is not low, and the output is in tri-state. It may also be noise due to poor grounding and the SCLK line is coupling to the line. Is it possible for you to send us your schematic?
Best regards,
Bob B
Bob,
I'm sorry, I have CS tied to ground. I was initially testing with a bus speed of 1MHz, but I slowed to 250kHz hoping for a response or at least to minimize the coupling, and I got neither. Attached are the board and schematic files for Eagle for my circuit.
Thanks again,
Chuck
8054.Slave_final.sch
8168.Slave_final.brd
Chuck,
As you are pulling CS high on your board, I'm assuming that you are pulling CS low with your micro. If this is the case, you must make sure that the CS is low for the entire communication. It must not toggle between bytes. Have you verified that CS is remaining low?
There are a couple of other things I noticed with your schematic that may result in future issues. There are no bypass caps on your board and there is also the possibility that the op amps could drive the analog inputs above (or below) the supply rail on the ADS1241.
I'm sorry to not have followed up with this.
My issues stemmed from LabVIEW embedded for arm (2010) and its spotty handling of the SPI interface between different families of microcontrollers. After lots of troubleshooting, I finally realized that LabVIEW does not toggle the CS line automatically on the LM3S8962 microcontrollers but does toggle it automatically on the LPC2378 microcontrollers.
When LabVIEW toggles the CS line automatically, it does *not* allow me to toggle the pin manually. I was trying to allow for the requisite set-up time between issuing the read data command and then reading the converted data by manually setting the CS line low, issuing the read command, then trying to read the conversion data. Again, LabVIEW completely ignored the fact that I was trying to keep CS low between commands, and thus the chip was responding as though it was an aborted command. There's no way to change how LabVIEW handles the CS line during data transmission shy of rewriting the C function it calls, so my fix was to slow the bus speed to accommodate the set-up time in one clock pulse.
No worries Chuck!
Thank you for the follow up!
Regards,
Tom