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]
Parents
  • After more than a year (1 year and 8 days), we can now celebrate this bug discovery anniversary, Analog Devices does not solve this problem, maybe AD is not interested in solving it, I will probably reverse all the DLL code and build a alternative version (without bugs), also share the source code with the community, in this way TCP.dll will be open source.

  • FormerMember
    0 FormerMember
on Aug 31, 2020 9:38 AM in reply to Rocha

Hi Rocha,

I am not able to duplicate your exact configuration here at home (working from home due to Covid, yes, it a pain) since I do not have an open network to connect to the Audrino.  I can look at this as soon as we get back in the office and we get the open network rebuilt.  I have given you an expanded buffer dll as described by your debugging but this did not seem to work so the issues seems to lay somewhere else.

Reply
  • FormerMember
    0 FormerMember
on Aug 31, 2020 9:38 AM in reply to Rocha

Hi Rocha,

I am not able to duplicate your exact configuration here at home (working from home due to Covid, yes, it a pain) since I do not have an open network to connect to the Audrino.  I can look at this as soon as we get back in the office and we get the open network rebuilt.  I have given you an expanded buffer dll as described by your debugging but this did not seem to work so the issues seems to lay somewhere else.

Children on Oct 27, 2020 11:57 AM in reply to yopi

The next release will have the bug fixes in it

  • Hi ,

    these are really good news. Can you foresee a release date of the new sigma studio version yet?

  • Hi yopi, 

    I am sorry to inform you that in addition to the already known bugs, we have other pending ones, which have not been properly addressed, in summary, I believe that fully functional will never be, I believe that Guenter will correct only the reading problem related to UTF8, other problems, as well as necessary implementations and improvements are no longer deal/discussed, between me and Guenter.

    Pending implementations and improvements:

    1) Fixed bug related to UTF-8, full reading 1024 bytes.


    2) Implement eeprom over TCP reading and writing

    3) Implement a new protocol, which is unique among all DSP models, as well as maintaining compatibility with the current protocol, with have more informations about destination IC

    4) implement receiving (assyncronous) reading of the Data Capture Registers, because without them, there is no way to view anything, like (Levels) in real time within Sigma Studio

    All this has beem related to Sigma Studio developer team, attached pdf has few suggestions, that will made easy for most developpers, also give more value to Analog Devices products.

    PDF

  • Hi GunterL,

    I'd like to highlight one more bug hopefully triavial to be solved:

    We are working with a project including 2 x ADAU1466.
    TCPIP block permit to connect up to 4 device and Sigmastudio seems supporting it propely.
    We have been expected that Sigmastudio differentiate Write/Read Request to the different IC indexing in the field "IC Address". However in Write Request IC is actually addressed by field "Channel Number".
    Unfortunately there is no that field in Read request, thus is impossible to know which IC Sigmastudio is trying to read back.
    (We are workaround on it setting manually in our micro if readback should be driven to DSP1 or DSP2)

    It looks a trivial error in the code due to register meaning misunderstanding by the guy have implemented it, hopefully could be solved in a minute.