Post Go back to editing

Ad7705 data register not responding

Category: Hardware
Product Number: AD7705

Hi All,

I am trying to use an AD7705 with an raspberry pi pico w. Setting the initial registers (clock, setup, calibration) works as expected. After reasing the dataregister a view times (not always the same) the register returns 8192 (using a gain of 4) and nothing else. This seems to have happened to a view people before but no solutions are published. Is this a common problem? I am using a standaed ad7705 breakout board and have tried serval to rule out a faulty unit.

i'm not sure

what aditional info i can give. I can post (badly writte) prototyping code, logic analyser (dsview) captures or screenshots from my oscilloscope if needed.

edit:

As requested i added some additional info.Since i can only add pictures here i created a shared folder on my google drive with the original capture files.

The link to this folder is: https://drive.google.com/drive/folders/1jaEWu0dabaq3lW5rF8DuDZUr_ZPMs_0I?usp=share_link Please note that in the logic analyser files channel 4 is the status of the DRDY pin.

Below is a screenshot from my osciloscope, it was hard to capture so i hope it is helpful. If other measurements are needed feel free to educate me :-)

Below are two screenshots from my logic analyser when sending a command 0x38 to receive the data register and the result from the ADC. Notice that in the first screenshot that a valid value is sent by the ADC followed by the rising of the DRDY pin. In the second screenshot the ¨frozen"value is returned and the DRDYpin does not go high.

channel 0 is CS
channel 1 is MOSI
channel 2 is SCLK
channel 3 is MISO
channel 4 is DRDY

Many thanks for helping me with this, i hope i just overlook something simple.

edit 2:

I managed to capture my clock, and i think this might be considdered bad ringing although there is a distinct signal there.

Edit 3: as promisses a photo of my project. The red area outlines the mcu, the area outlined in blue is the adc used in above testing. The device in purple was added tonight, it is a logic level switcher which did most definitly not help my signal. But since it is not part of the original setup it can be considdered to be not there.

The white wires are the spi lines to the adc.

edit 3:

So i changed the code to readback the clock and setup register every time i try to read the data register. Something funny is happening.

Below you´ĺl find the output. the red lines show the last time everythoing reads correct. The blue lines show that also reading the clock and setup register is failing when the data register returns the frozen values. I will also capture this with my oscilloscope and post some pictures later.
Also, something strange started to happen, when i had an oscilloscope probe attached to the CS-pin the freezing would occur less...
starting...
ADC succesfully reset
ADC interface succesfully reset
{'result': 0, 'error': '', 'command': '00100000', 'function': 'ADCnextop'}
{'result': 0, 'error': '', 'command': '00001110', 'function': 'ADCclock'}
{'result': 0, 'error': '', 'command': '00010000', 'function': 'ADCnextop'}
ADC setup
{'result': 0, 'error': '', 'command': '01010000', 'function': 'ADCsetup'}
00010000
{'result': 0, 'error': '', 'command': '00011000', 'function': 'ADCnextop'}
{'result': '01010000', 'error': '', 'command': 'read', 'function': 'ADCsetup'}
00010000
{'result': 0, 'error': '', 'command': '00011000', 'function': 'ADCnextop'}
{'result': '00010000', 'error': '', 'command': 'read', 'function': 'ADCsetup'}
Calibration completed.
{'result': '00010000', 'error': '', 'command': 'read', 'function': 'ADCsetup'}
ADC interface succesfully reset
press single
{'result': 0, 'error': '', 'command': '00101000', 'function': 'ADCnextop'}
CLOCK REGISTER : 00001110
{'result': 0, 'error': '', 'command': '00011000', 'function': 'ADCnextop'}
SETUP REGISTER : 00010000
DATA REGISTER  : 01111111 11110011
{'result': 0, 'error': '', 'command': '00101000', 'function': 'ADCnextop'}
CLOCK REGISTER : 00001110
{'result': 0, 'error': '', 'command': '00011000', 'function': 'ADCnextop'}
SETUP REGISTER : 00010000
DATA REGISTER  : 01111111 11110101
{'result': 0, 'error': '', 'command': '00101000', 'function': 'ADCnextop'}
CLOCK REGISTER : 00000000
{'result': 0, 'error': '', 'command': '00011000', 'function': 'ADCnextop'}
SETUP REGISTER : 00011000
DATA REGISTER  : 00000000 00000000
{'result': 0, 'error': '', 'command': '00101000', 'function': 'ADCnextop'}
CLOCK REGISTER : 00000000



added code output including readback of registers
[edited by: h3ndr1k at 1:19 PM (GMT -5) on 20 Jan 2023]
Parents
  • Hi  ,

    Yes, can you provide your prototyping code, logic analyzer captures, and scope shots of your outputs to help us better understand the issue/problem. Thank you.

    Best Regards,

    Rod

  • Hi! thank you for replying. I edited my post. If you need additional measurements feel free to ask, iḿ happy to help you help me :-)

  • Hi  

    Apologies for the delay. But can you label the attached analyzer? Can you also check your SCLK? it seems to have different pulse width?
    With regards to your register settings, can you also share your full register map settings readback from the ADC? Can you successfully readback the correct register settings?

    Thanks,

    Jellenie

  • Hi , No woorries i am SO glad someone is helping me at all. So yesterday i found that the signal is degraded significantly (although it's not great at the micro side either) because there is a 10 cm wire to the ADC. This might has something to do with the logic analyser detecting a different clock pulse width. As you can see on the SCLK screenshot the pulsewidth seems okay when captured with a oscilloscope.
    My prototyping code is checking the setup register (readback the register) to ensure that calibration is completed. I will implement checks for the other clock register to as soon as i get the time.

    the settings i am using for the current test are:
    CLOCK register: 00001110 (CLKDIS 0, CLKDIV 1, CLK 1 and 250hz)
    SETUP register: 01010000 (SELF-CAL, Gain of 4, bipolar, buf shorted, FSYNC input)
    Then i wait untill the setup register first bytes are returning to normal mode (00)
    only after the return to normal mode i will attempt to read the data register.

    Since i can succesfully readback the setup register i assume all communications are going as planned upto that point. Most of the time i do get a couple of correct readings after the calibration supporting this assumption.

    Upto this point my assumption is that the ADC is getting out of sync with the clock and "crashes" because it detect different clock pulse width (like the logic analyser does) but i am not sure how i can resolve that or even confirm that theory.

    p.s. my design is going to use multiple ADC's on one SPI bus. this enables me to test the the ADC closer to the micro (only one ADC was connected during testing) but it resulted in the same behaviour.

    I will make a picture of my actual setup tonight and add it here.




  • Hi ,

    So i changed the code to readback the clock and setup register every time i try to read the data register. Something funny is happening.

    in the original post you´ĺl find the output. the red lines show the last time everything reads correct. The blue lines show that reading the clock and setup register is failing when the data register returns the frozen values. I will also capture this with my oscilloscope and post some pictures later.
    Also, something strange started to happen, when i had an oscilloscope probe attached to the CS-pin the freezing would occur less...

  • Hi   and ,

    So i might have found the solution. I wen´t into the rabbithole of the mysterious "add probe and it works". I kept getting good results when probing the CS pin and getting bad results when i removed it. It was so consistent that it could be a coincidence.

    Even when i attached just a wire going nowhere it still gave the same results. Eventually i added a 100 ohm resistor between the CSpin and GND and it seems pretty stable now. I activated a pull-down resistor in the code but that was not enough or does not work on the pico.

    The problem is that this is a fix that i do not understand. Do any of you maybe know why this was causing problems? MAny thanks in advance! If this fix is holding i will ensure to put it on top of the post for future reference :-)

  • Hi  

    Thanks for sharing these details. So, it appears to be an SPI communication issue rather than a data conversion issue. It is interesting that adding a series resistor will fix the issue. Before adding the resistor, what is the connection of your /CS is it just directly connected to MCU/DSP? Can you share the specifications of your MCU/DSP digital lines? 

    For example if you put a pull up resistor to /CS line will it also resolve the issue? 

    It is also interesting that you are connecting multiple boards, does all boards have all of their GNDs connected at one point? 

    Thanks,

    Jellenie

Reply
  • Hi  

    Thanks for sharing these details. So, it appears to be an SPI communication issue rather than a data conversion issue. It is interesting that adding a series resistor will fix the issue. Before adding the resistor, what is the connection of your /CS is it just directly connected to MCU/DSP? Can you share the specifications of your MCU/DSP digital lines? 

    For example if you put a pull up resistor to /CS line will it also resolve the issue? 

    It is also interesting that you are connecting multiple boards, does all boards have all of their GNDs connected at one point? 

    Thanks,

    Jellenie

Children
  • I'm so sorry, i did not get a notification of your reply.

    Before the resistor i indeed made a direct connection from the MCU (Raspberry pi pico w) to the CS-pin. I do not know the specs of the pico in regards to the digital lines but my best guess is that the digital pins on the pico do not go all the way to GND or that the micropython layer is not fully implemented and does not activate the pull-down resister that i configured.


    Adding a pull-up disables all communication.

    All the grounds are connected within the project.

    I can confirm that the pull-down resistors are a valid and consistent solution.

  • Hi, 

    Thanks for confirming that it appears to be a microcontroller interface issue.

    Regards,
    Jellenie