ADAU1701/1401 I2C addressing AFTER selfboot sequence
Dear friends! Still fighting with my super slow multi adau1401 project and here's my question. I'm trying to develop a board with 2 ADAU1401s and I want them selfboot separately from each own EEPROM. After that I want to connect I2C lines of all the chips and give them different addresses to be able to program them in Sigma Studio. Which rises a following issue. Datasheet, Self-Boot section, states:
After the ADAU1401A finishes self-booting, additional messages can be sent to the ADAU1401A on the I2C bus, although this typically is not necessary in a self-booting application. The I2C device address is 0x68 for a write and 0x69 for a read in this mode. The ADDRx pins have different functions when the chip is in this mode, so the settings on them can be ignored.
Which in turn means if I set ADDR pins of my chips 0/0 (both low) for chip 1 and 1/0 (ADDR0 - high) for chip 2 this is going to be no good because after chip 2 completes it's selfboot it's still going to be addressed 0x68/0x69. Is this assumtion correct? If it is, is it possible to set selfboot pin low after the selfboot sequence is complete to make the chip 2 "understand" it's I2C address?
adau1401a
Audio Signal Processors
adau1401
i2c issue
adau_1701
SigmaDSP Audio Processors
selfboot
Show More
Dave, thank you very much for your reply! Indeed I am thinking of a prototype where everything is going to be manual (jumpers), so I guess I'll have a chance to experiment with putting the dsp into this "sleep mode") Probably it's not going to happen soon, for that I am sorry)
You are mentioning I2C bus repeaters, now that makes me wonder, do you think my setup requires them? I was going to use just an analog switch (74HC4066) thinking that 2 ADAUs, 2 EEPROMs and USBi are not going anywhere near the I2C bus limitations... is there something I'm missing?
Hello Ivan,
I finally had a chance to investigate this and there is no way to "reactivate" the address pins once the part has performed a selfboot. In fact, lowering the selfboot pin cuts off all communication to the part. Now I suppose you could take advantage of that. Just lower the Selfboot pin on the part that you do not want to communicate with. I cannot easily test this so if you are able to try it then report back the results.
When I raise the selfboot pin back high I am able to communicate with it again. I do have to compile and connect each time (not download) after shutting it off because the USBi just sits there waiting for an ACK that it is never going to get. You should not have that problem because the other part will supply the ACK.
If this proves to have other side affects I am not aware of then the only other way to do this would be to use two I2C buss repeaters to steer the I2C commands to the proper DSP.
Let us know how it goes.
Dave T
Hello Ivan,
I am not sure if you will have issues with the analog switches. I have never tried to do that. I do know there is a lot of capacitance on these switches so that may limit the speed of the I2C or might cause intermittent errors with data transfers. All the devices on the bus have to be high impedance when not driving the bus low so I guess the 4066 would do that. I am guessing you will not have any 5V I2C in the design so you should be fine with voltage levels.
The "On" resistance can be high which may cause signal integrity issues if there is too much damping of the signal. So my gut feeling is that there will be issues but I cannot point at something right now that would tell me that it will not work at all. I do think you will have issues if you try to run the speed up too high.
Dave T
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Strangely enough, 10 years haven't passed)) and there's an interesting development here.
My setup is a two-chip ADAU1701 board with chips addressed as 0x68 and 0x6C, this is hardwired. Then I finally organised everything else as buttons and I have button 1 that links-unlinks I2C between chips and button 2 that sets up selfboot pins, EEPROM addresses and write-protects. To be short: you press both buttons - and you're programming. You depress buttons - each chip is on an independent piece of I2C bus and in self-boot.
Now, I selfboot ADAUs, press both buttons, I2C bus gets linked, self-boot pins go low, then I load my project into SigmaStudio, press LinkCompileConnect and enjoy jumping level meters. If I depress button 2, which again does exactly what? - right, except changing one EEPROM address and setting write-protects (which shouldn't mean much once self-boot is complete) it only rises selfboot-pins on both ADAUs - so, I depress button 2 and I see chip 0x6C stop to communicate with SigmaStudio. I press it again, after a sec it communicates again. And I don't touch anything on the computer.
So my conclusion is that high self-boot pin kind of freezes I2C operations of the higher address ADAUs while the one that has low address pins still communicates. When self-boot pin goes back low ADAU remembers its address and starts communicating. And you can do it hot without any resets or recompilations of your project. While sound goes through both chips without any interruptions. Weird, eh? But that's exactly what I hoped for))
Don't know if this is of any use to anyone, but anyway)
Please log in to reply.