Difference in I2C behaviour between 4.1 and 4.2?


the following code is working on NETMF 4.1 devices but not on 4.2 ones :

String Text = "Test string";

I2CDevice.I2CTransaction[] xActions = new I2CDevice.I2CTransaction[2];
xActions[0] = I2CDevice.CreateWriteTransaction(new byte[4] { 0, 3, y, x });
xActions[1] = I2CDevice.CreateWriteTransaction(System.Text.Encoding.UTF8.GetBytes((byte)0 + Text));
I2C.Execute(xActions, 1000);

To make it work in 4.2, I have to send two separate orders :

String Text = "Test string";

I2CDevice.I2CTransaction[] xActions = new I2CDevice.I2CTransaction[1];
xActions[0] = I2CDevice.CreateWriteTransaction(new byte[4] { 0, 3, y, x });
I2C.Execute(xActions, 1000);
xActions[0] = I2CDevice.CreateWriteTransaction(System.Text.Encoding.UTF8.GetBytes((byte)0 + Text));
I2C.Execute(xActions, 1000);

[em]Edit: clarified the following sentence…[/em]
The first code snippet writes “Test string” at position (x,y) on the LCD on 4.1 devices and it writes “st string” at the (x,y) position on 4.2 devices (Cerbuino, Cerb40).

I don’t know yet if it is a matter of NETMF version or processor speed (NETMF 4.1 are Panda/PandaII or Domino) and I2C timings, though.

Has anyone already seen this or has info about it ?

Which device? There are known issues with Hydra.

@ ianlee74 : I’ve just edited my post to clarify this a bit.

I’ve tested on Cerbuino and Cerb40 for NetMF 4.2 and on Domino, Panda and PandaII for NetMF 4.1

I haven’t tested on Hydra.

Did you test the same hardware in 4.1 and 4.2?

I suspect not; there’s no 4.1 in Cerb family and there’s no 4.2 in USBizi family…

I haven’t tested yet on the only device I have that supports both version : Cobra.
else :
[ul]USBizi : 4.1 only
Cerb-family : 4.2 only[/ul]


Just checked with Cobra : result is good on both NETMF versions.

Then it is not a 4.1 vs 4.2 problem :slight_smile: your cerbuino is not working with i2c.

How is your device connected to i2c pins and where?
Do you own a scope?

I’m not 100% sure it’s not 4.1 vs 4.2 problem :wink:

Indeed, the fact that Cobra is showing good results in both environments is a big point. But… what we know at the moment is :
[ul]4.1 only device ar working correctly
4.1 & 4.2 device(s ?) are working correctly
4.2 only devices are not working correctly[/ul]

The other big difference between 4.1 & 4.2 devices that I own is the processors’ speed. That’s why I also think at a problem with timings. This is only a supposition, nothing else.

I don’t have a scope to check this, though:(

About i2c “not working” on Cerbuino : yes, it’s working. Please re-read my first post here : it doesn’t work on it (and on Cerb40) if I send a bunch of 2 write transactions at once, but it’s working if I send them one by one.
So I’m confident in my cabling and in the i2c functionning of both Cerbuino and Cerb40. But maybe (maybe) there’s a flaw somewhere in the implementation that only appears now, either with 4.2 or with high-speed processors ?

Here are the results of some new tests with Hydra, Cerbuino and Cerb40, all of them with latest firmware and NETMF

[ul]Hydra : works fine :slight_smile:
Cerb40 and Cerbuino : does not work fine :frowning: [/ul]

I suspect the same (bad) results with Cerberus but I don’t have this board so I can’t check and say for sure.

Feels like something is fundamentally wrong with I2C in STM32 port.

Then it’s no longer in my abilities to go further

In this case, I have a fix so I can leave with it. But maybe this behaviour could be another manifestation of the same problems (bugs ?) encountered by [em]ianlee74[/em] and [em]dobova[/em] with the IO60P16 board ?

@ Bec a fuel, we have to differentiate between hardware i2c and software i2c. For what we discover:

  • On cerberus hardware i2c is working, software i2c is working and mostly no problem.
  • On hydra software i2c partially works (not for io60p16) and is not reliable in very heavy traffic. Hardware i2c works, but only if you use .netmf class avoiding gadgeteer wrapper.
    There are also differences between ethernet firmware and no ethernet fw.

For all I say below, it’s related to hardware i2c only. I haven’t checked with software i2c and don’t even want to try…

Regarding the issue in this thread, it is not working as it should. But I admit it’s not a big issue in this particular case (because I have a fix).
What I think, though, is that it could be the tip of the iceberg, the big part being potentially a bug in the STM32 port, as Architect said.

In all my tests, I’ve only used NetMF. By design, in fact, because my module can’t be a type “I” module in the Gadgeteer world.

I’ve only used non-ethernet firmware. I will try ethernet firmware this evening and come back with results.

Did you or ianlee74 try with the latest firmware(s) and NetMF ? I know you’re not newbies, but the spectacular result in my case for the Hydra makes me think it should be worth a try :wink:

@ Bec a Fuel - I think we used many firmware on the way, but exactly I don’t remember if we get until the last.

It can be, but if I remember correctly, the driver for IO60P16 was working fine on cerberus with multibyte transactions (I tested until 24 byte reading). I will do a fast check.

The last tests I did were based on the currently available firmware (QFE2).

@ ianlee74 & @ dobova : I was quite sure you already did the tests, but one never knows :wink:

I’ve just checked with the Ethernet firmware and here are the results :
[ul]Hydra : works fine
Cerberus : “unknown USB device” :frowning: (with or without ENC28 module plugged in)
Cerb40 : no change, still has the bug[/ul]

Except for the Cerbuino, there doesn’t seem to be any difference about i2c. But nevermind, it doesn’t seem to worry anyone else but us three.
Since I have a workaround, I won’t annoy anyone else with this anymore

Last thing :

The following code is working fine :

xActions[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0, 12, 0, 19, 0, 4, 0, 3, 2, 2 });
I2C.Execute(xActions, 1000);

but this one is not working :

xActions[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0, 12 });
xActions[1] = I2CDevice.CreateWriteTransaction(new byte[] { 0, 19 });
xActions[2] = I2CDevice.CreateWriteTransaction(new byte[] { 0, 4 });
xActions[3] = I2CDevice.CreateWriteTransaction(new byte[] { 0, 3, 2, 2 });
I2C.Execute(xActions, 1000);

I mean on Cerb-family devices. On Hydra and 4.1 devices, both snippets are working correctly.