I2C errors when display is connected

[skipfire]

I have recreated this with multiple PIs, displays, and devices so I can rule out individual hardware as an issue. I am finding that when I have the display and another device connected to I2C that the second device gets lots of errors (intermittent but frequent) that it cannot find the I2C device. I've been working with Si7021 temp sensor and an Si470x radio unit. With both projects I want to be able to dim the display as well as use the extra component. With the temp sensor I have error code handling the dropouts and just skipping that read session and using the last successful value, but with the radio it means missed commands to change station or volume, missed incoming RDS data, etc. I have been able to hook up both the temperature and the radio units together and not get errors, so it is not a 2-device issue.

Is there a way to make the I2C on the display more cooperative, or is it just going to continuously cause errors?

I am using Windows 10 IoT if that make any difference.

[skipfire]

To clarify further, I do not even have to have code connecting to the display's I2C, just having the display physically connected is enough to cause the problems.

[gsh]

Which I2C port are you using? Are you definitely using i2c_arm ?

[6by9]

To expand on gsh's response, the firmware will be polling the touchscreen using i2c_vc (normally i2c0).

If you're using i2c0 on GPIOs 27&28 of the 40 pin header then you have a conflict and will get issues. You can disable the touchscreen polling by adding "disable_touchscreen=1" to /boot/config.txt, and then the GPU won't touch i2c0 again after the boot time initialisation of the screen (assuming you're not using the camera either).

Use of i2c_arm (usually i2c1) should be totally independent of the display.

[skipfire]

I am using I2C1 (pins 3 and 5) on a Raspberry Pi 3.

[6by9]

I am using I2C1 (pins 3 and 5) on a Raspberry Pi 3.

That should be totally independent then, and it certainly would be on Linux.
I wonder if Microsoft have done something dodgy in their I2C driver and are trying to service both controllers when they shouldn't be. It'd be worth trying "disable_touchscreen=1" and see if it helps. If it does then it'd be worth taking it across to the Microsoft forums as they provide all the support for Win10 IOT.

I assume you have only got the ribbon cable and power connected between the Pi and display controller. The links on to the SDA and SCL pins of the controller board are only needed on the original model A & B which didn't have I2C up the ribbon cable. Unfortunately some installation guides incorrectly show wiring those up to GPIOs 3&5 on all models

[skipfire]

On the Raspberry Pi 3 the extra pins are still required to control interface with the touchscreen if you want to control features such as brightness. So I have the 5v, Gnd, SDA, and SCL pins connected plus the ribbon. WIthout the SDA and SCL pins, trying to control the touchscreen will result in an address not found error.

[6by9]

On the Raspberry Pi 3 the extra pins are still required to control interface with the touchscreen if you want to control features such as brightness. So I have the 5v, Gnd, SDA, and SCL pins connected plus the ribbon. WIthout the SDA and SCL pins, trying to control the touchscreen will result in an address not found error.

In which case Microsoft have done things very differently to the way it has been done in Linux and you're at their mercy.
Under Linux the VideoCore GPU sets up the display and polls it for touchscreen events. Linux then uses a mailbox service talking to the GPU to control the brightness and get touchscreen events. It only needs the I2C up the ribbon cable.

What you are almost certainly seeing is collisions as you have connected the 2 I2C busses together, and the GPU is polling the touchscreen at the same moment that you try to talk to your sensors.
You may be lucky in that adding "disable_touchscreen=1" will stop the GPU polling the touchscreen, but otherwise you need to be asking on the Windows forums. There's nothing Pi Towers can do about it.

[6by9]

It looks like the second answer on https://social.msdn.microsoft.com/Forum ... WindowsIoT may be of help to you
There is an implementation of the mailbox service, so you can make your own calls to the GPU to adjust the brightness and then disconnect i2c1 from the display.

[skipfire]

Thanks for the responses. Unfortunately the Windows IoT forums push down the path of using device 0x45 on I2C1 and the mailbox implementation right now is only C without a C# implementation, and reviewing it I have doubts that I can make it work in C#.

At the very least I have a better idea of what I need to be watching for, thanks.