SPI for AD1938 odd functionality

Hello thaines3,

wish I was in a classroom with you and a white board. These are good questions and bring up interesting concepts. I should ask you what school do you attend but that is too personal so you do not have to answer that.

SPI electrical connections do not support multi-master modes of operation unless you can tri-state one of the masters when the other wants to communicate. The issue is that the MOSI line and the SPI Clock lines is actively driven by the master SPI device. This means that if you connect another master you have two parts driving to drive the MOSI and SCK at the same time so they are fighting each other. We put in some large resistors in series on the USBi to prevent the chip from being damaged but it will have issues driving a line high when something else is trying to drive it low. 

You may be able to tri-state the microcontroller SPI port via software. If you can then you could setup some way to tell it to tri-state and get out of the way. I have seen people use the 5V output that is on the USBi ribbon to drive a couple of transistors to signal a controller via a GPIO pin that the USBi has been connected. Just be careful to translate the 5V level to 3.3v. This is why I said a couple of transistors. 

Your question about what the microcontroller is sending. Yes, you can send exactly what the USBi is sending and it will work. There is nothing special that the USBi is doing. 

Use the Capture window to capture what it is sending. You can save that as a text file and then compare it with what you are programming in the controller. There will be some wait periods to wait for things like the PLL to lock. 

This is detailed in the datasheet but just grabbing the process in the Capture window and copying that is probably faster. 

Dave T

Okay, that point about the multiple master SPI devices makes sense, but we actually tried disconnecting the USBi completely and connecting wires to the SPI pins that we need in the USBi interface (J1 on the EVAL board). This setup still did not work.

In order to test whether we were actually writing the correct values to the registers we did a reset of the chip by pressing the reset button on the EVAL board and then we send the SPI commands from the microcontroller. At this point the chip is somehow not correctly setup. It isn't until we disconnect the wires from the interface on the EVAL board that the chip works correctly.

Do you know why that might be the case?

thaines3 said:

It isn't until we disconnect the wires from the interface on the EVAL board that the chip works correctly.

This means that you have both connected and you cannot do that. 

Dave T

What do you mean by "both"?

We actually have the USBi disconected the whole time.

You said you disconnected wires. So I assume you were disconnecting wires from the USBi or from your controller board? 

Can you send pictures and explain more? We are clearly not communicating and understanding each other. 

Maybe even a short video?

Dave T

My apologies for the late reply.

My team and I were actually able to figure out what we needed to do.

The scenario we were dealing with was the following:

1. Connect microcontroller's (Teensy4.1) SPI lines to AD1938 SPI lines on EVAL-AD1938AZ.

(Note: only 1 microcontroller (Teensy4.1) is connected to the AD1938 as an SPI master. The Analog Devices USBi is not connected at all.)

2. Connect relevant wires for I2S audio transmission to DSP (MCHStreamer) and audio input device

(We are converting an analog signal from an MP3 Player to a digital signal (I2S) using the AD1938's ADC. At this point when the correct SPI commands are sent, the audio should start playing on our playback device (software on PC).

3. Send the SPI commands to configure AD1938's registers.

(At this point nothing would happen)

4. Disconnect all SPI lines from microcontroller and AD1938.

(At this point the audio would start playing on our playback software.)

What we ultimately found was that for each SPI communication "session" that our microcontroller had with the AD1938, we needed to call the SPI.begin() function before we sent the SPI commands and then call the SPI.end() function after sending all the commands.

Previously we were calling SPI.begin() at the beginning of our code for setting up the various pins on our microcontroller and then never calling SPI.end(). But since audio started to play once we disconnected the SPI lines from the AD1938, we were able to determine that calling SPI.end() would solve our problem.

Our thinking was that this causes the microcontroller to "let go" of the SPI lines.