ADAU1701 and SigmaTcp - Header mismatch

Hi,

I am facing the same problem. Can you share what you changed?

Best regards

Axel

You have to adequate the size of the header and the position of the information in the right places. SigmaStudio works with a 10 bytes header, instead of 8. You will have to place a few changes in the function handle_connection in sigma_tcp.c 

lines 163, 166 and 167:

while (count >= 9)

len = (p[6] << 8) | p[7];

addr = (p[8] << 8) | p[9];

lines 184 and 185:

p += 10

count -= 10

lines between 180 and 192: replace all "8" with "10".

Hi,

thank you, this works for me. Did you also try to read registers from the DSP using sigma-tcp? Currently, we are able to write using your modifications but are unable to read.

Edit: My student postet a seperate thread for the problem here: TCP/IP ADAU1701 - Read not possible 

Best regards

Axel

I believe that your problem is in the i2c interface. I faced the same problem when trying to interface the ADAU1701 with raspberryPi (I saw in the other thread that it is the hardware that you are using). Are you able to read the DSP in another way? Try to "i2cdetect -y" your i2c bus and verify if you are able to detect the codec in the right address. 

The ADAU  i2c bus requires two start conditions in a row, and it seems that the i2c hardware of the broadcom chip in RPI doesn't do that (and I couldn't find a way to change it). 

you can read more about this problem here:

ADAU1701 I2C read 

Lucas

Hello Lucas,

yes we already figured out how to read. Our own application running on the pi works for both reading and writing. Only SigmaTCP using the provided patches is only able to write to the DSP but is unable to read. Unfortunately, we cannot patch SigmaTCP the same way for reading as we did for writing because SigmaStudio is the black box and we can only guess how the packets need to be modified for SigmaStudio to accept them.

Best regards

Axel

why doesn't analog devices help with this and describe the tcp protocol ?

is it different from this ?

TCP/IP Channels (ADAU144x / ADAU145x) [Analog Devices Wiki] 

raspberry pi has no problem making repeated starts.

uint8_t addr_buf[2];
struct i2c_msg msg[2] = {0};

struct i2c_rdwr_ioctl_data msgset;

// 16 bit address
addr_buf[0] = (addr >> 8) & 0xff;
addr_buf[1] = addr & 0xff;

msg[0].addr = i2c_dev_addr;
msg[0].flags = 0;
msg[0].buf = addr_buf;
msg[0].len = 2;
msg[1].addr = i2c_dev_addr;
msg[1].flags = I2C_M_RD;
msg[1].buf = data;
msg[1].len = r_len;

msgset.msgs = msg;
msgset.nmsgs = 2;

if(ioctl(i2c_fd, I2C_RDWR, &msgset ) < 0) {

I don't understand why Analog doesn't respond to that either.

I already know the link you mentioned, but this package order only applies to the ADAU 144x and 145x - not to the ADAU1701.
I already tested it, but it didn't work out.

I did study the C code for the 145x/146x family as i will use it for raspberry PI

many bugs and overly complicated/obfuscated, must be very unstable. (IMHO)

the oposite of KISS

I will rewrite it , and add  SPI support,

anyway,  to return to the original topic.

it cannot be very hard to reverse engineer the 1701 format, can it ?

i assume it will resemble at least the 145x format

if you just run the code you can see the incoming packet and analyse it, or run wire-shark on it.

The software itself is even relatively stable.

Because some answers in the thread suggest that we did not precisely nail down the problem, here is a step by step what we did and try so far. 

1.Sigma Studio sends a read request to the Raspberry PI via the LAN interface - This step works.
2. the Raspberry PI receives the request via the LAN interface and analyzes the packet for what it should do. For   example, the first byte contains the prompt what to do. 0x0A stands for read and 0x0B for write - this step also works.   Even if Sigma TCP only checks if the first byte is not 0x0A.
3. The Raspberry PI sends a request to the ADAU that it would like to read - This step works.
4. the ADAU responds to the Raspberry PI - that works too.
5. The PI receives the response of the ADAU, this can be an analog value, for example. - It works the same way.
6. The PI packs the answer into a new package and sends it to Sigma Studio - Here's the problem!
 The problem is that Sigma Studio expects a specific package, as described here: https://wiki.analog.com/resources/tools-software/sigmastudio/usingsigmastudio/tcpipchannels. The problem is that this package seems to be different for   the ADAU1701 - it doesn't work in this package order.

Wireshark doesnt help here because SigmaStudio is the black box. SigmaStudio receives a package from us and doesnt accept it. We need to know the package format for packages from SigmaTCP to SigmaStudio. We can look into the package we sent using wireshark but we cannot the extract the information we need: Will SigmaStudio accept the package?

And if not, why not?