SigmaStudio Selfboot with I2C and SPI findings
So I have been spending a lot of time integrating the ADAU1452 into a project requiring selfboot operation from an EEPROM and then the project working with a Microcontroller and communicating with the micro continuously.
I found a few things that were VERY difficult to debug and need to share to save others some effort. I welcome any corrections if people have found other things to be true:
1. SigmaStudio was never able to erase a EEPROM connected to the system. Either I2C or SPI, I could write through the DSP to the memory and verify selfboot worked but I could never erase the memory to re-write it. Since I had a microcontroller, plan was to use it to erase memory which would allow DSP to re-write it. This DOES work but only wtih I2C, not SPI due to #2 below...I repeated the same process multiple times...solder fresh memory, write through dsp...try to erase without success...give up and solder new memory. Yes, I had all commands correct and I observed this behavior on the ADAU1452 eval board too. Go to I2C memory and you can multi-master the memory to let a micro erase it.
2. the _M SPI bus does not seem to work in multi-master mode meaning I couldn't write to the memory when it was idle to erase it since SigmaStudio/DSP couldn't erase the memory. I switched to I2C and could erase fine (since DSP only uses the bus during self-boot and releases the SCL/SDA pins when done) so after selfboot, the micro could write to the memory and erase it.
3. _M I2C bus connected EEPROM could not be recognized at any address other than 0xA0. Using logic analyzer, the DSP would never try to write to another address, it was always using address 0xA0 even though I had configured 0xAC. Changing my I2C EEPROM to address 0xA0 allowed DSP to write to it and I could self boot from it. And I could tell SigmaStudio it was a different address but it would read from the I2C regardless of address configuration so long as the I2C EEPROM was configured physically as address 0xA0.
4. Simplest microcontroller-to-dsp interface I found was to use I2C and setup SigmaStudio program to periodically poll the I2C bus and the micro respond with necessary commands as needed. Likewise, DSP could transmit over the same I2C bus connection.
Hope this helps someone as this is 30+ hours of debug work and lots of soldering and tweaking.
i2c eeprom
Audio Signal Processors
adau1452
spi eeprom
eeprom
sigmastudio
SigmaDSP Audio Processors
selfboot
Show More
Hello EhrenAchee,
Sorry to hear you were having trouble. Let me comment on a few things to shed some light on this:
EhrenAchee said:
2. the _M SPI bus does not seem to work in multi-master mode meaning I couldn't write to the memory when it was idle to erase it since SigmaStudio/DSP couldn't erase the memory. I switched to I2C and could erase fine (since DSP only uses the bus during self-boot and releases the SCL/SDA pins when done) so after selfboot, the micro could write to the memory and erase it.
Neither the SPI or I2C master ports will operate with more than one master. This is in the datasheet on page 50:
"No error detection is supported, and single master operation is assumed. Only one bus interface protocol (I2C or SPI) can be used at a time."
For I2C you can get around that due to the architecture of the I2C bus. If the DSP is not trying to communicate, it will let the SCL/SDA lines float up which will allow another processor to use it. Likewise, if the DSP is trying to use it then another master MUST not try to use the bus. We do not support multi-master operation. So you are correct, you can use the bus once the selfboot is complete.
SPI is a very different case. The SCLK and MOSI lines are always driving the bus so if there is another master on the bus they will be colliding. So unless there is some sort of hardware setup to disconnect and isolate those lines from the bus you cannot use two master.
Next Issue:
EhrenAchee said:
3. _M I2C bus connected EEPROM could not be recognized at any address other than 0xA0. Using logic analyzer, the DSP would never try to write to another address, it was always using address 0xA0 even though I had configured 0xAC. Changing my I2C EEPROM to address 0xA0 allowed DSP to write to it and I could self boot from it. And I could tell SigmaStudio it was a different address but it would read from the I2C regardless of address configuration so long as the I2C EEPROM was configured physically as address 0xA0
Page 52 of the datasheet is rather clear of what the DSP assumes for the EEPROM requirements. For I2C the address can only be 0xA0 (0x50 for the 7-bit number) The selfboot program is hardcoded into the silicon so it cannot be changed. The setup in SigmaStudio has the address in there for other runtime uses where it is under software control. For SPI, the EEPROM must use the SS_M/MPO pin for the chip select pin of the EEPROM.
Next Issue:
EhrenAchee said:
1. SigmaStudio was never able to erase a EEPROM connected to the system. Either I2C or SPI, I could write through the DSP to the memory and verify selfboot worked but I could never erase the memory to re-write it. Since I had a microcontroller, plan was to use it to erase memory which would allow DSP to re-write it. This DOES work but only wtih I2C, not SPI due to #2 below...I repeated the same process multiple times...solder fresh memory, write through dsp...try to erase without success...give up and solder new memory. Yes, I had all commands correct and I observed this behavior on the ADAU1452 eval board too. Go to I2C memory and you can multi-master the memory to let a micro erase it.
Your experience here may have been clouded by the other issues I mentioned above. The memory on the eval board is SPI and it is able to be erased. I have done it many times as has most people who have used these eval boards. It has been tested heavily. What might be part of the issue is that you should lower the selfboot pin to take it out of selfboot when trying to do anything (program or erase) through the DSP. The reason is that the process of loading the data transfer program into the DSP requires the DSP to be reset using the soft reset. When that is done and the selfboot pin is high, it will try to self boot and load in a program while SigmaStudio is trying to load in a program. Often the selfboot fails or finishes before SigmaStudio starts trying to write to the program memory so it succeeds but other times it does not. I ran into this and figured out the issue. I was having to write to memory many times before it succeeded or erase it first then write to it.
I hope things go smoother after all this.
Dave T
Please log in to reply.