Hi, im working on TCP-IP comunication with ADAU1401/1701.
First of all, i have not found any valid documentation about TCP-IP Protocol, i dont know if not exist or Analog Devices refuses to make it public.
So i spended many hours debuging and using Wireshark, trying to understanding Sigma TCP-IP Protocol, finally i got sucess, but i have found BUGs on Sigma Studio, that make Full Implementation Impossible! see bellow explanation and a temporary solution, when us still waiting for Analog Devices solves.
Hardware in use:
USBi ADAU1401 on custom board, self boot with 24lc64 ADAU1701 on custom board, self boot with 24lc64
ESP8266 with WiFi, connected to ADAU board I2C ESP32 with WiFi, connected to ADAU board I2C Software in use:
Windows 10 Pro ( 64bits ), running on I7-7700HQ with 16GB
Sigma Studio Version ( 4.2 Build 1. Rev 1764 ) 08/23/2018 ( with bug! ) Sigma Studio Version ( 4.3 Build 3. Rev 1777 ) 05/17/2019 ( with bug! ) Sigma Studio Version ( 4.4 Build 0. Rev 1786 ) 06/26/2019 ( with bug! )
1) Using Sigma Studio, i can write Program and Parameters to ADAU like expected, but i cant connect EEPOM to TCP-IP, so i cant read or write on 24lc64, i hope Analog Devices quickly solves that.
2) Using sigma Studio, when i try to read Program or Parameters from ADAU, problems starts...
a) Sigma Studio is doing (4) four requests, each request expect 256 registrers/1024 Bytes "Requesting Parameters" using TCP-IP at same time, sequential, expect response only after that.
b) The four (4) resquest sequencial start to be a problem, because TCP-Server over Ethernet or WiFi is slow, because it needs to read data from ADAU registers, build a packet and send, then repeat a process for next requests, a possible solution is Sigma Studio do a request, wait TCP-IP Server process this request and response data, so repeat this process until read all.
c) Ween TCP-IP Server reply first request, Sigma Studio receives and read only (1020 Bytes ), missing last four ( 4 bytes ), then raises an exception and stops! also shows "Compiled, Comms Failed!" this left me crazy, because first i think have error on TCP-Server, but after analize TCP with Wireshark, all 1024 bytes are in packet like must be.
d) After certify my TCP-Server is working correctly, i start to undertand what are wrong with Sigma Studio, i have disassembled tcp.dll and found that Analog Devices Team Programers, have coded that dll and never do a single test, because Sigma Studio requests 1024 bytes, response has to be 4 Bytes ( Packet Header ) followed by 1024 bytes, its 1028 bytes to read from TCP, but tcp.dll has hardcoded to read only 1024 bytes, so it will never read all bytes!
e) After i found the problem, i have discovery that this problem is not only for ADAU1401/1701 DSPs, it affects all ADAUDCP Family, i have contacted Analog Devices, but they send me a e-mail, ask for post on this site.
f) Because i need it finished quickly, I start to try solve this myself, so i do a pacthe on dll changing 1024 to 1028 ( Found it on many places ), and after that patch, Sigma Studio receives all bytes correctly, the patch address changes from one dll version to another, if u want to solve this yourself, open tcp.dll with an hex editor search for "14 2A 20 00 04 00" and replace with "14 2A 20 00 04 04" ( you have to replace many times to cover every ADAU Model )
3) Sigma Studio do multiple sequencial requests, it still a problem ( Some times TCP-Server cant quickly read data from ADAU over I2C and do a response ), on this case Sigma Studio stil ignoring some bytes at end o packet wenn receives, Analog devices must consider the folowing:
Current Sigma Studio Request
Send Read Request from 0x0000 to 0x00FF Send Read Request from 0x0100 to 0x01FF Send Read Request from 0x0200 to 0x02FF Send Read Request from 0x0300 to 0x0400 Wait TCP-Server response from all packets "some times TCP-Server receive a re-send packet from Sigma Studio, i think becase TCP timeout"
Sugested Sigma Studio Request
Send Read Request from 0x0000 to 0x00FF, wait TCP-Server response for that packet Send Read Request from 0x0100 to 0x01FF, wait TCP-Server response for that packet Send Read Request from 0x0200 to 0x02FF, wait TCP-Server response for that packet Send Read Request from 0x0300 to 0x0400, wait TCP-Server response for that packet
I hope Analog Devices solves this problems, also make an usefull TCP-IP Documentation
Rocha, could you share the esp32/8266 source code?
Thanks for doing a great job detailing this. I had reported the problem to our programming team back in August. It is still on the task list. I added this post to the bug report. The programming…
Hi mk_sounds, i have dicided to share code with this comunity, i think will help a lot of people, i will remove some personal code first, that way i will rebuild a library only for share, this can take…
Can you provide your sorcecode for the TcpIp server for the Esp32?I am working as a user with the board freedsp aurora. This Project is Open Source.
Thanks a lot Rocha
Could someone from AD step up and tell us if this bug is going to be fixed in a next release or not ? This bug is hanging there with no one reacting...
Hi, due to the bad drivers for the USBi (e.g. USB 3.0 support etc.) I'd like to use the TCP/IP option too. At Analog Devices it already seems to fail at offering some usefull documentation. 3 months and no reply? Seems that AD is trying hard to get rid of it's customers.Has this issue been fixed in the current Sigma Studio releases?
Rocha I'm also interested in the code for the esp32. I haven't worked with that hardware base yet, but it seems to be a good platform for some dsp projects.
Kind regards, Markus
Hi Markus, this issue persists in current Sigma Studio version, they not solved, like you say, ESP8266 and ESP32 fit all needs for USBi replacement, also do more, allow comunication over wifi network and you can have both functions "USBi and User Interface( display, http and api )" at same time, eeprom read/write is possible with http interface, on same solution. im thinking about share code with comunity, i will decide soom about that, best regards.
Thanks for doing a great job detailing this. I had reported the problem to our programming team back in August. It is still on the task list. I added this post to the bug report. The programming team has been super busy. I would think they should get to this soon. It is an easy job since you have seemed to find the root cause and detailed it here.