ADS1248: DRDY toggles, but data returned always 0

There's no resistor/caps on the digital spi lines, and the traces between the microprocessor and the adc1248 are very short.

The cross-talk seems to be related to the scope ground..   I found a better connection, see pic below.

However, I don't see any activity on MISO regardless of register I read back.    

To minimize and simplify the configuration/traffic, after power-on, and after setting NRST and START HIGH,  the only SPI write I'm doing now is 3 bytes to set AIN6 and AIN7 as GPIOs:  0x4C, 0x00, 0xC0   

I've also slowed SCLK to about 100kbps, and increased the time between CSN and the first SCLK.  I've also experimented with changing MOSI on the rising edge, or on the falling edge  (the scope pics are for MOSI changing on the rising edge of sclk)

Then, in a loop I try to toggle the GPIOs (AIN6, AIN7) every second by sending  :  0x4E , 0x00, 0x00    and   0x4E , 0x00, 0xC0

However I don't see any activity on the AIN6/7 test-points.   

Not shown on the schematic, but we are using the internal oscillator by tying the CLK Pin 3 to ground.  Since NDRDY appears to toggle regularly, it would seem the internal clock is working.   Anything else that could cause the basic GPIO to not work?    

Thanks

Hi Parker, apologies I didn't have time to get to this today. Will update you in the morning. 

Hi Parker,

Thank you for providing additional information and details about the other tests. One thing I would try is leaving CS low after you send your SCLKs. It appears that you are bringing CS back high after sending SCLKs which puts DOUT into a high input impedance state. 

"

9.5.1.1 Chip Select (CS)

The CS pin activates SPI communication. CS must be low before data transactions and must stay low for the entire SPI communication period. When CS is high, the DOUT/DRDY pin enters a high-impedance state. Therefore, reading and writing to the serial interface are ignored and the serial interface is reset. DRDY pin operation is independent of CS. DRDY will still indicate that a new conversion has completed and is forced high as a response to SCLK, even if CS is high. Taking CS high deactivates only the SPI communication with the device. Data conversion continues and the DRDY signal can be monitored to check if a new conversion result is ready. A master device monitoring the DRDY signal can select the appropriate slave device by pulling the CS pin low.

"

Next, I see you are writing 0x4E , 0x00, 0x00    and   0x4E , 0x00, 0xC0. 

From this format: 9.5.3.9 WREG (0100 rrrr, 0000 nnnn)

The "4" indicates writing register, while rrrr indicates the register to be written to. E is the GPIO register on the ADS1248. 0x4E Looks good.

Next is 0000 followed by nnnn, where nnnn indicates the number of bytes to write. Here you have 0000 instead of 0001. Try changing 0x00 to 0x01.

Lastly, the byte to be written. You have 0x00 and 0xC0. 0x00 will turn all of the GPIO's off. While 0xC0 is potentially writing bits reserved with 0 to 1. Looking at 9.6.4.11 GPIODAT—GPIO Data Register (offset = 0Eh) [reset = 00h], you can see that the first 4 bits are reserved and should be written as 0000. Try changing 0xC0 to 0x0C.

Give these steps a try and let me know if this helped! 

Tried keeping chip select low all the time, not just during the 3 byte transfer, but no luck.

Similarly, I tried setting the 2nd (length) byte to 1, but no change.    However, I interpret the datasheet as saying you must subtract 1 for the number of data bytes to write.   i.e. writing 1 data byte, requires this length byte to be set to 0.

On the GPIODAT, we are using the ADS1248 which uses bits 7 and 6 f to use AIN7 and AIN6 as GPIOs.

Is there anything power or clock wise, that would prevent the AIN6/7 GPIOs from reacting? Is there any other way to tell if the chip is alive?   Because Aside from NDRDY toggling, it doesn't seem that it responds to any command (IDAC, GPIO, etc).

Thanks!

Hi Parker,

I looked over the schematic again and don't see any obvious issues. You can probe the power-supplies to double-check that AVDD/DVDD are both powered-up as expected. Next, I would try using the 10.1.7 Pseudo Code Example to verify that all of the timing periods and commands are being observed. 

However, since the device is toggling DRDY, I believe the device is alive. There may be an issue with regards to power-up timing (waiting 16mS) that may be causing an issue. I would also recommend issuing an additional RESET as well as SDATAC.  

Maximum SCLK frequency is 2MHz. Minimum is 64 * ODR (5 is default) = 320Hz. 

There is also some example code in this post that may help. https://e2e.ti.com/support/data-converters/f/73/p/340614/1190469#1190469

Thanks, the initialization is similar to what I originally was using, before trying the GPIO toggle as that seems less configuration is required to verify.  Do you see any reason why immediately after power-on, the cpu takes about a second to initialize, then the ads1248 is placed out of reset, and the start line set high, that sending these 3 bytes,   0x4C, 0x00, 0xC0   , followed by these 3 bytes 0x4E , 0x00, 0xC0, wouldn't cause the AIN6/AIN7 to go high?  The timing for the spi is in the previous scope captures... but I've also tried slowing the clock down to 100kbps but same result (No MISO activity, no GPIO toggle).    I've also tried sending a RESET command, then WAKEUP, before sending the GPIO commands.

The traces between the microcontroller and ads1248 are short.. however, the scope picks up a little bit of overshoot.. not sure if it's actually real or not.   Since we don't have any resistors in series, is the device very sensitive to where this could be the problem?

The 5V and 3.3V rails seem good, and come on at the same time.. 

Hi Parker,

Before we get to the GPIO's, can you also provide scope captures showing your reading of the registers? 

The internal reference must be turned on for the IDAC current to flow, even though you may be using an external reference. 

To use the GPIO pins, first the GPIO configuration register must be set from analog input to GPIO (register 0x0C).  Register 0x0D sets the GPIO to input or output and register 0x0E sets the pins as high or low. As you have been doing. 

To write to the registers, the RESET pin must be high, the START pin must be high, and there must be a valid CLK.  The CLK pin must either be tied low to use the internal oscillator or a valid clock actually applied. If the clock pin is floating, the deice may lock up until it is reset, either via the power pins, or the reset pin. 

One other thing to confirm is if the uC is holding the DOUT pin low or not. You could try lifting the DOUT pin away from the trace to see if it communicates when the uC is not connected.  

Hi Parker,

I've spoken at length with another member of the team about this issue and we both agree that we should start from the beginning. 

As a fresh start, please try setting the SCLK frequency to 1MHz. We know for a fact that this frequency works with the ADS1248 with no issues. 

We do in fact see data coming out of the ADS1248, as shown in the bottom right picture. The ADS1248 defaults to continuous conversion mode (RDATAC) as the result is automatically placed in the transmit buffer. As soon as SCLKs are received, data is transmitted out. Regardless of sending a RREG or WREG command, the dat will be transmitted out for the first 16 bits (MSB and MID-BYTE). ). If the command is WREG, the whole conversion will be transmitted.  If the command is RREG, then only the first 16 bits are transmitted because after the RREG command is decoded (Command and number of bytes) the Output buffer will be updated with the new register information.

With the RESET pin high and the START pin high would highly recommend that you try the RREG command for register 0 as the very first operation after power-up with no register writing or any other commands.  The default value for this register is 0x01.  And it would be good to see a scope shot of that communication.

Next, try issuing the SDATA command to see if this command works. Once this command has been sent, you can verify it is working by reading various registers and you should no longer see the conversion data in the output register when SCLKs are transmitted. We would like to see a scope shot of this communication.

If this is working, then try WREG, and read it back with RREG.  We would like to see a scope shot of this communication. 

Schematically, it appears that AGND and DGND are the same potential, but the schematic does show them both labeled as AGND. Just double-checking that they are the same net. If they are split, they should be connected as close to the ADC as possible by joining the grounds together with a low impedance connection, without any type of inductance. 

By chance, is there any isolation between the uC and the ADS1248? If so, the signals may become inverted crossing over the barrier. 

Last but not least, we would like to confirm where you are probing these signals? Should be as close to the device pins as possible. 

The previous screenshots are all probing at the pin of the ads1248.. the MCU (bga) connects directly to the chip with no resistors/isolation in between.. it makes it a bit difficult to get all spi activity captured.   We're in the process of tacking wires but in the meantime...

I've adjusted the prescaler so that SCLK now measures 926khz  (instead the previous 1.8Mhz).

After power-on , the reset is kept low, 1sec later it is released , then a sec later, Start is placed high.  A second later, I read Register 0 (3 byte transfer), and the MISO line (and CPU) see : 0xFE, 0xD6, 0x01.   (i.e. The Mux0 Register value of 0x01 is good).

Next the SDATAC command is sent ( 0x16) and the MISO line returns : 0xFE.

Finally, reading Register 0 in a loop, I see the MISO line traffic is:  0x00, 0x00, 0x01.    (The chip correctly seems like it's no longer converting.. interestingly, the read immediately following the SDATAC I see non-zero data on the first couple bytes.. presumably this is old data)

Unfortunately, doing a write to GPIO CFG register (0x4C, 0x00, 0xC0), and then commanding a read (0x2C, 0x00, 0x00), the MISO line returns 0x00, 0x00, 0x00.    Similarly, writing other (IDAC , GPIO DIRECT, MUX0), all behave the same.. they don't return the value being written to them.   

No voltage potential between AGND and DGND.     The previous scope shots are with the probe at the ads1248 pins..     there's no resistor/isolator between the cpu (BGA) and the chip, making probing a bit harder.   We're in the process of tacking wires to get the scope captures, but in the meantime,  we slowed the SCLK by 2 so that the frequency we measure is now 975khz (instead of 1.875Mhz).  Next the sequence we are doing:   

1) Power-On ,  NRST/START low, 1 sec delay , NRST High, 1sec delay, Start High , 1sec delay

2) Read Reg 0 command (3 byte transaction 0x20, 0x00, 0x00), the MISO line (and CPU) shows:  0xFE, 0xD6, 0x01

3) Send SDATAC command (0x16), MISO line returns:  0xFE  

In a loop:   

4) Read Reg 0 command , the MISO line returns:  0x00, 0x00, 0x01.   Interestingly, the first time the register is read after SDATAC is sent, the first 2 bytes are  non-zero.   Also NDRDY continues to toggle.

Unfortunately, writes to any register (ex. MUX0, IDAC0, GPIOCFG, GPIODIR, GPIODATA, etc) the RREG data returned from the registers suggests the data written wasn't latched.   For example, writing Inputs to GPIODIR (0x4D, 0x00, 0xFF) the RREG command (0x2D, 0x00, 0x00), has MISO returning:   0x00, 0x00, 0x00,      The silicon revision field returns 0x9.. is there any known issue with DIN data not getting latched?

Hi Parker,

I see, thank you for the effort. I know getting lines directly onto traces can be difficult. 

This behavior is very peculiar. The ADS1248 seems to be communicating except for the WREG command. 

One other thing to consider is that  the WREG command consists of 3 bytes; WREG command+starting register, number of registers to read, and data.  The RREG command consists of 2 bytes of commands and a NOP to read the registers.  The command sequence being used is RREG command+register starting address, the number of registers to read, and the WAKEUP command (0x00) instead of (0xFF) for NOP. This dummy byte retrieves the data. Figure 84. is incorrect as it does not show this NOP transmission. 

The only reason that WREG would not be working is if START is not high, CS is not LOW, or SCLK is too fast/slow. We know that all of these criteria are correct at a high level, which means that it may be a glitch in the communication line. We would like to see scope plots of the WREG communication (CS, START, SCLK, MOSI) at the 926kHz SCLK frequency. It would also be beneficial to see a zoomed in plot of this communication so that we can look for glitches. 

Attached is a screenshot of CSN, SCLK (<1Mhz), MOSI, MISO immediately after power-on, with 3 commands:   RREG to 0    (data returned is 0x01),   a WREG to register 0x0E with the value of 0x40 , followed by a RREG from register 0x0E.

Zooming in on the CSN, SCLK, MOSI, there is no glitches or spikes that can be seen.  

Hi Parker,

Your communication is correct but it looks like there is some over/under shoot on your communication lines, which may be causing a problem. If you have not done so already, I would try adding a small resistor (~10-50ohm) close to the signal source and a small capacitor (~30pF), near the receiver to smooth these transitions. One other thing to look into is the drive strength of the uC. You can try turning is down to ~2mA to see if that helps as well. 

If you share the layout I'm happy to take a look at that as well. 

Here are some scope shots we took on our side: 

RREG 0, default settings:

WREG 0:

RREG 0:

The traces between the adc1248 and the cpu are about an inch long. We're in the process of reworking a board to add the resistor/cap.. however, I'm not sure the overshoot we see isn't an artifact of the scope.     The microcontroller, doesn't support configuring the drive strength. 

Interestingly, it's not 100%, but slowing SCLK down more, and using retries, the registers are returning the data that was written to them. 

If the ADC values read correctly,which I'll test tomorrow, this will at least be a workaround to move forward.    I'm also looking at minimizing the amount of register writes needed after all registers have been initialized,  ideally just writing to MUX0  to select the input  (leaving all other registers, including IDAC to the value they are initialized with once).

Hi Parker,

One other thing to try is to increase the amount of time after the last SCLK is transmitted before pulling CS high. tSCCS, requires 7tclk minimum.

With the workaround in place, the register read back contains the data written:

Once initialized, we minimize the number of writes/retries, by only updating the MUXSEL  : 

0x40 0x00 0x01

0x40 0x00 0x13

0x40 0x00 0x25

For now the PGA, REF, and IDAC settings will be the same for all channels.

However, despite seeing ~2V at R35, the adc data is either zero or 0xc00000..  regardless of the voltage across CH0/1 & CH4/5,  or the RTD resistor across CH2/3.

It's possible it's still a lingering issue with the flakey SPI communication, but is there anything from the register setup that could be the cause?

Hi Parker,

Did you have a chance to try increasing the amount of time from the last SCLK to pulling CS high? tSCCS, requires 7tclk minimum.

From a register setup, have you ever written to the FSC register? If so this may be the issue.

9.4.5.2 Full-Scale Calibration Register: FSC[2:0]; The full-scale calibration value is 24-bit, straight binary, normalized to 1.0 at code 400000h.

Thanks the FSC was being written to incorrectly.    Leaving the register untouched, I'm seeing much better values.

Also, I increased the falling edge of the last SCLK to the rising edge of CSN to be 125usec.. however, this didn't seem to help with the communication.  I can't get anywhere near an sclk of 1mhz.     I'm currently running at 100kbps and it seems to be mostly stable.