ADS1247: RDATA Output always zero

I had to scrape a via and solder a wire to it, so the signals aren't as clean as they would normally be.

SCLK top, MOSI middle, MISO bottom.

This is sending RDATA 0x13, followed by 0xFF. Nothing received on MISO.

Zoomed in on the first RDATA transaction.

----------------------------------

Successful SPI transaction during register reads

Hi Eric,

Thanks for your post and welcome to the forum! 

I know you said it's difficult to probe, but can you probe /CS to see if it's actually being driven low as an output by the MCU GPIO? With the resistor installed, it may be having a tough time actually being driven low. You may want to un-install R42 to verify that this isn't causing the issue. Additionally, I do not see the extra /RESET command after CS is being taken low. There are some timing delays that must be accounted for as well. 

Take a look at 10.1.7 in the datasheet for an example.  

http://www.ti.com/lit/ds/symlink/ads1246.pdf

Hi Alexander,

Thank you for your reply. Since the ADS1247 is sitting on a dedicated SPI lane, I've tried permanently keeping the /CS signal low. This has produced identical results.

I am able to write the registers, and read them back. 

I've updated my config process:

• Assert START High
• Initialize SPI bus
• Take CS low, and stay low
• Send Reset Command
• Wait 1 ms
• Send SDATAC Command
• Wait for DRDY falling edge
• Wait 50us
• Write 15 registers,
• Readback and verify (this returns true)
• Send SYNC command (I've also tried RDATAC here).

Read Data

• Wait for DRDY falling edge
• Send RDATA Command
• Read in 3 bytes, while keeping MOSI high via 0xFF / NOP command.
  • (I've also tried issuing SDATAC at the begining and then issuing SYNC or RDATAC at the end)

The results are all the same. I can successfully read and write registers, but the ADC output code is always zero.  I've tried this on three different boards with identical results.

Here is my code for the Config. This much I'm sure works.

bool ADS1247Config(void)
{
    usleep(16000);
    GPIO_init();
    GPIO_write(ADS1247_START, 1);
    SPI_init();  // Initialize the SPI driver
    SPI_Params_init(&rtdSpiParams);  // Initialize SPI parameters
    rtdSpiParams.frameFormat = SPI_POL0_PHA1;
    rtdSpiParams.bitRate = 1500000;
    rtdSpiTransaction.count = RTD_SPI_MSG_LENGTH; // 1 byte
    rtdSpiTransaction.txBuf = (void *) rtdTxBuffer;
    rtdSpiTransaction.rxBuf = (void *) rtdRxBuffer;
    rtdSpi = SPI_open(SPI_RTD, &rtdSpiParams);
    GPIO_write(ADS1247_SCS, 0);
    ADS1247SendByte(ADS1247_CMD_RESET);
    usleep(1000);
    usleep(600);
    ADS1247SendByte(ADS1247_CMD_SDATAC);
	ADS1247WaitForDataReady(0);
	usleep(50);
	//write the desired default register settings for the first 4 registers NOTE: values shown are the POR values as per datasheet
	ADS1247WriteRegister(ADS1247_0_MUX0, 15, regArray);
	ADS1247ReadRegister(ADS1247_0_MUX0, 15, regArrayReadBack);
	ADS1247SendByte(ADS1247_CMD_SYNC);
	if((regArrayReadBack[0]) == regArray[0] && (regArrayReadBack[10] != regArray[10]))  /// checks that register 0 wrote okay, and that register 0x0A picked up the ID bit.
	{
	    return 1;
	}
	else
	{
	    return 0;
	}
}

And here is my Read Data:

long ADS1247ReadData(void)
{
    long Data0;
    long Data1;
    long Data2;
    long Data;
    //ADS1247SendByte(ADS1247_CMD_SDATAC);      // 16 or 17
    while (!(GPIO_read(ADS1247_DRDY)));
    while (GPIO_read(ADS1247_DRDY));
    usleep(10);
	// send the command byte
	ADS1247SendByte(ADS1247_CMD_RDATA);        // 12, but I've also tried 13
	// get the conversion result
	Data0 = ADS1247ReceiveByte();
	Data1 = ADS1247ReceiveByte();
	Data2 = ADS1247ReceiveByte();
	Data  = ((Data0 << 16) | (Data1 << 8) | Data2);
	// sign extend data if the MSB is high (24 to 32 bit sign extension)
	if (Data & 0x800000) { Data |= 0xff000000; }
	//ADS1247SendByte(ADS1247_CMD_SYNC);
	return Data;
}

Hi Eric,

Thank you for the additional information. 

Can you provide additional scope shots of the read data communication as well? Please include CS as well as MISO, MOSI, and SCLK. 

Probing all four of those at the same time is incredibly difficult. Instead I've done multiple 2 or 3 wire probes to piece together how they all relate to each other.

----------------------------------------------------------------------------------------

Sending Read Command:

MOSI, top. MISO middle, SCLK bottom

--------------------------------------------------------------------------------------

I had to zoom out in order to see the CS

All 24 SCKs top. /CS Bottom.

----------------------------------------------------------------------------------------

Zoom in of 4 SCK bytes, and then CS being asserted high.

----------------------------------------------------------------------------------------

/DRDY top, CS bottom.  CS is triggered after negative edge of DRDY

----------------------------------------------------------------------------------------

/DRDY top, SCK bottom. After about 1.5ms, the 24 SCKs are issued. /DRDY goes high on first SCK.

----------------------------------------------------------------------------------------

/DRDY top, /CS bottom. First DRDY pulse is hard to see, but it is slightly before CS goes low.

Additional update:

If I alter the values of FSC I am able to force an output of 0xFF800000. So data read is working.

However, if I leave FSC alone and only change OFC the output remains zero regardless of register values. I tried 0x000001 and 0xFFFFFF. All return zero.

I measured the voltage across the input capacitors C53 and C54, and again they are what I would expect. 110mV, and 1.65V. These voltages also appear across the pins of the chip.

DVDD and AVDD have almost no ripple what so ever, And both DGND and AGND share the same plane. Return plane is also very quite. 

I'm getting identical results on all three of my boards.

Here is snap of the layout. The three layers above the IC/traces are solid ground  and power planes.

The only layout issues I can think of the trace running under the package, and pin 8 not having  a nearby ground via

You're a full minute too late :D

But this was indeed the issue. Thank you for looking into this.

Hi Eric,

Very happy to hear that this resolved the issue! My pleasure, please let us know if you have additional questions or concerns by starting a new post.