I got my board working guys/gals!
1) I'm not sure if the EEPROM supplied onboard was SPI or I2C because I can not find datasheets for it. However I do know my board was set to use an I2C EEPROM because of the ressitors in use around the EEPROM.
So, I replaced the EEPROM IC with a known I2C device (512bytes).
2) The ADAU1452 datasheet P.52 specifies that it looks for self-boot EEPROM on address 0x50 (7-bit hex). In Sigma Studio on the USBi controls (8-bit) this is 0xA0.
This means on most I2C EEPROMs (incl. the one I used), all 3 of the address pins must be pulled low (grounded). However the PCB in factory configuration had EEPROM Pin 1 connected to ADAU1452 pin 26 'SS_M/MP0' and when running this pin is HIGH 3.3V. This means the EEPROM address is not 0x50/0xA0.
3) The ADAU1452 datasheet P.52 specifies that Pin 26 'SS_M/MP0' must be pulled LOW to define EEPROM as I2C. (Pin 26 HIGH = SPI).
Since ADAU1452 pin 26 is connected to EEPROM Pin 1 I simply pulled EEPROM Pin 1 LOW to ground.
Now it works!
I can program the EEPROM by right clicking the ADAU1452 in the SigmaStudio 'hardware' tab and choosing SelfBoot Memeory > Write latest compilation through DSP. It doesn't seem to matter if the self boot pin is enabled or not.
However, I did also find that I can write the I2C EEPROM a second way:
Connect programmer board directly to EEPROM pins SCL and SDA. In the hardware tab you can Right-click on the EEPROM IC2 > Read/Write Window. Follow the images below to write directly to the EEPROM from the programmer board. The IC2 .hex file will not be generated unless you already clicked 'Link, Compile, Upload'.
This method actually writes faster than doing it through the DSP, but of course you need to connect the programmer directly to the EEPROM.
1) I'm not sure if the EEPROM supplied onboard was SPI or I2C because I can not find datasheets for it. However I do know my board was set to use an I2C EEPROM because of the ressitors in use around the EEPROM.
So, I replaced the EEPROM IC with a known I2C device (512bytes).
2) The ADAU1452 datasheet P.52 specifies that it looks for self-boot EEPROM on address 0x50 (7-bit hex). In Sigma Studio on the USBi controls (8-bit) this is 0xA0.
This means on most I2C EEPROMs (incl. the one I used), all 3 of the address pins must be pulled low (grounded). However the PCB in factory configuration had EEPROM Pin 1 connected to ADAU1452 pin 26 'SS_M/MP0' and when running this pin is HIGH 3.3V. This means the EEPROM address is not 0x50/0xA0.
3) The ADAU1452 datasheet P.52 specifies that Pin 26 'SS_M/MP0' must be pulled LOW to define EEPROM as I2C. (Pin 26 HIGH = SPI).
Since ADAU1452 pin 26 is connected to EEPROM Pin 1 I simply pulled EEPROM Pin 1 LOW to ground.
Now it works!
I can program the EEPROM by right clicking the ADAU1452 in the SigmaStudio 'hardware' tab and choosing SelfBoot Memeory > Write latest compilation through DSP. It doesn't seem to matter if the self boot pin is enabled or not.
However, I did also find that I can write the I2C EEPROM a second way:
Connect programmer board directly to EEPROM pins SCL and SDA. In the hardware tab you can Right-click on the EEPROM IC2 > Read/Write Window. Follow the images below to write directly to the EEPROM from the programmer board. The IC2 .hex file will not be generated unless you already clicked 'Link, Compile, Upload'.
This method actually writes faster than doing it through the DSP, but of course you need to connect the programmer directly to the EEPROM.
Last edited:
Member
Joined 2018
Nice Speaker you made!
Unfortunately the device is Cypress CY7C68013A.
I hope someone will develop the FT232H driver emulates USBi or AARDVARK for SigmaStudio.
Thanks
Last edited:
That is extremely unlikely to happen. Analog Devices, when creating the USBi, originally wrote the code for a Cypress chip. Someone a long time ago figured out that the Cypress chip used by AD in the USBi was almost identical to the one used on the cheap development boards. So they figured out a way to trick a generic Cypress development board into providing the same USB product ID as the AD one. That way, the AD driver uploads the necessary code into the development board. The code that AD wrote.
For someone to create an USBi out of any other microprocessor (or interface chip like the FTDI ones), they would need to completely reverse engineer the communication between SigmaStudio and the USBi, then re-implement all that code. Given that a Cypress dev board is universally available and extremely cheap (actually cheaper than some FTDI boards), I cannot see anyone motivated to write all that code (not to mention the risk that any change that AD makes in SigmaStudio, will require yet another reverse engineering)
Someone in the AD forum (Rocha IIRC) made a TCP/IP programmer based on Espressif ESP8266 or ESP32 chip. I didn't tried his firmware because I developped my own ethernet solution since a long time.
He decompiled SigmaStudio in his entierty and found several bugs that AD is taking ages to fix.
Those DSPs are very good for most audio uses, but I tend to get away from them because AD is very slow in adressing issues we've been pointing at. They are not responding to me about a bug occuring with their Holters filter implementation for example, and those were essential for one of my project which is now stuck since monthes without any answer from them...
Right now I am going to try a Teensy 4.1 running Faust generated code, and I'm waiting impatiently for the FPGA toolkit of GRAME.
Good job @Tenson.
He decompiled SigmaStudio in his entierty and found several bugs that AD is taking ages to fix.
Those DSPs are very good for most audio uses, but I tend to get away from them because AD is very slow in adressing issues we've been pointing at. They are not responding to me about a bug occuring with their Holters filter implementation for example, and those were essential for one of my project which is now stuck since monthes without any answer from them...
Right now I am going to try a Teensy 4.1 running Faust generated code, and I'm waiting impatiently for the FPGA toolkit of GRAME.
Good job @Tenson.
Yes and no. I have used that programmer, but it was just hardcoded to work with ADAU1401/1701. What the programmer did, was to reverse engineer the TCP/IP protocol from AD, then implement an hardcoded ADAU1701 implementation. Basically the same way you can create an Arduino program using the header files from SigmaStudio and loading the right values in the DSP or EEPROM. Clever and the author did a lot of work finding bugs in the TCP/IP implementation, but it's not a generic USBi replacement, nor the author reverse engineered the USBi driver/code implementation.
That code needed to be adapted to every single chip supported by SigmaStudio, in order to be a USBi replacement... And since the author has not released the source code, it will not be adapted to any chip that the author doesn't have (like the ADAU1452)
The TCP/IP protocols are documented by AD (at least for the 1452), there even are some code examples. Like I said, I made my own implementation and it works exactly like the USBi, except it doesn't because of the poor handling of the TCP/IP socket by SigmaStudio.
Round trip latency is a big issue and doesn't allow real time read from the DSP via Wifi (or well you can but it will crash). SigmaStudio should open the TCP/IP socket with a -NODELAY argument, which doesn't seem to be the case, making small packets wait 250ms in the stack in the computer. Also, the protocol does not provide any form of acknowledgement back from the flasher. Meh, a lot of things have been overlooked by AD here actually.
I don't remember exactly why Rocha had to check the ADAU1701 TCP implementation. Maybe there was some discrepancies between the docs and what SS actually does. And again, I tell you, he decompiled ALL Sigma Studio, can compile it back, and almost got banned from the forum after having shown snippets of code. I was there. Brilliant.
Round trip latency is a big issue and doesn't allow real time read from the DSP via Wifi (or well you can but it will crash). SigmaStudio should open the TCP/IP socket with a -NODELAY argument, which doesn't seem to be the case, making small packets wait 250ms in the stack in the computer. Also, the protocol does not provide any form of acknowledgement back from the flasher. Meh, a lot of things have been overlooked by AD here actually.
I don't remember exactly why Rocha had to check the ADAU1701 TCP implementation. Maybe there was some discrepancies between the docs and what SS actually does. And again, I tell you, he decompiled ALL Sigma Studio, can compile it back, and almost got banned from the forum after having shown snippets of code. I was there
. Brilliant.Not the same thing but I didn't tried the Rocha firmware, so can't tell. The headers included into the exported files of SS (with the generate files function in SS) are just easing an MCU implementation for standalone control and update.
I stand corrected on how the TCP/IP protocol works, thanks for the additional info. But it's still very different from how the USBi driver works, and doing that would require a separate reverse engineering effort, which would hardly be justified given how cheap the Cypress dev boards are
Do you have your TCP/IP - ADAU code shared somewhere? Rocha never published his, and I think many people would benefit from learning more
Do you have your TCP/IP - ADAU code shared somewhere? Rocha never published his, and I think many people would benefit from learning more
Hi Guys...
Im Rocha... Nice to see that people talking about TCPi Interface.
TCPi can handle most ADAU DSPs right now, in automatic way, also you dont need eeprom anymore, because TCPi can handle firmware exported from Sigma Studio and boot automatic DSPs, also many others improvements.
New features
Version 2 of TCPi Interface is not an update, it has been entirely rebuilded
Support for multiple DSP models with Sigma Studio auto detection, like 1401, 1702, 1452, 1466 and others.
Automatic detects DSP presence on I2C or SPI bus, first it try to connect using I2C, if there is no response, DSP will be initialized using SPI. Please note: SPI does not have acknowledge!
GPIO pins can be configured, this allow use of existing boards with diferent ESP models connected to DSP.
TCP-IP Protocol is now detected with smart code, user only need setup dsp model inside Sigma Studio and start uses.
Can now boot DSP after every power-on, just need upload exported xml file from your Sigma Studio project, no need external conversions.
Built-in Web admin interface, that allow user customize interface parameters, also upload files.
Customizeable User interface, thats allow realtime control of DSP parameters, like volume, mute, EQs and more... Just upload your minimal custom html files, samples of html and Sigma Studio project is provided.
Connection with Sigma Studio can be disabled/blocked by admin, this way only custom interface will work.
Can adjust Volume, Mute and Parametric EQ, using custom web interface, pending load/save profile.
you can see user customized controls example at TCPi - Custom user interface
Its in final beta, who wants to try it, just ask.
Best regards...
Rocha
I forgot to say, I can modify and recompile the USBi driver, it's not complicated code.
I wrote a code for USB using Microhip PIC 18F4550, also for Atmega32u4, they works with USBi original driver ( Its a USBi Clone with same PID/VID ) however I prefer with Espressif WiFi ( ESP32 and ESP8266 ).
Regarding the real-time audio level and other reads, the problem is not WiFi, WiFi can handle it as well, the problem is Sigma Studio, which floods via TCP/IP, it requests data more than 250 times per second.
I wrote a code for USB using Microhip PIC 18F4550, also for Atmega32u4, they works with USBi original driver ( Its a USBi Clone with same PID/VID ) however I prefer with Espressif WiFi ( ESP32 and ESP8266 ).
Regarding the real-time audio level and other reads, the problem is not WiFi, WiFi can handle it as well, the problem is Sigma Studio, which floods via TCP/IP, it requests data more than 250 times per second.
Hi Rocha ! Very nice to see you there
Yeah what you said is true about wifi. Still, I remember a direct ethernet connection enabled me to do slightly more reads.
I see you've kept yourself busy with your firmware. Great functionalities.
Do you have a "fixed" TCP/IP dll you would share?
Robca: my sources are on an inactive server at the moment. I'll try to make the source available as soon as I have some time. You will need and ESP-IDF toolchain to compile it. And it will only work on the ESP32 with an ADAU145x. But seeing what the Rocha firmware could do I don't think it would be wise to try to improve on that.
Yeah what you said is true about wifi. Still, I remember a direct ethernet connection enabled me to do slightly more reads.
I see you've kept yourself busy with your firmware. Great functionalities.
Do you have a "fixed" TCP/IP dll you would share?
Robca: my sources are on an inactive server at the moment. I'll try to make the source available as soon as I have some time. You will need and ESP-IDF toolchain to compile it. And it will only work on the ESP32 with an ADAU145x. But seeing what the Rocha firmware could do I don't think it would be wise to try to improve on that.
Last edited:
About fixed DLL, Analog Devices have partial fixed, there are many problems/bugs remaining.
I have completely rebuild dll that add two DSPs ( ADAU1372/1772 ) that does not exists on Sigma Studio itself, so users with that DSPs can now uses TCP/IP too.
This new DLL can be downloaded, link: tcpiipdll.rar
About realtime reads level and another dsp data, TCPi can handle 2 simultaneos VU levels without chrash, this works with original dll.
Using custom user TCPi html interface, it can handle 8 simultaneos VU levels.
Best regards.
I have completely rebuild dll that add two DSPs ( ADAU1372/1772 ) that does not exists on Sigma Studio itself, so users with that DSPs can now uses TCP/IP too.
This new DLL can be downloaded, link: tcpiipdll.rar
About realtime reads level and another dsp data, TCPi can handle 2 simultaneos VU levels without chrash, this works with original dll.
Using custom user TCPi html interface, it can handle 8 simultaneos VU levels.
Best regards.
Prototype DSP
Thought I'd post a few pics of my prototype based on the ADAU1467 core board.
I designed a pcb to connect it up to the following :-
Inputs
2 x USB I2S (only 1 connected at the moment)
SP/DIF
Bluetooth I2S
ADC pcm1802
Outputs
4 x Pcm5102a DACS (3 populated at present)
Jumpers/pins to allow use of alternative LDOs for analogue sections
Jumpers for 7 rotary encoders for volume (main, sub, 5 inputs) plus aux ADCs that I use for mute.
Other pins broken out on headers.
Future development includes ESP32 for remote control
The board isn't perfect, but it works and is easy to assemble with just a soldering iron as the SMD caps are 1206
I made the mistake of thinking MP1 and MP3 were usable, so had to use alternatives from the aux header instead. (They're used for the self boot EEPROM)
Thought I'd post a few pics of my prototype based on the ADAU1467 core board.
I designed a pcb to connect it up to the following :-
Inputs
2 x USB I2S (only 1 connected at the moment)
SP/DIF
Bluetooth I2S
ADC pcm1802
Outputs
4 x Pcm5102a DACS (3 populated at present)
Jumpers/pins to allow use of alternative LDOs for analogue sections
Jumpers for 7 rotary encoders for volume (main, sub, 5 inputs) plus aux ADCs that I use for mute.
Other pins broken out on headers.
Future development includes ESP32 for remote control
The board isn't perfect, but it works and is easy to assemble with just a soldering iron as the SMD caps are 1206
I made the mistake of thinking MP1 and MP3 were usable, so had to use alternatives from the aux header instead. (They're used for the self boot EEPROM)
Attachments
Last edited:
Nice!
My efforts on making a breakout board for the core boards has been stalled for a while now as I've done other DIY projects, and I have a DCX2496 as well as two working FreeDSP classic boards (and the ADAU1452/ADAU1466, black boards w/out the u-controller).
Anyway, nice work!
Hi all,
I recently purchased an ADAU1467 core board as well as the corresponding 8 input 8 output base board with the analog inputs and outputs. I'm having a little bit of a problem with trying to get SigmaStudio to recognize this. I have a Sure or Wondom ICP3 (similar to the Dayton Audio ICP1). This programmer appears not to support SPI, so I'm using I2C.
I ran some wires to the core board, and plugged it in. When attempting to load the sample program, SigmaStudio says "Active, Downloaded" for a second, then back to "Comms failed". The program is not loaded correctly.
If I disconnect the I2C lines, it doesn't do this, and stays at comms failed. I have already configured the strapping resistors for I2C operation per the included schematic.
Wondering if anyone else has had any luck getting this to work with I2C or whether I need to buy a USBi that supports SPI. The programmer works fine with an ADAU1701 board from Sure/Wondom (the JAB5).
Thanks!
I recently purchased an ADAU1467 core board as well as the corresponding 8 input 8 output base board with the analog inputs and outputs. I'm having a little bit of a problem with trying to get SigmaStudio to recognize this. I have a Sure or Wondom ICP3 (similar to the Dayton Audio ICP1). This programmer appears not to support SPI, so I'm using I2C.
I ran some wires to the core board, and plugged it in. When attempting to load the sample program, SigmaStudio says "Active, Downloaded" for a second, then back to "Comms failed". The program is not loaded correctly.
If I disconnect the I2C lines, it doesn't do this, and stays at comms failed. I have already configured the strapping resistors for I2C operation per the included schematic.
Wondering if anyone else has had any luck getting this to work with I2C or whether I need to buy a USBi that supports SPI. The programmer works fine with an ADAU1701 board from Sure/Wondom (the JAB5).
Thanks!
Dear Rocha,
I would very much like to try the software,
also, could you please recommend a board to run it on? (i need to purchase a board, I'd rather buy one that you know works)
thanks!
I'd suggest trying all of the I2C address options in turn, to see if the board simply has a different address than expected.
Yes, could just be the I2C address. You can also try to probe the I2C address pins and check how they are set.
A bit hard to guess what could be wrong without some documentation. We can guess but the schematic may reveal some interesting things if you can share it.
I have the ADAU1467 core board and Sure programmer, it works fine.
Programming is identical to the adau1452, see my instructions further back in the thread. Try programming it not plugged in to the other board, you might have power issues. Not sure what you've done with regard to resistors, I didn't change anything and it just worked.
I picked up 3 of these board combos last year May. Been using them 96k without a problem, up to now. With the boards vertical, the 1938 had no issues.
However, all of a sudden, each of them, within a month of eachother, has started 'jamming up'... they run fine, either downloaded or eeprom based, and then randomly stop processing. The led turns on a dim white when this happens. Resetting the boards does the same thing.
Yes, checked the output of the voltage regulator, its within spec. Also have removed the 1938 board.... and the dsp still all of a sudden just stops. The dsp's have never run hot, btw, always cool.
Any ideas given what folks have seen that might cause this?