I am trying to use the AD9914 EVAL board controlled by a microcontroller instead of the USB. I see how to set the jumpers to set the connections to the USB chip to a high impedance state, but I am confused about the requirements for setting up the registers.
I want to do something fairly simple. I need a programmable output frequency, and programmable amplitudes for four profiles, which I propose to select by the inputs to PS0 and PS1.
I set the board up and got it working through the USB port. I then copied the data for the four control registers. With the microcontroller and can send SPI data and clock to set the input registers. I am using CSB to select the chip. Even though i have only one chip at moment. After setting the data in the serial input registers I issue an IO_UPDATE pulse to transfer the data. Right now I am putting a dc signal on the PS0 input in hopes of seeing a CW signal. So far nothing.
I have done this with the AD9959 successfully.
I am uncertain whether or not anything will work without synchronizing the IO_UPDATE with the SYNC_CLK. That does not appear to be necessary for the AD9959, for example. The timing of the update is not critical for my application.
Also, I have read the the PSx pulses have to be synchronized with the SYNC_CLK in order for the profile selection to occur. Right now that isn't an issue. I'd be happy to see an output of any kind.
I need a simple guide for using the EVAL board to get any output with my microcontroller.
First I need to tell you that it was only an hour and a half ago that I actually got it working. I've been beating my head into a wall trying to figuree out what I could be doing wrong.…
I am making some progress. When I run my program I send the initial data to the first 4 registers CFR1-4 and to the USR register.Before sending the data I reset the DDS and do a DAC CAL sequence. I am…
I think this thread might help you.
Perfect timing! Thanks for the link. I'm working on turning SYNC_CLK off and on with just the one buffer disabled. I'm guessing that the issue is when I disable all buffers some bits arer floating, but first I need to see if I'm communicating with SPI.
I am making some progress. When I run my program I send the initial data to the first 4 registers CFR1-4 and to the USR register.Before sending the data I reset the DDS and do a DAC CAL sequence. I am apparently communicating with the registers because I am able to turn on and off the SYNC_CLK and invert it or not.
As soon as the register sequence is complete the board puts out a signal at a random frequency, but it is always the same frequency. The amplitude control, frequency control, and Profile bits and external profile bits have no effect.
I am sending the chip the following:
CFR4 0x0000011C (This is what I see sent to this register when I set up the evaluation software for the operation I want. According to the datasheet I should be sending the default values 0x00000120)
USR 0xE2110000 (Again this is what I see sent to this register when I set up the evaluation software for the operation I want. According to the datasheet I should be sending the default values 0x00000800)
It doesn't make any difference whether I use the values copied form the evaluation software or the defaults that are listed in Table 14 of the datasheet.
It's encouraging that I can communicate with the chip. There were a lot of problems getting the initial setup right. I have also temporarily extended the IO_UPDATE pulse to about 400 usec.
According to the evaluation board registers I am sending the correct data for frequency, phase and amplitude.
I am unable to see what I am doing wrong.
What I am trying to do is fairly simple. I need a source at a frequency that that is the same for all profiles, but can be varied over a limited range. I want 4 profiles controlled by the PS0 and PS1 bits. PS0 PS1 = 00 I want amplitude 0. With the bets = 01 I want amplitude 1, 10 amplitude 2, 11 amplitude 3.
I control output on/off when the bits are pulsing by setting all amplitude to zero.
I have done something similar with the AD9959, and didn't have nearly as much trouble.
Good to hear that you are successful with controlling SYNC_CLK. If possible, can you share your whole program?
First I need to tell you that it was only an hour and a half ago that I actually got it working. I've been beating my head into a wall trying to figuree out what I could be doing wrong.
I thought I had set everything up right. I have a nice, fast mixed signal USB scope, a Link Instruments 9212, that I used to deduce the sequence from the USB controller. Before my breakthrough I had output on a random frequency that depended on which board I was testing. I have four boards.
I had problems with them because the tri-state buffer for the SPI signal would fail. I bought replacement chips, but they require some skill to replace. I thought I may have damaged the chips by accidentally connecting my external circuit while forgetting to disable the gates.
I became annoyed at having to remove the board from my system. I still had one board with a functioning USB controller. I decided to extend my control cables and use this board on my benchtop, and be very careful to make sure the gates were disabled before connecting my circuit.
In spite of that I finally had a hard failure. The chip U202 loaded the SDIO line. By this time I had fully reverse engineered what the USB chip was doing and implemented it in my control code. Rather than going to the hassle of replacing the chip I just removed it.
I then connected it back into my test setup. Amazingly, my controller now works.
I have a microcontroller chip that executes all of the control functions of the chip through a command structure via TCP/IP. In addition the microcontroller reads analog signals from the forward, reflected, and cavity amplitudes of my rf linrear accelerator rf power system. It then calculates the phase between the forward and cavity signals. It can be phase locked by comparing the phase to the reference phase so the rf tracks the accelerator frequency as it drifts due to ambient temperature and rf power level changes.
I am using the 9914 because I can generate the 3 GHz signal directly, greatly simplifying the rf circuitry required to generate it from an AD9959, which has a 500 MHz clock.
I need to go back and remove some of the desperate measures from my code that have no effect on the functionality.
I have mixed emotions about sharing what I learned after the effort I put into getting it working. I'm a little bit annoyed at Analog Devices for not providing better guidance. I am also annoyed that the final problem is a hardware problem that shouldn't happen. I have four boards with the same problem I took extreme care with the last board to make sure I didn't damage its gates by driving the SPI lines with the gates enabled.
It's also peculiar that in all cases it is the SDIO line. You might think that the SCLK line could have the same problem. The failure mechanism is a mystery. On the most recent failure it was spontaneous. It worked and suddenly quit working. However, even when it appeared to be working it must have been corrupting the data. I didn't see anything obvious. All through testing I was monitoring the clock and data lines. The scope has a built in SPI decoder function and the data always seemed to be correct.
That brings me tho another annoyance. The SPI signals are an odd SPI mode. The SDIO data is valid on the rising edge of the clock but the clock resting level is high. The data resting level is also always high. In other SPI implementations, including the one I have, the data line simply remains in its last state, high or low depending on the data.
At first I thought my problem was due to the SPI mode, although my scope interprets mode 0 and mode 3 the same - both have valid data on the rising edge of the clock. Now that I have it working I need to go back and see if mode 0 will also work on the DDS chip.
My searching of the Internet brought me a few clues that resulted in some progress but there is no Ap Note that lets it out clearly. It took sleuthing with my scope to discover what needed to be done, only to be frustrated by a hardware problem. I am curious to hear what the AD engineers have to say about the hardware issue.
I'm too old for secrets to be useful for very long, so I will probably write the missing Ap Note when I recover a bit from the long hours I've been putting in. Hopefully, I can save others some of the frustration I experienced.
I will describe exactly what is required to set the chip up for basic operation in profile mode, which is all I need to do. That will be at least a starting point for people who want to do fancy things like amplitude or frequency sweeps.