ADC128S102: ADC128S102

Part Number: ADC128S102

Tool/software:

Hello,

I think I'm experiencing same issue to related question.

I think that everything is set correctly to retrive data in continuos mode. fSCLK set to 2 MHz, SPI mode 3.

But the data from channel 1 to 7 are never the same even if I put the some resistor (with different value) on input channels.

I'm using ADC128102EVM connected to Microchip SAMRH71 microcontroller.

Do you have any suggestion to understand if there is some SPI configuration error?

Thanks and regards,

Enrico

Yellow: MISO

Light Blue: MOSI

Purple: CLK

Blue: CS

  • Hi Enrico,

    Apologies for the delayed response, as I was out of office.

    To verify, are you seeing the expected results with the ADC128102EVM connected to the PHI controller included as part of the kit?

    https://www.ti.com/tool/ADC128S102EVM

    Can you explain the procedure below more in depth? The simplest way I can think is to connect a power supply to the input to verify the output code.

    But the data from channel 1 to 7 are never the same even if I put the some resistor (with different value) on input channels.

    Would you also be able to send the oscilloscope plots without the logic analyzer overlay? It's a bit hard to see the plots this way. DOUT should always start with 4 zeros, so the first digit on MISO should always be a zero. This is not always the case in your capture, so it is likely there is some misconfiguration. 

    Regards,
    Joel

  • Hi Joel,

    I try the TI GUI and I see that everything is working as expected. (See below the order of signal are MOSI, MISO, CLK, CS)

    Then I try my setup, see image below. 

    The procedure that I'd like to do is to acquire all channel with a single SPI communication (continuos mode).  The SPI output buffer is charged with channel1-channel7 address + channel 0 address to get channel 7 measure. The set up is providing 3,3V to the EVM.

    What I'm experiencing is that the channels never respond with same values and not in range. Also never see leading 0 in response.

    It seems also that the channel 0 respond different value respect the ones received with GUI. (0x170/0x180 VS 0x1D1/0x1C7)

    The main difference I can see is that the clock has a period of stuck, not sure why at this moment. I manage SPI comm with interrupt to update output buffer. Is this the issue in your opinion?

    I'm also going at lower frequency (2MHz)

    All channels:

    Channel 0 response

    Channel 1 response

    Thanks and regards

  • Small update from my side:

    I've removed the space between two transmission even if the frequency now is 1MHz.

    Same results Disappointed   

    I hope you can see a misconfiguration that I can't see.

    Thanks and regards

  • Hi Enrico,

    Thanks for sharing these captures. I went ahead and marked up the image showing the problem just to make it easier to see. Red lines demark the end of a SPI frame. It seems like data is coming one bit earlier than we would expect from the datasheet description,

    What is the data being sent on DIN? It doesn't seem to be aligned with where the ADD[2:0] bits should be issued on the 3rd, 4th, and 5th clock. 

    One thing you may be able to try is tying to input to AVDD, so as to make to output 0xFFF. Then, the four zeros might be more clearly seen.

    There is also interesting behavior on DIN, in a slight transition on the 14th falling edge. Any insight on what the controller might be trying to do at this point?

      

    Regards,
    Joel

  • Hi Joel,

    I think I've made confusion with signal description. Now I put the label according to ADC128S102 pinout.

    In my undestanding the address is aligned to he 3rd, 4th, and 5th clock rising front. Am I correct?

    The first image is the first address request for channel 1.

    The second image is reporting the sequence of address I'm currently sending with the conversion below.

    In the two image below I also put the input of channel 0 and channel 1 to AVDD but, as you can see, I'm not receiving 0xFFF...

    I'm not able to understand where is the wrong configuration... Disappointed

    I add another strange behaviour: if I connect channel0 and channel 1 to VDD also the other inputs change the response... Not sure if this can add information....

    Thanks for your time,

    Regards

  • Hi Enrico,

    I'm a little bit stumped here admittedly. Can you double check the supply voltages and the input connection to AVDD? Unless the device is damaged, it should be changing the output code, especially if you short it to AVDD. It does still work as expected when connected as part of the ADC128S102EVM?

    Can you try taking the conversions from channel 0 immediately after power-up? You can disconnect DIN in the meanwhile. 

    Regards,
    Joel

  • Hi Joel,

    I reply below to some of your question

    • I've tried the board part of Evaluation board and everything is working as expected. If I short Vin to AVDD I read 0xF9F (something like that)
    • When I connect the EVB to Microchip dev board I connect power supply directly to VA and I connect VA to VD. R42 is removed (even with the PHI motherboard connected indeed). The external power supply is set to 3.3V (1A limit). D4 led is on.
    Can you try taking the conversions from channel 0 immediately after power-up? You can disconnect DIN in the meanwhile. 

    Could you please describe it better?

    Thanks and regards

  • Hi Enrico,

    Is R39 disconnected as well? Is the PHI board still connected to the ADC128S102EVM when it is powered externally? Where on the EVM board is the power supply hooked up to, and how are AVDD and DVDD shorted?

    What I mean to say is that, since the ADC channel is selected through the DIN pin, if it is disconnected from the controller, it will read in all 0's and select channel 0 always. That way, it can be assured that the output on DOUT actually corresponds to channel 0. DIN could also be grounded to be safe.

    Still shorting AIN0 to If you only give the device ~CS and SCLK, do you get any high bits on DOUT? 

    I also have another suspicion. The inputs of the EVM board are driven by amplifiers. These amplifiers are supplied by a 5V3 rail, generated by an LDO. That LDO is powered directly from USB power via the PHI controller. Could it be that the input is connected to the amplifier input, and the amplifiers are not being powered, so the output is incorrect?

    Regards,
    Joel

  • Hello Joel,

    I'm sorry I didn't explain the setup well.

    1. Setup with PHI+EVB

    In this case I connect PHI to J25 connector and I power PHI with USB. In this setup the external power is disconnected but R42 is not present (R39 is present) and a short between VA and VD is present. [The short is with an external wired connection, lab crocodile clips]

    The connection for SPI (from Microchip board) on J26 is removed and I connect the pins to oscilloscope.

    2. Setup with Microchip Dev board

    In this case PHI is removed from J25 connector. R42 not present, R39 present. Same short on VA/VD. External power supply (3,3V9 connected directly to VA.

    SPI connection on J26 with Microchip Dev Board and oscilloscope connected on wires.

    The connection of inputs channel doesn't change between two configuration. The jumper J1,J7,J13...(an so on) are connected to Bypass OpAmp, or this is our intenction (jumper connected on the side of the writing "Bypass")

    What I mean to say is that, since the ADC channel is selected through the DIN pin, if it is disconnected from the controller, it will read in all 0's and select channel 0 always. That way, it can be assured that the output on DOUT actually corresponds to channel 0. DIN could also be grounded to be

    Undestand. Today I was not able to redo the test but I'm pretty sure that in previous test I tried to send channel 0 request for all 8 channels. I do it on software because it was easier and I check the output on oscilloscope. Same wrong result with not valid ADC conversion. Disappointed

    The setup 2 was done bacause the Microchip dev board is configured to manage 3.3V regulator (this will be the status in real project when our PCB will be ready). So we was scared about mixing different voltage reference.

    Could you please suggest the best way to connect the evaluation board?

    Regards,

  • Hi Enrico,

    Thanks for sharing the full setup. Everything definitely seems correct from the description. Maybe sharing a picture also could help spot if anything is off? Also probing the actual voltages at the pins to be sure.

    Otherwise, I would point to making sure that the timing characteristics are being observed, though I am having trouble finding anything that would be wrong currently.

    I would again check to see that the device isn't damaged by testing with the EVM, and swapping back and forth between the MCU and the PHI controller. 

    Other than that, I can't think of anything else that could be checked, given that this is a relatively simple device. I have checked the digital over and over again, the power from your description seems to be good, and the input seems to be good as well. I don't think we've discussed grounding, but presumably that is good as well. 

    I'll read the entirety of the thread over to check if I missed anything obvious, but if you are able to verify all of the above, it would be very helpful. 

    Regards,
    Joel

  • By the way, here is a capture where I am seeing correct operation. I have been cross-comparing against this. Let me know if you are able to see anything that might be different from your setup, because I have not up until now.

    Regards,
    Joel

  • Hello Joel,

    maybe I've some news even if the communication is still not OK. Maybe you can help me finding the root cause.

    So, I try the setup with PHI board (photo below, not clear setup I know...) and everything working correctly. But This setup trigger me! R42 is disconnected and VA is not shortned with VD as I previously mention. However the conversion with GUI are quite good (and also with oscilloscope; 0xFF9 0XFFA with Ain0 shortned to VD and 0x000 with short to GND) .

    What it made me suspicious is the voltage on VA that is not connected to VD,It was about 4V.

     

    I try to replicate the setup with our demoboard, quite same setup but VA shortned to VD and SPI communication connected to demoboard. 

    SPI communication didn't work as previously I see that the channel connected to GND  report 0x000. Slight smile

     

    Then I tried to remove VA and channels connected to GND still report 0x000 on SPI Slight smile

    So we try (I involved HW person in my company) to simplify the setup removing all connection for input channels and short all of them to GND and all channels reports 0x000 on SPI if request. 

    It seems a solution but it wasn't Disappointed

    I try to connect only 1 channel to VD and we receive spurious data. We also measure voltage on VA and was about 2,4V. 

    Make a short on VA/VD iseems to make things worse.

    So we do another test. We disconnect evrything from demoboad and we leave connection only to GND and VD, all jumper removed.

    Then we measure VA and we found 2.484V as reported in photo. Does it make sense to you?

    So I'm thinking that there is something wrong in setup and not in SPI comm itself....

    Could you please help me understanding which is a good configuration to power the demoboard without PHI board?

    Thanks and regards,

     

    Note: during first step with PHI board I try to connect VA to external reference because R42 is removed but the PHI board shut down and I need to reconnect USB to give power again...

  • I forgot to mention that we check ground connection between the two boards but we didn't found ground shift.

  • Hi Enrico,

    I am still looking into this. It might help to note that the ADC128S102 has a diode from VD to VA. If VD is powered while VA is not, VA might be back powered with a 0.7V drop relative to VD.

    This also applies to the digital and analog inputs. The device could be back-powered and function unexpectedly if voltage is present at the inputs before the device is powered on. VA being back-powered caused an issue in some testing I performed recently...

    I'll keep looking at this for more significant recommendations.

    Regards,
    Joel

  • HI Enrico,

    Any discoveries since this? The 2.4V measured is very telling to me, as it tells me 3.3V from another pin is forward biasing an internal diode, resulting in ~0.7V drop. Is there somewhere on the board that is reading 3.3V? 

    On the board, VD is clamped to 3.6V by the D1 Zener diode. Could that also explain why VA and VD being shorted causes an issue?

    I would also remove R33, the pull-up from DOUT to VD. It is not necessary, and could help in isolating the hardware issue.

    The RET_SCLK net is necessary for operating with the PHI, but R37 can be removed if used externally. 

    I would just focus on removing everything peripheral from the device that could be causing a stray leakage path.

    Regards,
    Joel