New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EMX i2c throws InvalidOperationException #164

Closed
rickmas opened this Issue Jan 27, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@rickmas

rickmas commented Jan 27, 2018

TinyCLR OS Version = 0.7.0

Running I2C sample code here http://docs.ghielectronics.com/tinyclr/tutorials/i2c.html
(using a different slave address of 0x7F)

gives

The thread '<No Name>' (0x2) has exited with code 0 (0x0).
    #### Exception System.InvalidOperationException - CLR_E_INVALID_OPERATION (1) ####
    #### Message: 
    #### GHIElectronics.TinyCLR.Devices.I2c.Provider.DefaultI2cControllerProvider::AcquireNative [IP: 0000] ####
    #### GHIElectronics.TinyCLR.Devices.I2c.Provider.DefaultI2cControllerProvider::GetDeviceProvider [IP: 0046] ####
    #### GHIElectronics.TinyCLR.Devices.I2c.I2cDevice::FromId [IP: 003a] ####
    #### Program::Main [IP: 0014] ####
Exception thrown: 'System.InvalidOperationException' in GHIElectronics.TinyCLR.Devices.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in GHIElectronics.TinyCLR.Devices.dll

while executing this line

var device = I2cDevice.FromId(FEZSpider.I2cBus.Socket4, settings);

Here's the complete code I'm trying run on my Fez Spider

using System;
using System.Threading;
using System.Diagnostics;
using GHIElectronics.TinyCLR.Pins;
using GHIElectronics.TinyCLR.Devices.I2c;

namespace TinyCLROSExperimentation
{
    class Program
    {
        static void Main()
        {
            var settings = new I2cConnectionSettings(0x7F)
            {
                BusSpeed = I2cBusSpeed.FastMode
            };
            var device = I2cDevice.FromId(FEZSpider.I2cBus.Socket4, settings);
        }
    }
}

Any advice on what's wrong?

@bauland

This comment has been minimized.

Contributor

bauland commented Jan 27, 2018

I think address is wrong as it seems to be a reserved address.
What is your i2c device ?

@rickmas

This comment has been minimized.

rickmas commented Jan 27, 2018

The device is a MulticolorLED which uses DaisyLink. I've read that TinyCLR doesn't support DaisyLink and won't going forward. However, I wanted to see if I could at least make use of one of these devices. I get the same exception without any attached device.

@bauland

This comment has been minimized.

Contributor

bauland commented Jan 27, 2018

I test your code on a FEZ Spider I and it is working (I don't connect anything on socket).

Try to rewrite firmware perhaps ?

@rickmas

This comment has been minimized.

rickmas commented Jan 27, 2018

OK, reloading the firmware was successful but still got same error. Then tried reloading firmware but first did an erase. Then ran the code and it worked successfully the first time. Ran the code again and it threw the same exception above. Confirmed the behavior by doing it again (reloaded firmware after erasing and then running the program. worked first time ok but second time got the exception).

Are you able to run the code a second time without an exception?

@bauland

This comment has been minimized.

Contributor

bauland commented Jan 28, 2018

You were right: second attempt to start app throw an exception. As I have only tried once, I didn't have any exception.

Perhaps resources aren't correctly free ?

@Palomino34

This comment has been minimized.

Contributor

Palomino34 commented Jan 29, 2018

Probably daisylink slave device need to be reset because virtual address is already set? How about disconnect power completely and don't run the code until press a button?

@Arke64 Arke64 added the bug label Jan 29, 2018

@Arke64 Arke64 added this to the v0.8.0 milestone Jan 29, 2018

@Arke64

This comment has been minimized.

Member

Arke64 commented Jan 29, 2018

@rickmas we were able to reproduce it but don't have a fix just yet. It is likely something in the "soft reset" functionality not releasing resources properly.

@Palomino34

This comment has been minimized.

Contributor

Palomino34 commented Jan 29, 2018

Using softwareI2C while waiting for the fix, if it is needed in your project.

@Arke64 Arke64 closed this in b2bf872 Jan 30, 2018

Arke64 added a commit that referenced this issue Jan 30, 2018

Merge pull request #166 from ghi-electronics/#164_Port_EMX_I2C_failed…
…_openSecondtime

#164 port emx i2 c failed open secondtime
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment