Reading parameter data on ADAU1701 via microcontroller

Hello joe42,

Read this post and the post it links to:

ADAU1401 register readback - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (analog.com)

Here is another link to the same post I mentions above.

This post talks about the Capture registers and how to read. This is a good post.

Using hardware data capture (trap) registers with the DSP Readback cell (AD1940, ADAU1701) - Documents - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (analog.com)

There is a little information on timing on this one.

Readback timing for ADAU1701 - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (analog.com)

A little more info...

Help with safeload of ADAU1701 - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (analog.com)

Let me know if there are still issues.

Dave T

Thank you! I may be missing something but in these links you provided they all seem to involve reading data from a readback cell, not reading parameter data that was written to, say, a gain cell.

For example, if I have a DC cell or gain cell, and write a value to it, shouldn't I be able to read that same memory location to retrieve the value? That doesn't seem to work, though the readback cells do work. Maybe there's a subtlety for doing this, or are parameters write-only, and only readback cells can be used for readback?

Hello joe42,

You can read parameter data directly and write to it as well. When writing you need to use the Safeload feature. This is because in this core when you access parameter RAM it stalls the core which can cause audio glitches. So you have to use the safeload feature for writing. (+) Implementing Safeload Writes on the ADAU1701 - Documents - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (analog.com)

Your question is about reading. I reread your question and there may be something simple I am missing here to see what is wrong?

You can read the parameter RAM directly. I can do it with the sequencer in SigmaStudio just like you would with your uC. Perhaps this is a slight I2C command formatting issue? Let me assume this might be the issue and walk through this procedure.

I will assume you are using I2C.

Are you first issuing a WRITE command to write the address of the data into the comms port so it knows where to get the data. Then issue a repeated start with the Read/Write bit set to Read without issuing a stop command and then clocking in the data. Are you doing this procedure?

Here is the detail in the datasheet:

It is a bit of a strange thing at first that you have to issue a write command first if you are trying to read. What is happening is you are writing the address into the pointers in the I2C hardware. If you then continue to clock and send out data it will write to the address in the pointer. If you issue the repeated start it will not clear out the pointer but instead will change the mode to read and it will read from that address stored in the pointer. So first write in the pointer to the data then change the mode to read and read from that location.

In SigmaStudio you see it reported as a "read request" Then a read. Like this:

Dave T

Thank you! I am reading the memory in exactly the same way as I would read from a readback cell; just changing the memory address to whatever the address was that I wrote the parameter value to. So I think I'm doing it correctly. But now that I know it's possible, I can look for the subtle error I undoubtedly have.

Current routine, written long ago, which works fine for readback cells:

i2c_start_wait(0x68);
i2c_write(0x08);
i2c_write(0x1A);
i2c_write( (address>>8) & 0xff );
i2c_write( address & 0xff);
i2c_stop();

i2c_start_wait(0x68);
i2c_write(0x08);
i2c_write(0x1A);

i2c_rep_start(0x69);
data1=i2c_readAck();
data2=i2c_readAck();
data3=i2c_readNak();
data=(uint32_t) data1<<16 | (uint32_t) data2<<8 | (uint32_t) data3;

Looks like I am not doing the proper procedure for general reading. I'm not writing the address information to the safeload locations, I'm writing it to data capture locations.

Hello joe42,

The data capture registers are only for reading information going on in the core not in memory. If you were trying to read the core exactly at the time where it picks up the data for something like the gain of a volume control, you would have to know where/when exactly in the program instruction counter to capture the value. Then you would also have to know what to pick up? In this case the accumulator might not be the right place? It would be the X or Y register because the program would pick up the gain and multiply it by the audio to get the output. This is possible but the Trap.txt file does not have that much information. It only tells you the instructions number for things like meters and readbacks. So the best way is to directly read the parameter.

Look at my post with the screenshot of figure 24. That is how you have to format the message.

It looks like from line 8 on you have it setup? But the address will not be the correct address but the formatting of the message looks good. So change line 9 & 10 to have the address of the parameter you need to read. You can find that using the Params tab of the capture window.

I would not read this too often because it might cause some clicks or pops if it is often.

Dave T