Post Go back to editing

2 ADAU1701 AND 1 1 I2C LINE

Hello, there. The card I designed includes 2 ADAU1701, 3 tanae EEPROM and 1 processor. They are on the only I2C line to communicate with each other. I've made and run software for 1 Adau in the Sigma studio app. But 2. Adauya code is not going. The device is not connected error. How do I solve this? Do I have to do the software for two candidates in one project when I create the project? If you have a source document on this issue, can you pass it on? What should I do?

1.ADAU1701 Address 0x68
2.ADAU1701 Address 0x6A
1.EEPROM address 0xA6
2.eeprom address 0xA0
3.EEPROM 0xA8

Parents
  • Hello, there. Another question is, how do you identify the address from the R/W pin in the Table 16 address table on page 23 in the datasheet of ADAU1701? It should not be identified from the R/W pins. I have to do reading and writing. Already there are no such addresses in the sigma studio. The Sigma studioda can provide 8 addresses for I2C. But how do you do that with 2 address pins? I'd appreciate it if you could help me with that.

Reply
  • Hello, there. Another question is, how do you identify the address from the R/W pin in the Table 16 address table on page 23 in the datasheet of ADAU1701? It should not be identified from the R/W pins. I have to do reading and writing. Already there are no such addresses in the sigma studio. The Sigma studioda can provide 8 addresses for I2C. But how do you do that with 2 address pins? I'd appreciate it if you could help me with that.

Children
  • Hello YLmazGNDZ,

    I wish they did not put in the R/W pin state in that table 16. It only confuses the issue. Just look at the lines where R/W is zero. So the four addresses set by the pins are 0x68, 0x6A, 0x6C and ox6E.

    These are the only address combinations you can get with the two pins. Yes, the address byte will be different when you set the byte for a read but that is a different subject from just setting the address.

    In SigmaStudio the USBi for some reason has four more addresses. Do not use those, the 1701 cannot use those addresses. 

    Now there are other more serious issues you will have to work out. The 1701 can only selfboot from one EEPROM address, A0. So you will have to separate the I2C buss between the two part when selfbooting. Once the self boot is complete for both DSPs, then you can connect the two I2C busses together. There are bus repeaters available that you can setup to connect using what ever logic you desire. One good way is to use the 5V output of the USBi to trigger the repeater to connect the two busses. You can also use digital switches. There are many ways to do this. You can also use jumpers. 

    Dave T

  • Hello Dave,

    in this way, we have a board with two ADAU1701 and two EEPROMs. In self-boot mode, the two ADAUs read data from its own EEPROM at 0xA0 (I2C bus separated), and with USBi, the two EEPROMs at 0xA0 and 0xA4 can be written independent. Unfortunately, SigmaStudio only ever writes to 0xA0, even if the second EEPROM is specified as 0xA4. Apparently, there's no mapping of which data for which DSP should be written to which EEPROM.

    Konfiguration with two ADAU and two EEPROMs

    Could this be a bug in SigmaStudio or is there an option to solve the problem?

    Harald

  •      Hello Harold,

         For what it's worth, you might consider booting your -1701s from your micro.  The -1701 is easy to boot with just three block writes.  Link-Compile-Download your project without hardware connected (ignore the error message).  Then, select Export System Files.  Among the files this generates is a TxBuffer.txt file for each DSP.  Open with Notepad to see the instructions, the parameters, and the HW config register contents.  Copy and paste each block into its own byte constant in your uC source code.

         On power up, your microcontroller should first wait a moment for the DSPs' PLLs to lock.  Then have it write those three blocks to first one and then the other DSP.  Where I work we have a uC running two I2C busses with three -1701s on each.  We have one SigmaStudio project with three DSPs for each I2C bus.  To allow for flexible development, we have jumpers to either load one bus at a time via USBi, or connect the micro.

         Best regards,

         Bob

  • Hello Bob,

    Sorry. Misunderstanding. We have two ADAUs and two EEPROMs - no other CPU or microcontroller. This implementation can be easily edited in one SigmaStudio project and also loaded into the DSP via USBi. However, when writing to the EEPROMs, SigmaStudio doesn't differentiate between the EEPROMs and also writes the contents for DSP #2 to the EEPROM of DSP #1.

    There seems to be no mapping from DSP to EEPROM.

    Regards Harold

  •      Sorry my bad.  As Dave said, you'll need a switching or jumper arrangement.

         Best regards,

         Bob

  • That's exactly what we did (see above). But SigmaStudio seems to have trouble distinguishing between DSP and EEPROM mappings.

    Maybe Dave can take another look at this

    Regards

  • Hello Harald,

    The problem here is that the hard-coded state machine built into the DSP is not very sophisticated. Making it more flexible would have made things more complicated and might have required more pins on the package which impacts cost. The state machine wakes up and if the Selfboot pin is active, then it looks for the EEPROM at the base address and cannot look at any other address. So you will need to figure out a hardware fix. If it is possible to have a jumper on the board to combine the two I2C busses then you could talk to both DSPs with SigmaStudio. Then jumper to only to one to program the EEPROM and then jumper over to the other I2C bus to program the other EEPROM. Then leave the two unconnected to each other. Then at power up they will only "see" their one EEPROM because both EEPROMS need to be set to A0. (I think that is the address? It is in the datasheet) 

    So that would be the workaround. One of our old engineers that the seasoned SigmaDSP enthusiasts will remember, Brett, He had tried in the lab to hook up a bunch of ADAU1701 DSPs all to one EEPROM. Then he set them up to all selfboot. They all woke up as a master on the I2C bus but they all were doing the same thing, trying to read from the same addresses on the EEPROM. They all expected the ACK at the same time and it worked! I do not know how wise it is to do for a product but he was able to load in the same program into several DSPs. If your program is exactly the same for both DSPs then you may be able to try that. 

    Otherwise, you will have to separate the two I2C busses or get a controller to boot them up. I had written an Apps note years ago for using an 8-pin PIC to boot up a codec. The part is like $0.99 and is easy to program. Well, I have done a fair amount of PIC programming and have the C-language tools for it. 

    I wish I had better news. Perhaps someone else on the forum has other tricks they have done. 

    Dave T

  • Hello Dave,

    Thank you very much for the detailed answer.

    But as I've already tried to make clear, in the case of selfboot, I have two separate I2C buses, but of course not when accessing via USBi. Here, both buses have different addresses for all four chips (see SigmaStudio screenshot above). Realised by a FET switch.

    In case of selfboot the addrress of the EEPROMs is for both DSPs the same (switch with selfboot signal).

    The problem is, that I may handle the different DSPs within one file in SigmaStudio and for this case I have the configuration with different addresses but SigmaStudio seems to be not able to write the content of both EEPROMs to the dedicated EEPROM. Both contents are only written to the first EEPROM. The second EEPROM will be ignored. So in selfboot the first DSP starts with the content for the second DSP and the second DSP does not find any information or starts with an old program which may bi in the second EEPROM.

    Short: In the configuration shown below, SigmaStudio writes content only to the first EEPROM and not the corresponding content to both EEPROMs with different addresses.

    Harald