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.

ADS1255: DRDY sometimes stays high

Part Number: ADS1255

Hi there,

I hope you can help me. I am using ADS1255 with 8Mhz Clock and 7500SPS.

The ADS1255 is communicating with an Arduino Uno board via SPI. I am using this library https://github.com/adienakhmad/ADS1256.

I'm waiting for DRDY goes low and then read the channel.

PWDN & RESET is tied to 3V3.

Normally, if I only read from the ADS1255 in a while loop where no other functions causes greater delays, everything works fine and I get the data.

But if I add some things in the while loop, which causes delays (for example Print functions) then sometimes  my program hang up @adc.waitDRDY();  where I am waiting that DRDY goes low so that I can read new Data input. But the problem is that the DRDY is held high and I dont know why.

If I add the command SELFCAL after the delays, before I wait for DRDY so that I can read new data, the problem is gone.

So it seems that the cause is that DRDY is sometimes (sometimes after 5 seconds, sometimes after 45 seconds) held high. But I really dont know why. Also it seems to make a difference how fast I take the Samples. It seems that lower sample rates doesnt really cause this problem so often than higher sample rates.

Do you have any suggestion what it could be? Maybe some timing issues anywhere?

I hope you can help me. If you need some further information please tell me.


Kind Regards,

Lukas

  • Hi Lukas,

    Are you reading data continuously during the while loop, or are you constantly sending the mux / sync / wakeup commands? Are you only using 1x channel, or both?

    I think the short answer is that you need to remove the additional functions within the while loop, or slow down your conversion speed. I have seen other people have this same problem in the past, where their controller is trying to do too much during conversions and they are missing data.

    You could also send scope shots or logic analyzer captures of your communication lines to better understand what is going on.

    -Bryan

  • Hi Bryan,

    Thanks for your response!

    I am constantly sending the mux/sync/wakeup command and I am only using one channel.

    Maybe I can make the additional functions faster. The additional functions and the delay in the while loop is only present if I want to adjust something over the touchscreen. Normally I need fast data rates from ADS1255 for my system. Maybe a command after the delays like RESET or SELFCAL(maybe not the best option because ADC data could be slighlty changed after that), before I read out DRDY, could be a solution so that the program doesnt hang up.

    Do you have an explanation or an idea why the DRDY is held high forever (when it hang up) sometimes?

    It's a pity because I dont have a scope nor a logic analyzer, so I can't go deeper.

    Kind Regards,

    Lukas

  • Hi Bryan,

    Thanks for your response!

    I am constantly sending mux/sync/wakeup commands and only using one channel.

    Maybe I can make the additional functions way faster. The delay in the while loop is only present if I adjust some parameters on touchscreen. Normally I need high data rates for ADS1255. Maybe a command like RESET or SELFCAL after the delay could also be a solution so that it doesnt hang up. But yeah maybe I can make the functions faster.

    Do you have an explanation why DRDY is held high forever sometimes so that the program stucks?

    It's a pity because I dont have a scope nor a logic analyzer so I cant go deeper on that.

    Kind Regards,
    Lukas

  • Hi Lukas,

    Depending on how your code operates, your controller might not respond to the DRDY pulse if it is performing other operations during this time.

    I assume your conversion process looks like Figure 19 in the ADS1255 datasheet. Note that the time that DRDY is low is quite small (difference between T18 and T19 in tables 13 and 14), so if your controller "misses" this change DRDY will always look high. At a lower data rate, the controller has more time to complete other tasks during the conversion time, so it doesn't "miss" the DRDY pulse. This is something you could identify on a scope or logic analyzer unfortunately.

    Also, as you noted, issuing a command such as the SELFCAL command restarts the conversion process, so you could issue such a command after your additional code completes. But this will change the effective data rate that you get out of the ADC, since there will be delays between samples.

    -Bryan

  • Hi Bryan,

    This is the code where it hang up: while (PIN_DRDY & (1 << PINDEX_DRDY)){ }

    So the DRDY pulses cant be missed because Im waiting for it and I dont do other things in between.

    Yes I noticed that the datarate is obviously lower, but this wouldnt be a problem because SELFCAL wouldnt be send all the time.

    Kind Regards,

    Lukas

  • Hi Lukas,

    It will be challenging to diagnose this further without being able to see what is happening on the SPI lines. The question really is, does the ADC not send DRDY pulses or is the MCU not detecting them? Since you say that without your extra code the ADC communicates properly, this suggests that the error is somewhere in that code and is causing the DRDY function to hang. Again, since the ADC communicates properly without that code, I would guess the DRDY pulses are being "missed" by the MCU. This would be easily detectable with a scope or logic analyzer.

    For now, the best recommendation I can make is to remove that code from the while() loop or, if that is not an option, reissue the SYNC+WAKEUP command (or SELFCAL) after that portion of the code completes.

    If you want to post that portion of your code, you may do so. Please make sure the part you added is clearly denoted.

    -Bryan

  • Hi Bryan,

    I will try to get a scope and run some more tests. Is it possible to reopen this post later when I made the testing?

    Sometimes it hang up only if I added this simple code.

     Serial.print("Weight:");
     Serial.print(actual_weight,2);  //Print float value
     Serial.println();
     
      delay(100);   //wait 100ms

    I noticed that when the 100ms delay was longer it hang up earlier.

    Bryan thanks for your support. I will do some more tests before I would return with questions, because at the moment I think you can't help anymore if I dont have made some new testing.

    Kind Regards,

    Lukas

  • Hi Lukas,

    Is this within the DRDY while loop? Can you post the surrounding code so I can see what is happening before and after?

    Yes, scope shots will help, and you may certainly continue this thread when you are able to get them. If this thread has been closed by that point, just start a new one and reference this thread, and we will go from there.

    -Bryan