Not seeing I2C traffic on SCL2_M,SDA2_M pins with ADAU1463

Hello SoundConsulting,

Well, from what I can tell you are doing everything correctly. Now, one little thing you did not mention is if you are setting the I2C_M port to be split off?

SECONDARY I2C MASTER REGISTER
Address: 0xF5F0,

It is on the MP pin register page. The second page:

Before you boot up I assume the two pins are sitting high correct? So the pull-ups are doing their job?

It is difficult to troubleshoot some of this stuff remotely. I have a lot of practice doing it but it is still tough.

So I may need to see your project and get more details off forum.

Thanks,

Dave T

Yes, I did scroll to the bottom of the second MP pin page. That setting always seems to be On by default, whenever I create a new project. It's always Green. In other words, I have never changed it from the default. I interpreted the text on that button to mean that I should have it turned on and green if I want SCL2_M and SDA2_M to work as the second I2C Master bus, and not as MP24, MP25 pins.

^ If I should be setting that button to Off and Red, please let me know!

I measured the resistance between the I2C bus lines and IOVDD, and they're exactly 2.0 kΩ (or 1.99 kΩ) when the board is powered off. I will check the voltage again, but when it was attached to the analog 'scope I was seeing 3.3V on the clock.

Last night, I created a longer I2C Sequence with 36 bytes of varying bit patterns, and assigned an address that does not match any of my actual I2C devices (to avoid writing garbage to the registers). Even with this, I do not see any traffic on SCL2_M or SDA2_M.

I did notice that the Master Control Port module has settings for Edge Trigger or Level Trigger, but I assume those are not meaningful for the Startup module.

Note that when the glitch occurs (around the same time that DSP Readback stops working), I still only see 0x80, i.e., just a single bit high - presumably when SCL2_M drops just once and triggers a load of SDA2_M, which is still high.

When I turn off the power to my board with the Beagle I2C bus analyzer still active, I see a handful of 0xFF bytes. This probably means that the clock line becomes unstable when the power rails drop. I only mention it to show that the Beagle seems to be working, even though the bad news is that I only see 1-bit glitches or some garbage when power is removed.

to clarify, SS+ show "SECONDARY I2C Master Enable" with a Green button labeled "I2C master drives MP24 and MP25"

Now that folks are recommending SS 4.7 instead of the new SS+ releases, I see that SigmaStudio has that corresponding button in Red for switching I2C to the alternate MP24 and MP25 pins.

I tried to retest in SS 4.7, but I'm getting this error:

Master Control Port I/O: ControlPort11

'Address Byte Length' configured in the module does not match the sequence file(XML).

I understand the I2C EEPOM chips would have 2-byte or 3-byte addresses, but ADC, DAC, and A2B chips should all have 1-byte addresses. I created my Sequences with 1-byte I2C addresses, but SS 4.7 seems to have a lot of bugs related to the startup module and Sequence files, both in specifying the file in the dialogs as well as in matching the startup module settings to the Sequence file configuration.

Hello SoundConsulting,

Actually, you have this backwards. Look at the Capture window.

When I click on it to make it Green, this is what it send out:

A zero so it is NOT in the I2C spilt mode.

When you click on it and make it red, then it sends a ONE to set it into the mode you need.

So we may have found the issue!!

Dave T

Thanks for mentioning the Capture window - I have not even been looking at that. Now I see that because of the Address Byte Length error, the "IC 1.SECONDARY_I2C" Block Write is completely missing.

I've also taken your advice to stick with SigmaStudio, not SS+ ... should version 4.7 be the correct one to use?

I have made some progress - now Beagle sees a couple of I2C transactions to the correct address, but with 0 bytes of payload.

Here's what I did so far:

A) I had been using Pattern.xml created in SS+ and surmised that might be a bad choice, so I recreated my test pattern in SS 4.7

B) When SS complains that the Address Byte Length is wrong, I had to hand-edit that from "2" to "1" in the XML. Although SS+ allows you to specify the ABL of a Sequence, SS 4.7 does not appear to have a way to do that (please let me know if there is). At this step, I also edit the IC_Address to "8" so that I don't write garbage in the registers.

C) When I browse to select the new XML in the Control Port Properties, SS complains that the Sequence File does not exist. If I manually remove the directory name and path separator, it seems to find the Sequence File provided that it's in the same directory as the project.

D) When I Link-Compile-Download, Beagle shows a Write transaction for Address 8, but 0 Bytes. Perhaps this is because no chip is there to ACK.

I will try again with the actual register values for my ADC, and see whether that works.

Sorry for the frequency updates.

I now have transactions on SCL2_M and SDA2_M as desired, although it seems to require hand-editing of the XML to keep SigmaStudio 4.7 happy. I have not found any way to use the Sequence editor to achieve this, so if you have any advice it would be appreciated.

Note that I never see the "IC 1.SECONDARY_I2C" block writes when the startup module sends the data, and I cannot seem to get the Sequence editor to manually Download Mode to Hardware. Perhaps this is because there is no way to specify 1-byte address, or to target an IC that doesn't exist.

On that note, should I add components to the 'schematic' for the ADC, DAC, and both AD2437 chips? I suppose that would be a way to designate that they have 1-byte addresses and a unique IC_Address.