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

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.

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 Rocha,

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 Rocha

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

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.

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 ,

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

The next release will have the bug fixes in it

Hi Guenter, please fix all those bugs.

Rocha made so much efforts describing et proposing fixes, that would be a pity not fixing it now ! All the community is waitng for your patch. We really need SigmaStudio tcpip fully functionnal.

Hi Guenter, i have reversed all TCP.DLL to source code, now i can rebuild,and debug all code! so i have solved one more bug ( All bytes from packet can be read without looses, for ADAU1701 all four reads get 1024 bytes correctly ), but have a lot of bugs remain, also need improvents to allow fast develoment, we now living age of IOT and user of TCP/IP on DSPs for programing and control is all we need.

The original code of TCP.dll, bug has found! In UTF8 encoding, I can't imagine why anyone converts an array from integer to string if all the data inside it is integer! and even more, convert to array of integers again.

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.

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.

Hi Dave,

I am working on an implementation of the Sigma TCP protocol on a small system too.
There is one thing very important that Rocha mentioned and I would like to put more emphasis on this. Sigma Studio absolutely needs to wait for an answer after issuing a read request, or the number of requests and the timeout need to be configurable.
Imho this is very important and would greatly improve QoL when developing for a remote device.

Cheers =)

Hi Rocha, I now have the ESP8266 board and a 1701 board in the office. I plan to build the setup per you instructions issue so I can debug it. Please move the ESP8266 code to the dropbox.

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 a couple days.

Hello Lorenzo,

I have added your issues to the bug report for the software team.

When you mentioned short 3 or 4 byte messages are not working, I need to say that you need to read/write the correct number of bytes. Parameter RAM will be 4 bytes and most registers are 2 bytes. So performing a 3 byte read may cause issues with the comms port. I do not think this is the issue but it is something to check.

Dave T

Hi mk_sounds, DaveThib

Response of mk_sounds question of what work or not.

A) Without any changing, you can do anything USBi does, using TCP/IP, that means, if it works with USBi works also with TCP, with the folowing exceptions:

1) Full reads of data from Parameters RAM ( 0x0000 to 0x03FF ) will not works, partial reads on this address interval (few bytes), will works!

2) Full reads of data from Program RAM ( 0x0400 to 0x07FF ) will not works, partial reads on this address interval (few bytes), will works!

3) Eeprom read/write is not possible!!!

NOTE: All registers with size of (1,2,3,4,5) bytes, it can be readed/writed "with or without" modification/patch on dll, i have checked at least 25 sequential registers on single request ( +- 100 bytes ), and works very well.

B) With modifications (Patched), reads of data from Program RAM and Parameter RAM is possible, but not all times, sometimes 1..9 bytes are missing on Sigma Studio for first two packets response, so you must insists more than once, to have success, ( Remeber: Sigma Studio expect response with "4" packets with 1024 bytes each ).

NOTE:

A) If anyone have trouble reading or writting to DSP, please double check your code, because definitely has a problem, i will share my code with this comunity on a next days, but i will do in a new post, this one is growing up.

B) Read and write to EEPROM using TCP/IP is NOT possible with Sigma Studio!!! But, is possible using micro controller, that reads data available directly from DSP using I2C or SPI ( Data in RAM and Configuration Registers ), and writing it direclty to EEPROM!, this procedure apply wheen SELF BOOT, ( PS. Microcontroler can receive command from Sigma TCP/IP to do this, but used button is not made for this procedure, button have tha folowing text "Register Connection ASAP", i dont know what is real purpuse for this button at this moment, but for me is "write to Eeprom!"

C) Also same procedure is possible, but instead of EEPROM, data can be writed to SPIFSS ( Microcontroler or SD Card Filesystem ), this way is not hardcoded in code, is dynamic code, this procedure apply without SELF BOOT.

Hi DaveThib,

are there any news of the software team? Will the tcp/ip issue be fixed in the next release of sigma studio?

Kind regards,

Markus

Hi Markus,

I will jump in here for a moment. We have prioritized this TCP/IP issue and it is being addressed. I can't guarantee that it will make it into the next release but I will keep an eye on it.

Joshua

This bug was reported as a problem almost a year ago, soon we will be able to celebrate his birthday, with no solution.

Hello Marcus,

We are working on it. At this point it will probably not make the Rev 4.6 release. Someone is actually working on it now so that is good progress.

Dave T