Post Go back to editing

[BUG REPORT] Sigma Studio TCP-IP read from DSP ( With Temporary Solution )

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



Removed proprietary code, due to Analog Devices request.
[edited by: Rocha at 9:15 PM (GMT -4) on 3 Sep 2020]
  • 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?

     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.

  • Hello Rocha,

    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. 

    Thanks,

    Dave T

  • Hi ,

    meanwhile I implemented the programming process with generated sigma studio files on an esp32. But this is for hartcoded configurations (with export system files function).

    To use the TCP/IP stack on the esp32 would be a perfect solution for the issues with the USBi programming.

    Would be great if you could give me an insight how you implemented the functions on the esp32.

    Kind regards, Markus.

  • Rocha, could you share the esp32/8266 source code?

  • Dave,

    we are developing a project including ADAU1466 controlled by network connected host processor by means of SPI.
    We have written a TCPIP Bridge in out host to remotely tune systems at low level, leveraging on the great piece of software SigmaStudio is but....we can't readback any parameter from DSP...

    After days of struggling I finally land on this post and understood the issue:
    we are using SigmaStudio 4.5 released in Nov 2019 but still TCPIP readback is not working.
    If possible now seems worst than descriprion from Rocha: even short readback (3/4 byte) fails and we never get back any byte from DSP.

    Could you give us and the community some hope about solution of this bug....will be great to know if the software is under developement and there is a planned revision fixing it.

    KR,

    Lorenzo

    @Rocha: your fix was referring to SigmaStudio 4.4? HAve you managed to upgrade to 4.5? I see that DLL changed to TCPIP.dll and despite I can still find string you suggested to update will not fix my issue that is related to short readback. Did you experimented the same?

  • Hi Lorenzo, at this time, there is no Sigma Studio correction for this BUG, so you must patch dll yourself, you need find HEX values, NOT STRING ones, on Sigma Studio 4.5 TCPIP.dll it occurs 3 times!

    First      at: 0x33ed -> 14 2A 20 00 04 00 Replace at adress 0x33f2
    Second at: 0x55ad -> 14 2A 20 00 04 00 Replace at adress 0x55b2
    Third     at: 0x8625 -> 14 2A 20 00 04 00 Replace at adress 0x862a

    I have used versions from 4.2 to 4.5 ( im very new, with DSPs ), im using version 4.5 right now.

    PS. Without dll patch, you can do a little things with TCP/IP, ( Write, Read and Readback fail only in some conditions, not all ), on this case, i recommend you double check your source code, there is something wrong.

    Also full read wont works with patched dll for all packets, because Sigma Studio TCP/IP is Asynchronous, and requests receives timeout before you can read 1024 bytes from DSP, build packet and finally send it, most of times Sigma reads 1015 bytes on requests (1 and 2), but sniffed packet with wireshark shows exactly 1024 data bytes ), requests (3 and 4) sigma reads correct 1024 bytes ( Im Talking albout ADAU1401 and 1701 ones, i do not have another DSP boards, so i developped only to this ), if you write packets with all (1024) zeros without read it from DSP or EEPROM, Sigma receives it correcty, because without read takes less time, packets with real data, is received by Sigma Studio, from 350ms to 700ms (miliseconds) after requested, so i think ESP8266 is realy fast, but not enough for Sigma Studio. 

    I Have related this before, Sigma Studio programers must change to Synchronous communication

    Realtime project tunning with TCP is very good and works great, writting and reading back, like VUs, filters adjusts and more, works just like USB...

    Analog Devices must consider change TCP/IP packets too, i think they develop it for "Personal Computers", not for micro-processors and hardwares that haves speed limitations, packets must be optimized and have same readers size

    Best regards

    Rocha

  • Hi

    because it is not really clear, could you give a short info about:

    What is working without changing anything, what is possible with changing the dll as you described and what is not possible right now with the tcp/ip block of sigma studio?

    Kind regards, Markus