Post Go back to editing

Problem reading registers from ADF4382A through SPI

Category: Hardware
Product Number: ADF4382A

Hi everyone,

Recently I have been trying to work with ADF4382A an its evaluation board (EVAL-ADF4382A, REV D) both with ACE software and my own C functions and I am having some problems.

At first I was only trying to write and read through the SPI with my own custom C functions and while the writing operations seemed to work pretty well, the reading ones failed as the values read didn't match with the expected ones. I am sure that the registers were written ok because with an oscilloscope I could see the SDIO line change its voltage depending on the configuration of the 0x3D register. I could even achieve the PLL lock at some frequency of my interest. But, unfortunately, when I tried to make a silly read operation following the datasheet instructions, I encountered that the values returned were wrong. I tried to read different registers like 0x0C or 0x0D but instead of returning the POR  values they returned 0x01 and 0x00.

 

I assumed that my code had some mistake coming from a missunderstanding so I decided to use ACE to make some reads and compare the oscilloscope readings with the previous ones. To my surprise, the readings returned the same (e.g. 0x01 from the 0x0C register). This happens in spite of the SPIO line configuration, whether I use 3 or 4 wires, 1.8 or 3.3 V. In the screenshot of the oscilloscope trace that is attached I was working with 4 wires and 1.8V using ACE software. (BLUE = CSB, RED = SCLK, GREEN = SDO, YELLOW = SDIO)

I have not much knowledge, but I can see some things that for me seem off:

1- If the PLL is working in 1.8V, why does the logich high of the SDIO line reach 2.65V?

2- Is it normal that the SDO line is stuck at 2.36V when writing the address? Because when performing the reading at logic high it only reaches 1.8V

I have read across EF that there used to be a problem with a SDO resistor with some revisions of the evaluation board, but the bad readings for me also happen in the 3 wire configuration, so it may not be just a SDO problem, right? (see 2nd screenshot, 3wire 3.3V)

For me this seems like some kind of electrical problem, but I don't know how could this be when I am working with the EVAL board and the SDP-S controller board. Does anyone have some ideas?

Thank you very much in advance,

Andres

  • Hi Andres,

    (This was meant to be sent out last week but there was some issues with the engineering zone reply for my post)

    Thank you for the detailed description and the oscilloscope captures. Based on your observations, it does appear that SPI writes are being accepted correctly, since the PLL can be configured and achieves lock as expected. The fact that both your custom software and ACE are returning the same unexpected readback values makes this a particularly interesting issue to investigate.

    To help narrow down the root cause, could you provide a few additional measurements and checks?

    1. Digital Logic Level Verification

      • Could you confirm the actual digital I/O voltage rail present on the evaluation board when configured for 1.8 V operation?

      • If possible, please verify that the CMOS logic level configuration has been successfully applied and is not remaining at a different voltage level than expected.

    2. Power Rail Measurements

      • Please measure the 6 V supply rail being provided to the evaluation board and confirm that it is stable and free of significant noise.

      • If accessible, please also provide measurements of the relevant onboard regulator outputs.

    3. Readback Testing

      • Do the incorrect readback values occur immediately after power-up, before any user configuration is applied?

      • Are the returned values always the same (for example, 0x01 from Register 0x0C), or do they vary under different operating conditions?

    4. Additional Oscilloscope Capture

      • If possible, could you provide a zoomed-in capture of a complete read transaction showing:

        • CSB

        • SCLK

        • SDIO

        • SDO

      • A capture centered around an attempted read of Register 0x0C or 0x0D would be particularly helpful.

    5. Hardware Information

      • Can you confirm the exact revision of the EVAL-ADF4382A board and SDP-S controller being used?

    I have already ordered an evaluation board on my side and expect to have it in hand tomorrow. Once it arrives, I will attempt to reproduce the behavior using ACE and perform some readback testing under the same conditions you described. This should help determine whether the issue is related to the evaluation hardware, configuration, or the device interface itself.

    I look forward to your feedback.

    Best regards,

    Douglas
    Associate Engineer, Central Applications
    Analog Devices, Inc.

  • Hi   first of all, thank you very much for your answer and your predisposition. I found your reply very complete and promising to start digging in the intricacies of the problem I was having. Also, my apologies for the late response, I was eager to start investigating but I had other work to do so I had to postpone this a little.

    I am writing this post not only to thank you, but also to leave for the record what was the problem I was having in case anyone is having it too. 

    As I said previously, I could not perform a single correct reading from the ADF4382A pll, neither with my own custom C functions nor with ACE software. My tries were returning the same values in both cases, but they were always wrong (and they were always the same values). That was very odd. 

    When I started to work to try to provide you with additional measurements, I realized something. As I was mounting the setup from scratch, I tried to perform a silly reading with ACE and, to my surprise, it was correct. The only difference in the testbench from a week ago was that the oscilloscope was not connected yet. So... yes, the problem was in the oscilloscope, not because it was broken but because I was connecting the probes to the yellow test points TP4, TP3, TP1 and TP2 (red). Specifically, the probes connected to the test points related to data lines (TP2 SDIO and TP1 SDO) were the ones causing trouble in my readings. With them disconnected, ACE via the SDP-S controller performed the readings just OK.

    I said in my first post that the problem seemed to be electrical. I guess that it is related to the input impedance of the probes or something like that. Maybe it was a silly problem from the start, but I didn't realize that this could happen. The solution for me was to directly connect the probes to the P2 connector (green). Doing so I could read properly the results from the reading operations, and I was finally able to debug my custom C functions which now work fine.

    Finally, I would like to add that I have the REV.D version of EVAL-ADF4382A and the problem with 3.3V and 4-wire mode persists. Or at least I could not perform readings that way while I had no problems in the other 3 possible configurations (1.8V in 3W and 4W modes, and 3.3V in 3W mode). It is not a big problem for me, I can work with the other configurations, but I just wanted to leave that written down just in case.

    Best regards, and thank you very much,

    Andrés

  • Hi Andrés,

    Thank you very much for the detailed follow-up, and no worries at all on the timing. I really appreciate you taking the time to document the root cause. These silly bench-level issues can cost a lot of debugging time, especially when the symptoms look like a firmware or device readback problem at first glance.

    For reference, my setup on my side is the following:


    My setup:

    ACE version: 1.30.351.7117 x64
    Board: EVAL-ADF4382A / ADF4382A Board
    Board revision: REV F

    Controller: SDP-S
    Power supply: 6 V
    Current state: Good

    On my bench, I saw somewhat similar behavior in the sense that hitting software defaults in ACE made the memory map match the datasheet/register map values, but actual hardware reads were returning 0xFF across the register map. I also checked both 3-wire and 4-wire SPI modes, and even after switching to 4-wire mode, SDO appeared to sit high during the read transaction. I confirmed that CSB, SCLK, and SDIO were showing activity when a read was initiated, but SDO did not appear to toggle during the readback window.

    Given your finding, I am going to revisit my own setup and independently confirm whether the 0xFF readback behavior I observed was also measurement-induced, probe-location-induced, or something else in my setup. In particular, I will avoid probing the TP1/TP2 data-line test points and will try probing from the P2 connector as you did. It would not surprise me if this turns out to be another silly scope-probe interaction with the SPI data lines.

    I am glad to hear that once the probes were removed from TP1/TP2, ACE was able to read the device correctly, and that you were able to debug your custom C functions successfully. That is a very useful finding, and I agree that it is worth leaving documented for anyone else who may run into the same behavior.

    Regarding your remaining note that 3.3 V logic with 4-wire mode still does not appear to behave correctly on the Rev D board, I will continue looking into that. Since 4-wire readback depends specifically on the SDO path, while 3-wire mode uses SDIO for readback, that remaining issue may still point to something specific about the Rev D SDO path, board population, or 3.3 V readback configuration. I will work on getting you a more concrete answer there.

    Thanks again for the excellent follow-up and for sharing the final root cause.

    Best regards,
    Douglas Plummer