ADS1148-Q1: Issue in obtaining data

Alex,


Looking through your schematics and layout, I don't see anything specifically wrong. As you've mentioned, you've verified that START and /RESET are both high. I would also make sure the CLK pin is tied to ground so that the internal oscillator is enabled. After that, the device should be operating. Without writing to the device, can you see the /DRDY give a periodic pulse? The default data rate is 5 SPS, so you may see a narrow pulse every 200ms.

Can you write to and read from the device configuration registers? I want to make sure that the write register commands that have been issued are understood by the device and that the read command works.

Also, it looks like the you do issue the SDATAC command. To read out data, you need to issue the RDATA command and clock out 16 more SCLKs to get the data. Make sure the /CS low spans the entire transaction to read data.

Regardless, if you have scope photos of your communication, I'd be interested in seeing them.


Joseph Wu

Thanks for getting back to me! I went through and got an image of each of the signals being sent to the ADC.

All of the oscilloscope images are with this code 

void main(){
    SYSTEMConfig(SYS_FREQ, SYS_CFG_WAIT_STATES | SYS_CFG_PCACHE);
    DelayMs(20);
 
    // set up SPI
    SpiChnOpen(
        SPI_CHN_R,
        SPI_OPEN_MSTEN | SPI_OPEN_MODE8 | SPI_OPEN_CKE_REV,
        80000000/LED_SPI_SPEED
    );
   
    AD1PCFGbits.PCFG8 = 1;
    mPORTBSetPinsDigitalIn(BIT_8);  //DRDY in
    mPORTDSetPinsDigitalOut(BIT_9); //CS out
    mPORTBSetPinsDigitalOut(BIT_7); //Start out
    mPORTBSetPinsDigitalOut(BIT_9); //Reset out
    mPORTDSetBits(BIT_9);           //CS High (off))
    mPORTBSetBits(BIT_7);           //Start High
    mPORTBSetBits(BIT_9);           //Reset High
 
    DelayMs(200);
    can_init();    
 
    mPORTDClearBits(BIT_9);         //CS Low (on)  
        while(1){
            while(PORTBbits.RB4){}
               SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[0] = SpiChnGetC(SPI_CHN_R);      //Caliper Temp 1
            while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[1] = SpiChnGetC(SPI_CHN_R);   //Caliper Temp 2
            while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[2] = SpiChnGetC(SPI_CHN_R);      //Rotor Temp 1
            while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[3] = SpiChnGetC(SPI_CHN_R);   //Rotor Temp 2
            while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[4] = SpiChnGetC(SPI_CHN_R);      //Brake Pad Temp 1
            while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[5] = SpiChnGetC(SPI_CHN_R);   //Brake Pad Temp 2
            while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[6] = SpiChnGetC(SPI_CHN_R);    
           while(PORTBbits.RB4){}
                SpiChnPutC(SPI_CHN_R, 0xFF);
                    CANToSend[7] = SpiChnGetC(SPI_CHN_R);
                 
        CAN1TxSendMsg(0x201);  
    }
}

Data In & Clock

Data Out & Clock

DRDY & Clock, video on gfycat

DRDY & Clock +200ms, video on gfycat

/CS is tied low throughout and I made sure not to run the SDATAC command and I believe the RDATAC is the default mode of the ADC. I am not sure if I can write to the registers, I have tried to multiple times seeing if there is a noticeable change when sample rate changes from 5hz to 100hz or higher but I haven't been able to see any impact. I double checked and Start and /RESET are held high throughout the entire cycle. The DRDY appears when the trigger is set but as shown in the video it doesn't correspond to a clock cycle correctly and it's width wanders a fair amount. I also looked ahead 200ms and saw that the variation in the DRDY is pretty strong and still failed to correlate with the clock signals at all. 

Alex,


Looking at your pictures and videos, you're not showing much information. It would have been better to use a 4 channel scope and capture more information on the same screen. This is important to verify the communication to the device.

The first photos show SCLK and DIN, and then SCLK and DOUT. DIN only clocks in FF repeatedly, and it looks like DOUT clocks out 00. For the Videos, it does look like you are running at a data rate of 5SPS, where you look at DRDY.

However, I do have a few questions or comments.

1. How do you determine when to read the data? Normally, you use the /DRDY as an interrupt, and then clock out 16 bits of data when /DRDY transitions low. If you continue to add more clocks, you've already clocked out all of the data, and I don't think you'll get anything on the DOUT until the next /DRDY indication where the device has completed a new conversion. From the videos, it just looks like you're constantly sending in SCLKs without timing these data reads to the ADC conversion timing.

2. Also in the videos, the /DRDY doesn't go all the way back to ground. It looks like the low is about 1.6V above ground. Is there something misconnected in the digital part of the circuit?

3. It's still important to verify the ADC SPI communications. You should be able to read from the registers with the RREG command. This is the best way to verify that the registers were correctly written to. You should at least capture a write command with the scope (SCLK + DIN). I just want to see that the SPI is written correctly and that you're using the correct version of SPI.

4. Is there a reason that you aren't using /CS? It helps segment the commands and if there are problems with noisy SCLK this can reset the SPI to make sure the error doesn't continue.

If you can, get a 4 channel scope or logic analyzer. It's important to see the communication timing for writing to and reading from the device. Then work on timing the read based on the /DRDY transition low.


Joseph Wu

1. Right now on my code I have

while(DRDY high);

while(DRDY high);
SPIChnPutC(SpiChannel, 0xFF);
SpiChnGetC(SpiChannel);
SPIChnPutC(SpiChannel, 0xFF);
SpiChnGetC(SpiChannel);
while(DRDY high);
SPIChnPutC(SpiChannel, 0xFF);
SpiChnGetC(SpiChannel);
SPIChnPutC(SpiChannel, 0xFF);
SpiChnGetC(SpiChannel);

x2

so that I wait for DRDY to go low before running two 8bit Clock cycles and read back the data from those. However, as shown by the oscilloscope the SPI Clock doesn't coincide with the DRDY pin going low at all. I'm not sure why that behavior isn't correct because 2 SPI Clock cycles at 4Mhz is way faster then the 200ms for DRDY to go low again. I will work tonight on setting up my code for an interrupt on the DRDY pin as recommended to see if that solves that issue.

2. DRDY seems to only go down to 1.2V which might be causing issues on detecting whether or not the pin is low. I looked through both the schematic, pcb design, and physical board to see any connection that could be holding the pin at 1.2V instead of going to ground. There is nothing visible that could cause that behavior except possible failure/poor connection on the ADC or incorrect programming of the PIC32 chip. Once I start coding the interrupt I'll double check the code and make sure the PIC32 isn't trying to set the same pin high while the ADC is pulling it low.

3. I have tried to send it the RREG command and this is the 4 channel reading, from top to bottom the inputs are: Clock, DIN, DRDY, DOUT. Here is a closer view of DIN & Clock. For the code, outside of a while loop I send the ADC 0x16 over SPI to command the ADC SDATAC. Then immediately after inside a while(1) loop I send the ADC 0x20 for RReg and 0x03 to read 4 registers starting at register 0. Then I send 0xFF four times to read out those registers (The results are the same with 0x00 is sent instead of 0xFF). DOUT doesn't follow those clock signals and instead sends about 16 bits worth of 1s directly after DRDY pulses low, even though SDATAC should've been heard by the ADC and DRDY has no reason to go low. 

4. I have tried both the default-setting data read code as well as the read register code both with and without /CS and still see continuous CLK signals and no changes to other behaviors seen on the oscilloscope. 

I will work on setting DRDY as an falling edge interrupt tonight into tomorrow and hopefully have positive results to share.

Alex,


Just a really quick reply:

1. What is your SPI clock rate? You mention 4MHz but in the previous oscilloscope photo, it looked like 2 SPI clock for each 2us division. Note that for a 4.096MHz external master clock, the fastest SPI clock rate is going to be about 2MHz. You can find that in the Timing Requirements table on page 11.

2. If the DRDY only goes down to 1.2V, then there is probably some sort of contention for that pin from the master (maybe the pin is set as an output?). Regardless, the problem in 1 might be related to this problem in 2.

3. Looking at the scope photo, you have the wrong version of SPI. For the ADS1148, the clock idles low, and data is clocked into the device on the falling edge of SCLK. For you close up scope shot, it appears that you clock do have the clock idling low, but you have the input data trying to clock data into the device on the rising edge. Fix this and check on the read result again.

4. Ok. Again, the data is set up on the rising edge and clocked in and out of the device on the falling edge of SCLK. I think this is called SPI Mode 1, where CPOL=0, and CPHA=1. Check over how you have the SPI set up and try it again.


Joseph Wu

Sorry about the late reply.

I've been working through getting interrupts to be functional on my PIC32 board as I am pretty sure that is a major problem in getting out actual data. Changing the SPI mode is a simple fix. I'm still unsure why the method of waiting for DRDY with a while(DRDY high); didn't force the program to wait for it to go low but I'm midway through testing interrupts and hopefully I'll have good news soon. 

Thanks!

Alex