Issue with I2C in Waveforms SDK when using AD2

[dynamatt]

Hi guys,

I've been having some trouble getting the I2C working on my Analog Discovery 2 when using the Waveforms SDK on Windows 10. The issue occurs when using both the `FDwfDigitalI2cRead` and `FDwfDigitalI2cWriteRead` functions.

The weird thing is that it works fine when using the Waveforms application (v3.20.1), so I know it's wired up correctly, but when I use the SDK to read back I2C data the bytes read back are rubbish.

After confirming that all my settings were correct in my C# code (i.e. same digital IO pins, clock stretching enabled, same sample rate) I tried using the Python example `Digital_I2C.py` and got back the same rubbish data. So I'm not crazy! 🤔

After banging my head against the wall for hours I was out of options. I decided to install some new and old versions of Waveforms and see if there had been a regression. I tried:

• v3.20.1 - did not work
• v3.20.24 (beta) - did not work
• v3.18.59 (beta) - IT WORKED!

Note that in all versions listed, the I2C works fine via the Waveforms application, but somewhere between v3.18.59 and v3.20.24 a regression was introduced that prevented the I2C reads from working via the API.

I'm sticking with v3.18.59 now because I know it works, but I'd love to use the latest version if this bug gets fixed.

Thanks for all your help and for producing such an awesome product!

[attila]

Hi @dynamatt

Could you attach some code or script with problem ?

Here a Python example is run on Analog Discovery 2 and Digital Discovery is used as slave with WaveForms application.

[dynamatt]

Hi @attila,

For a bit of additional background - I'm running Waveforms as a Master and talking to an ATtiny85 microcontroller.

Here's a screenshot of Waveforms v3.18.59:

I've programmed my slave device to return it's address (h62), followed by a count that increments each read, followed by four zeros.

Here's a modified version of the Digital_I2c.py example that has been tweaked to connect to different pins and to set an analog IO voltage output of 3.3V:

Digital_I2c.py

The output of this script when using the v3.18.59 SDK looks like this:

PS C:\AnalogDiscovery> python .\Digital_I2c.py
Opening first device
Configuring power...
Configuring I2C...
Separate Write and Read:
[98, 79, 0, 0, 0, 0]
[98, 80, 0, 0, 0, 0]
[98, 81, 0, 0, 0, 0]
[98, 82, 0, 0, 0, 0]
[98, 83, 0, 0, 0, 0]

As you can see, it's working as expected.

Then I upgraded to Waveforms v3.20.1. Again, using the Waveforms software works as expected:

However, running the same attached script with SDK v3.20.1 gives me garbage:

PS C:\AnalogDiscovery> python .\Digital_I2c.py
Opening first device
Configuring power...
Configuring I2C...
Separate Write and Read:
NAK 5
[102, 60, 24, 103, 204, 0]
NAK 5
[102, 60, 48, 103, 240, 0]
NAK 5
[204, 120, 48, 207, 248, 0]
NAK 13
[204, 120, 48, 120, 0, 0]
[102, 60, 24, 60, 6, 0]

Thanks so much for your help, and let me know if you need any more details.

[attila]

Hi @dynamatt

The script is working for me with 3.20.1, 3.20.24 (I only added to print the sw version and device name)
Again, script uses AD2 and DD is used for slave.

What are you powering from the AD2's V+ 3.3V ?
Is ~500ms sufficient for this to power up? 

 

Running code in WF Script, to have similar timing as in the earlier Python script, would look like this:

Supplies.MasterEnable.checked = 1
wait(0.5)
for(var i = 0; i < 5; i++){
    print(Protocol.I2C.Read(0x62, 6))
    wait(1)
}
Supplies.MasterEnable.checked = 0

 

[dynamatt]

Hi @attila,

I have reproduced your script in Waveforms and everything works correctly. I even monitored the I2C lines with the oscilloscope to see what is happening.

To answer your question about what the 3.3V is for - I'm using it to generate the 3.3V rail to pull up the I2C lines, since I'm interfacing the Analog Discovery with some Arduino's running at 5V.

 

Regardless, I'm sure that the I2C interface is working correctly because it's working through the Waveforms software.

The part that I'm still confused about is why it doesn't work through the SDK...

I decided to do a bit of digging. I installed API Monitor software from http://www.rohitab.com/ and started looking at calls to dwf.dll.

There is a lot going on in the way of monitoring the status of the Analog Discovery. I filtered that out and had a look at what happens when I click the "Read" button in the "Protocol" tab. Something like this:

That's a lot of API calls! But strangely none of them contain "I2C"! Here's what it looks like when I add the "I2C" filter:

So it seems to me that there is a difference between how Waveforms works and how the SDK works.

Would you be able to shed some light on this or provide a link to documentation?

Thank you again for your help!

[AdamN]

Sorry to drag this up over a year later, but I have encountered the same issue, and have more information to add/supplement.

I'm using the C sdk included with V3.22.25 of Waveforms.

Following relatively closely the process used in the python example, I've been seeing a delay on the SDA line by 1 bit, basically making the address byte unable to be read by the i2c slave device.

This is what I've been seeing when using waveforms to interface with a device with an address 0x40:

And when i run the code using the SDK (both with seperate read/write functions, and the readwrite function showing the exact same result):

As can be seen, there's a single clock cycle delay in the SDA line, causing the address to change.

If people have a solution to this, it would be greatly appreciated!

Thanks.

[AdamN]

Just adding this on after a little bit more research.
It seems like the SDK isn't adding the r/w bit at the end of the transmitted address, causing this bit-shift.

After changing the 0x40 to 0x80 (and 0x81 for the read), it seems to be transmitting correct data.

[attila]

Hi @AdamN

The FDwfDigitalI2CRead/Write expects address in 8bit format, like it is in the examples:
#                                8bit address  
dwf.FDwfDigitalI2cWrite(hdwf, c_int(0x1D<<1), rgTX, c_int(16), byref(iNak)) # write 16 bytes