This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS127L01: ADS127L01: clock phase problems

Part Number: ADS127L01


I can properly read data on SPI bus from AD, but my problem is that it shares SPI with other devices.

On data sheet is written: <<Only SPI mode 1 (CPOL = 0, CPHA = 1) is supported>>; this is in contrast with the others devices. I have to change phase when dealing with AD.

My micro is MSP430F71.

It seems that when i go back to AD, first data is corrupted.

For example:  i convert 100 data and then i put CS high to disable AD (and stop it) , than i change clock phase and deal with some other device. than change clock phase again and acquire further data from AD.

Generally the first data or second is wrong.

  • Hi Enzo,

    When you state that you (stop it), are you putting the device in power-down? If so, there is a longer delay when the device is waking up. However, as long as you are monitoring the /DRDY line and retrieving data between /DRDY and SPI Keep-Out (Figure 91), then you should get valid data.

    Can you confirm that the SLCK line is LOW after your other SPI transactions before /CS is pulled low? If you could capture the first SPI transaction when you go back to reading the ADC, that may help find an answer. /CS, /DRDY, SDO, and SCLK. (SDI should be held low during the conversion reading.)

    Regards,
    Keith N.
    Precision ADC Applications
  • Hy Keith,

    when i stop the AD i use pin Start of device, i do not put it in power down.

    When other SPI transactions are ended, i write:

    UCB0CTL1 |= UCSWRST; // **Put state machine in reset**
    UCB0CTL0 |= UCMST + UCSYNC + UCMSB; // 3-pin, 8-bit SPI master, MSB,  -  37.3.6.1 Serial Clock Polarity and Phase data sheet
    UCB0CTL0 &=~UCCKPH;
    UCB0CTL1 |= UCSSEL_2; // SMCLK

    UCB0BR0 = 2; // 12.288MHz
    UCB0BR1 = 0;
    UCB0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**

    on micro, to restart the clock with correct phase, then i put CS low.

    Anyway I will verify

  • bit UCCKPL, that if 1 put SCLK high if inactive, is always 0. So SCLK line is always down when inactive.
  • Hello Enzo,

    In most cases, you do not need to use the START function. The main use of this pin is to synchronize the device with other ADC's in the system. When you do issue a START (pulling START pin low and then high or using the START command), there will be a delay of 4-5 master clocks, plus the settling time of the digital filter. (See Figure 85 and Table 13)

    As an example, if using the low latency filter and an OSR of 32, after the START pin is pulled high, you will not have valid data until 160+5 master CLK periods later. If you are not polling the /DRDY pin and try to retrieve data before /DRDY goes high at the end of 165 CLK periods, then you would get corrupted data.

    Regards,
    Keith
  • Hy Keith,

    i'm sorry but i gave you a wrong information.

    When i deal with other devices on SPI, I disable AD, setting high CS; I do not use the start pin.

  • Hi Enzo,

    Pulling /CS high will reset the ADC's serial interface, and it will ignore any SPI bus activity. After you talk to other devices and then re-configure the SPI bus to mode 1, you can pull /CS low (immediately following /DRDY going low), and then clock out the conversion result using 24 or 32 SCLK's.

    Since you can initially get good data, I think there may be something wrong in your timing of signals after returning to SPI mode 1. Please provide a waveform capture of the /CS, /DRDY, SDO, and SCLK lines (SDI kept low) for the first reading after returning to SPI mode 1 to make sure all timing requirements are correct.

    Regards,
    Keith
  • Hy Kate,

    I will make some test and let you know.

    Thanks for your help.

  • Hy Keith,

    i have found the bug.

    In firmware in one point i did not disable AD putting CS high.

    Now acquisition is correct.

    Thanks for your help, Enzo Ternavasio

  • Hi Enzo,

    I am glad you found the bug and thank you for the update.

    Regards,
    Keith