Can't talk over I2C with FEZ Cerberus

NETMF & Gadgeteer
1

Hi all, I’m completely new (and stuck) with what I feel should be a very simple task so I thought maybe somebody would have a quick fix or suggestion. I have a FEZ cerberus board (which I know is discontinued) but I’m making modifications to an older project which uses it.

Here’s the set up:
Socket 2= used to talk over USB (I send commands from a GUI on my computer)
Socket 8= used to deploy code (from VS 2013 using SDK 4.2) to the cerberus
Socket 5= used to communicate over SPI with motor chips

This has all been working well. But now, I want to talk over I2C with another chip. I used what seemed to be pretty simple code found here (I just copied the code from the “An I2C example” into a function that I call): https://www.ghielectronics.com/docs/12/i2c
but it keeps giving me the “Failed to perform I2C transaction” message. I then took a scope to socket 1 (since that is where I2C is available) and saw nothing on the signal pins (power pins were fine). Oddly enough, I did see signals coming from socket 6 (which doesn’t support I2C) on the scope. I know this signaling is coming from the I2C code and not my motor SPI code because the function I call only has the I2C code in it from the link above. I have attached two pics from the scope in case that is of interest. Note that in the zoomed out photo blue is pin 9 (I think clock) while yellow is pin 7 (I think data), but vice versa in the zoomed in photo since I swapped the probe channels (so yellow clock and blue data).

So I gave up and tried using the code from this link: How to use Gadgeteer Interfaces directly from your application | Microsoft Learn
Once again, I just put it in a function and called it. Except the GetSocket(int, true, null, null) function always throws an exception saying that the socket number is invalid (I’ve tried 0 to 100, all are invalid). So obviously this code doesn’t work for me.

In summary, I’m just trying to get a signal to come out of socket 1 since that is where it should be (and I’m already using socket 2 which is the only other socket with I2C). I can’t even get the simplest of examples to work and the only thing I can think of is that somehow when you set up the SPI comm it disallows I2C comm even though it’s on other sockets (which I highly doubt is true but I have no other ideas. The code is so simple and I just copied it)

Any help or advice as to what do do next is appreciated.
Thanks!

1 Like
2

Welcome. Hopefully you’ll get enough points from people coming along here and liking your post so you can post again soon (otherwise there’s a forced 24 hour wait as a spam-gate)

The problem is probably related to shared pins. I2C is a shared bus, and you have to ensure the pins are not used in other things - in the case of Socket 1 and Socket 2, the pins in question share the function of a UART, so I suspect your code is in conflict with itself. You’ll probably need to move the Socket 2 module over to Socket 6, and then try again.

But also, break the problem down; just write a test of I2C, because everyone (including chip manufacturers) messes up I2C addressing. If you still get failed transactions, check the address (show us a datasheet to get assistance there). If it works on it’s own, it’s the conflict.

1 Like
3

@ Brett - You were spot on Brett. The lines I was trying to use were shared between sockets 1 and 2, and moving the UART to socket 6 freed up socket 1 for I2C comm. I figured the sockets were independent but a quick look at the schematics would have shown they shared lines. Thanks for the help and the quick response!

One more quick question because I think you can probably answer it in 20 seconds. How does the cerberus pick which socket to use for I2C comm (or any communication that in enabled on more than on socket)? Right now it outputs on socket 1, but socket 2 also supports I2C. How would I use socket 2 instead of 1? The simple code:

I2CDevice.Configuration con = new I2CDevice.Configuration(address, clockrate);
I2CDevice MyI2C = new I2CDevice(con);

that I find in most examples doesn’t let you specify the socket or lines.

1 Like
4

there’s a secret there - I2C is a bus, and those pins are actually shared. So if you plug it in to socket 2, it’ll keep working as well :slight_smile: .