TM4C123GH6PM- 24Bit external ADC SPI Communication (Missing data or Getting wrong data)

How are you setting the time between samples? Did you record a time stamp with each data point? If not, that is the the first or second step I would take.

The first, if I could, would be to place a logic analyzer or 'scope on the chip select and set the trigger for missing pulses.

Robert

Hello Amit and Robert

My SSI config and ReadADC function code are in below. I checked Data Ready pulse on scope and its period is as expected. It is same with output data rate of ADC frequency. 

In fact, I am not reading ADC data continously. For getting  one 24 bit data, I make CS high to low. I am repeating same process for every data reading. 

I tried now in continous mode,I send only one CS signal to read 3X24 bit. Problem remains same.

void SPIInit(void)
{
SYSCTL_RCGCSSI_R |= 0x01; // Activate SSI0
SYSCTL_RCGCGPIO_R |= 0x01; // Activate PortA
while((SYSCTL_PRGPIO_R&0x01) == 0){}; // Ready?
GPIO_PORTA_AFSEL_R |= 0x3C; // Enable Alt Function on PA2,3,4,5
GPIO_PORTA_DEN_R |= 0x3C; // Configure PA2,3,4,5 as SSI
GPIO_PORTA_AMSEL_R = 0; // Disable Analog Functionality on PA
SSI0_CR1_R = 0x00000000; // Disable SSI, Master Mode
SSI0_CPSR_R = 0x02; // 18 MHz SSIClk, SSIClk(8MHz) = SysClk(80MHz) / CPSDVSR * (1 + SCR)
SSI0_CR0_R &= ~(0x0000FFFF); // Clear Related Bits
SSI0_CR0_R |= 0x000004C7; // SCR = 0x04 , SPH = 1, SPO = 1 Freescale Mode, DSS = 8-Bit Data
SSI0_CR1_R |= 0x00000002; // Enable SSI
}

unsigned long Read_ADC1(char adress)
{

a = 0x0000;
ADCdata = 0x00;

clrbit(ADC_CS1,0); //ADC Chip Select
a = SSI0_DR_R; // Dummy Read
read_adress = (adress<<1);
read_adress |= 0x41;
SSI0_DR_R = read_adress ;

a = SSI0_DR_R ; // Dummy Read

if(adress<3)
{
SSI0_DR_R = 0; // Write SPIBufffer. Sets TX Flag, if not done read will not clock.
while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
ADCdata += SSI0_DR_R;
ADCdata = (ADCdata<<8);
SSI0_DR_R = 0;
while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
ADCdata += SSI0_DR_R;
ADCdata = (ADCdata<<8);
SSI0_DR_R = 0;
while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
ADCdata += SSI0_DR_R;
}
setbit(ADC_CS1,0);
return(ADCdata);
}

Hello

I realized on scope that sometimes CS signal goes wrongly low to high and after it goes high-to-low as you can see in below scope screen. This happens in continous read mode. Normally one CS signal should be in line when DR falling signal is sensed.

Normally It looks like below 

Serkan,

That's not the question I asked. Let me try a third phrasing.

How are you triggering the a/d to start a conversion?

Robert

Serkan said:

100K pull up resistor tied to VCC in data ready pin. 100K value is suggested in datasheet of ADC

[Reading the thread I have been unable to find a mention of which external ADC is being used]

Hello

I am sure about 100K. It seemed also so weak to me. I changed now to 4K7 and data ready signal is sharper now as you can see in below pic

ADC is MCP3919 3 channel 24 Bit ADC. Data ready sharpness problem solved but  reading problem still continues. 

In addition to the good advice provided by Robert & Amit - and in light of the (just arrived) revelation that you are continuous clocking the ADC via the MCU's PWM signal - can that PWM signal be (fully/properly) released from your, "suspect list?"   (your scope's 3rd channel should monitor the PWM output - which clocks your ADC - to establish it's "alibi.")

Another point - we see 2 full sine wave periods prior to your signal's, "steep dive."   Would it not prove useful to extend your trace time-span - and determine if that "steep dive" occurs consistently - and (possibly) at a regular rate?   (such may indicate an overflow or some form of "disorder" in your ADC clocking.)

I noted from square one - yours is a 24 bit ADC - and those require very, very special pcb layout, signal routings, and most proper decoupling and powering.   Is your's a "Pro" (factory) board?   If homemade - please tell us it's not on a breadboard - or worse.

The fact that your graph reveals (at least to me) two apparently good measurement cycles - and then goes "haywire" - leads me to doubt your clocking or perhaps even your MCU's ADC buffer strategy and/or implementation.   My quick read could not find that detail - may prove useful...

As always - your "need" for 24 bit conversion would be of interest...

Serkan said:

I am sure about 100K. It seemed also so weak to me. I changed now to 4K7 and data ready signal is sharper now as you can see in below pic

The data ready pin indicates if a new conversion result is ready to be read. The default state of this pin is logic high when DR_HIZ = 1 and is high-impedance when DR_HIZ = 0 (default). After each conversion is finished, a logic low pulse will take place on the data ready pin to indicate the conversion result is ready as an interrupt. This pulse is synchronous with the master clock and has a defined and constant width.

The default state of the DR_HIZ bit bit in the Status and Communication Register is zero. If the DR_HIZ bit is written as a one by the TM4C software, then the Data Ready output will be driven high by the ADC which should give a sharper edge without having to adjust the pull-up resistor.

Serkan said:

unsigned long Read_ADC1(char adress)
{

a = 0x0000;
ADCdata = 0x00;

clrbit(ADC_CS1,0); //ADC Chip Select
a = SSI0_DR_R; // Dummy Read
read_adress = (adress<<1);
read_adress |= 0x41;
SSI0_DR_R = read_adress ;

a = SSI0_DR_R ; // Dummy Read

if(adress<3)
{
SSI0_DR_R = 0; // Write SPIBufffer. Sets TX Flag, if not done read will not clock.
while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
ADCdata += SSI0_DR_R;
ADCdata = (ADCdata<<8);
SSI0_DR_R = 0;
while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
ADCdata += SSI0_DR_R;
ADCdata = (ADCdata<<8);
SSI0_DR_R = 0;
while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
ADCdata += SSI0_DR_R;
}
setbit(ADC_CS1,0);
return(ADCdata);
}

There may be a race-condition where the Read_ADC1 function gets the reads from the ADC out of sync.

Suggest changing the Read_ADC1 function to add a check for the receive FIFO being non-empty before the dummy reads:

unsigned long Read_ADC1(char adress)
{

    a = 0x0000;
    ADCdata = 0x00;

    // Flush SSI FIFO of any stale receive data
    while((SSI0_SR_R&SSI_SR_RNE)!=0)
    {
        a = SSI0_DR_R ;
    }

    clrbit(ADC_CS1,0); //ADC Chip Select
    read_adress = (adress<<1);
    read_adress |= 0x41;
    SSI0_DR_R = read_adress ;

    while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
    a = SSI0_DR_R ; // Dummy Read to clear undefined receive data during transmission of Control Byte to ADC

    if(adress<3)
    {
        SSI0_DR_R = 0; // Write SPIBufffer. Sets TX Flag, if not done read will not clock.
        while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
        ADCdata += SSI0_DR_R;
        ADCdata = (ADCdata<<8);
        SSI0_DR_R = 0;
        while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
        ADCdata += SSI0_DR_R;
        ADCdata = (ADCdata<<8);
        SSI0_DR_R = 0;
        while((SSI0_SR_R&SSI_SR_RNE)==0){}; // Receive FIFO Not Empty
        ADCdata += SSI0_DR_R;
    }
    setbit(ADC_CS1,0);
    return(ADCdata);
}

Hello Friends

Firstly thanks for suggestion on code Chester. I added your code line suggestions to my project.

I observed my PWM signal that goes to ADC clock input. It seems OK. But this PWM signal is suspicious for me. Because I have a jumper on PWM line. When I remove jumper my ADC data buffer remains with last data sampling and remains with this last data. When I plug jumper again, It takes new measurements into buffer and refresh yourself. 

My PCB is factory made by the way corresponding to CB1's question.

It looks like my graph. Because in my graph sin wave firstly seems normal  then there are missed data and after it continous with new data suddenly. Maybe there can be a problem with PWM signal that I can not see.

I will record a  time stamp with each data point. I will do Robert's suggestion.

Serkan

You've not (really) followed my suggestion to extend your number of data captures - so that any, "regularity and/or repetition" of those "bad data reads" - is revealed!

Your writing suggests that your pwm signal path (interconnection) - between MCU and external ADC - may not be "short/sweet" - which is ALWAYS the requirement of any high resolution ADC.   Also - your report, "PWM signal that goes to ADC "seems OK"" is not especially convincing.   As past suggested - channel 3 of your scope should monitor your (critical) ADC clock (aka your MCU's PWM signal) - should it not?   Usually - but not always - that clock duty cycle should be close to 50% - and should "rise & fall" to specification and that signal line should be "free" from any other devices, routings or interconnects.   (other than the one between MCU & ADC) 

The powering of your "factory made" ADC board must be proper (sufficient & fully bypassed) and w/in ADC board's spec.  

Should your PWM signal deviate from the ADC's spec the issue you report is far more understandable. (and correctable.)

Serkan said:

I am sure about PWM clock is with in ADC spec.

That is likely true (sometimes)!   But what happens at the point when your conversion accuracy is lost?   If you've "measured" the PWM clock when, "All is well" that may not be sufficient - is that not so?

Again - your measure of the PWM clock - THROUGH the moment of data error - seems easiest & fastest.   And - this (indirectly) may accommodate poster Robert's good suggestion to "time-stamp."    (i.e. should the PWM clock vary or otherwise deviate - your time-stamps will be directly impacted.)

Now the greater complexity appears w/in the MCU & your management of the SPI - but w/"uncertain ADC clock rate" - your time-stamps are doomed.   (and they may also be impacted by MCU mishandling - yet monitoring of the PWM clock proves far faster/easier - and should warrant a first order (immediate) inspection.)  

May I ask poster Robert to comment upon (another's) suggestion of, "race?"   To my mind - the fact that 2.5 full ADC cycles evidence "No race" reduces "race" as a primary cause.   (unless the race slowly/gradually "builds" - and only then - wreaks its havoc.)

Hello Friends

After 2 day hard working on this issue, after changing only test buffer size to certain scale of 50 Hz sampling size, problem solved. All problem was related with my plot settings. 

Robert Adsett said:

Don't be too quick to declare 'problem solved'

Indeed - as listed - other items (surely) lurk.   Plot failure id is one symptom - not a likely cure.

Famed, unearned, "Self-Awarded Verify" has yet to appear - good that...

Serkan said:

My code does not enter to while(1) loop after a short time in the starting.

Your code reveals three "while" loops - does it not?   Your identification of the specific "while loop" which remains un-entered proves helpful.

As your code fails to reach that point - what has your debugging revealed as to "hang point?"

Have you made code changes or HW changes (beyond the pull-up value) which may have launched this (new?) issue?