Unable to write/read from  ADAU1450 DSP

Hello Binu,

There may be many ways where the DSP is not responding. So you have MCLK, is all the power correct? Are all the ground pins grounded? Is it in Selfboot mode?

Which port are you trying to talk to? There are two SPI ports on this device.

You need to keep the SPI speed down below 3.072MHz until the PLL has locked. It may be a bit lower if you are using exactly 12MHz. The normal frequency to use is 12.288MHz.

So I would run a bit slower, like 2MHz until you have checked that the PLL has locked.

You may have to capture your SPI transaction on a scope to see if it is in the proper format and is sending the required bytes in the correct order. Please post them here if you can.

One simple thing you can do to see if it is receiving data is to monitor the CLKOUT pin. Then write an 0x0001 to register address 0xF005. This will turn on the divided MCLK output onto the CLKOUT pin. It should be 3.072MHz for a 12.288MHz MCLK input.

So if none of this helps then send a schematic and take a screen capture of the SPI signals and tell me exactly what you are sending after the three dummy writes. Now on the screen captures, you will need to make several at different horizontal resolutions so we can see some detail.

Thanks,

Dave T

Hello Binu,

One other thing. When you write to the soft reset register. What are you writing? You should write a zero then you should write a "1".

Thanks,

Dave T

Hello Dave,

Thanks for your response.

I checked the ground and vcc. All ground pins are grounded and VCC supply is 3V .

We are using SPI as Slave port and the program is loaded from an external controller. I reduced the Baud rate to 2Mhz.

I am sending the following data

Dummy writes

00 00 00 00 00

00 00 00 00 00

00 00 00 00 00

Soft reset

00 F8 90 00 00

00 F8 90 00 01

Clock

00 F0 00 00 60

00 F0 01 00 03

00 F0 02 00 01

00 F0 05 00 07

Pll Enable

00 F0 03 00 01

Order of data transfer : MSB First

I tried to read data from 0xF000 by sending

01 F0 00 00 00

But Still no data on MISO

Hello binu,

Send me your schematic.

Get some screenshots of the SPI waveform.

Thanks,

Dave T

Hello Dave,

Please check the schematic and Spi waveforms

Three dummy Writes :

Yellow channel - Chip Select

Blue Channel - Clock Signal

Followed by Soft reset and writing to clock register

Writing 0x0000 to 0xF890

Yellow channel - MOSI data

Blue Channel - Clock Signal

Writing 0x0001 to 0xF890

Writing value 0x0060 to 0xF000

Writing value 0x0003 to 0xF001

Writing value 0x0001 to 0xF002

Writing value 0x0007 to 0xF005

Hi,

Why is data on MOSI changing on the rising SCK edge? It should change on the falling edge!

SPI mode 0, CPOL=0, CPHA=0, MSB first

Btw, I hope you are using the export feature of sigmastudio to generate the "DSP configuration and program" that you SPI-load into the DSP with your MCU. Because there are SPI delays that you must respect (for example while setting the PLL), and a complete "DSP start sequence". I think that you have to do the start sequence before being able to read some DSP values.

The practical way to tell the MCU that the DSP is alive is to read a register, which must contain a value that you know beforehand (for example a PLL setting register).

The practical way to tell the user if the audio DSP is alive is to pass audio through

Simon

Hi Dave,

I scoped the USBi (while performing a sigmastudio load), and found that it was using SPI mode 0.

The datasheet says in SPI slave port that SPI mode 3 must be used.

But on the figure35, p38 of revC, the SPI mode 0 waveforms are highlighted

Best regards,

Simon

Hello binu,

Simon is correct in that it appears you are using the wrong SPI format. Look at figure 8 in the datasheet. Also on page 35 of the datasheet it says this:

The format for the SPI communications slave port is commonly known as SPI Mode 3, where clock polarity (CPOL) = 1 and clock phase (CPHA) = 1 (see Figure 34). The base value of the clock is 1. Data is captured on the rising edge of the clock, and data is propagated on the falling edge.

Figure 34 in the datasheet also shows the differences between the modes. So this can certainly be the issue here.

So Simon,

I agree that reading a register that has a known value can help see if you are talking to the part but in this case he is not seeing any data out from the DSP. So by his saying that I know he is not able to read from the part. My simple test to see if something is alive and the DSP is receiving data by looking at the CLKOUT pin is because to get to the practical simple test to see is audio is passing through the part requires a lot of steps where errors can occur. A valid program needs to be loaded and all the clocks and ports need to be setup properly. So this is why I ask about the CLKOUT because all it requires is valid MCLK and only a few register writes. Then if that is good then move on to other things it takes to load in a valid program. It seems like a trivial thing I asked but there is a method to my madness.

So binu,

On to the schematic.

The schematic clip you posted is a bit short on some details that are not shown. But it did yield some things I can comment on.

First, I do see you are using the SPI slave port. So that is good.

The PLL loop filter is all wrong. It must be the values listed in figure 16 in the datasheet. This can prevent the PLL from locking.

The PVDD pin has a 100nf cap but I do not see a 10uf cap we also recommend.

All the other bypass caps are not shown so I assume are there. How they are implemented on the PCB is also important but lets go there later.

I see you are pulling the selfboot pin low with a 10K. There is an internal pull-up on the SELFBOOT pin but I think it is around 100K so an external10K pull down should pull it down low enough but you might want to check to see what the voltage is on the pin. Normally we ground this pin directly.

I noticed you have some series resistors on the I2S lines. There is one I don't see but I recommend you place them on all the lines, SDATA,BCLK, LRCLK.

The same thing goes for the SPI lines. It is not a good idea to treat the SCK , MISO and MOSI lines differently. This can skew the timing between the data and clock lines. It is good to have them there to control the reflections just treat all the lines the same.

Enough for now.

Thanks,

Dave T

Hello Simon and Dave,

Now i am able to read the data on MISO. The problem was with the clock. I used Spi Mode 3 and its working.

Thanks,

Binraj

Hi,

It appears that the SPI slave port supports both SPI mode 3 and 0, like the SPI master ports do.

Binraj, I'm glad you can now communicate with your DSP

According to what Dave said, if you want to have proper sampling rates and clocks, you have to fix the PLL section.

Cheers,

Simon