7 years, 2 months ago.

I have a suspicion on what's going on but can you try this first and see if I2C works?

I2C i2c(I2C_SDA,I2C_SCL);
 
//Ticker my_ticker; // ticker for interrupt
 
void read()
{   
     char data[7];
    data[0] = 0x10;
    i2c.write(0x70, data, 1, true);
    
}
 
 
int main()
{
    char data[7];
    data[0] = 0x51;
    i2c.write(0x50, data, 1, true);
 
    while(1){
    wait(1);read();
    }
}

6 years ago.

Is there any workaround to call i2c function periodically ticker like without ticker?

7 years, 2 months ago.

Seems you try to read from a device at slaveaddress 0x50 after selecting a specific register (0x51) in the slave's internal registerspace. You skip the stop condition in the register selection phase and then want to use the ticker to repeatedly read from that same registeraddress. In that case the I2C operation in the the ticker interrupt should be a read instead of a write operation and it should use the same slaveaddress. You now have:

..
i2c.write(0x70, data, 1, true);
..

The incorrect slave address may confuse the slave and hang the I2C bus..

That should probably be

..
i2c.read(0x50, data, 1, true);
..

Note that this could still cause problems when the slave auto-increments the registeraddress,

To make sure everything works as expected first try the complete read operation inside the Ticker.

I2C i2c(I2C_SDA,I2C_SCL);
 
Ticker my_ticker; // ticker for interrupt

void read() {   
   char data[7];
   data[0] = 0x51;
   i2c.write(0x50, data, 1, true);  // Set the registeraddress, repeated start

   i2c.read(0x50, data, 1); // Read from the register and issue stop condition
}

int main()
{
    my_ticker.attach(&read, 1);

    while(1){
       wait(1);
    }
}

6 years, 9 months ago.

I also have very similar problem with Lorenz Ruprecht. I use Nucleo F446RE instead. Sadly, i need i2c.read instead of i2c.write. Surely, It must be reported to github.

6 years, 9 months ago.

OK this isn't a researched answer but as I understand it the "ticker" class is an interrupt "wrapper" meaning that the callback takes place inside an interrupt. I2C operations are a bit slow for use in an interrupt, and raise the possibility of some interesting "collision" events. Personally I would advise setting a flag in the ticker and polling for it in the main program. That way the I2C is timed by the ticker but called from "main".

I'm going to clarify this and add that newer versions of the I2C library may have added "locks" for RTOS compatibility, meaning they MUST NOT BE CALLED FROM INTERRUPTS. Old examples that abuse interrupts will break with newer MBED builds.

6 years, 9 months ago.

My understanding of the problem is as follows; To get the variation of speed to the I2C timing MBED use Timers NOT the SYSTICK (which is separate from the general purpose timers) as you would expect. The Interrupt also uses the same timers broken down into small bite size timers to give the seconds delay and stack loading unloading ensues, hence I2C is not Interrupt safe but you can set a flag (i.e. service the Interrupt ultra-quick as Others have suggested) and then service the flag within main() and load/unload stack once per Interrupt. Hence we observe the issue both in the latest OS2 as well as OS5.4 Mutex locks are also used in i2c.cpp which shouldn't be used/permitted within an ISR

e.g. (This is not a complete listing but hopefully you get the idea....)

bool ISR_Flag=false;
int T_Temp,T_Press;
void isr(void);
void isr2(void);
int main()
{
    printf("Reading Pressure and Temperature from BMP180 Sensor\n\r");
 
    Ticker ticktock;
 
    ticktock.attach(&isr2, 2); //NB isr2 is just a flag setting and return. Whereas &isr WILL NOT WORK does all the I2C negotiating
 
    BMP180_Initialise();
        while(1)
        {
            if (ISR_Flag==true){isr();}
            //wait(1);
            //sleep();
        }
 
}
 
void isr(void){
            T_Temp=Temperature();
            float fTemp=(float)T_Temp/10;       //For the purpose of display divide by ten into a float
                     
            T_Press=Pressure();
            float fPress=(float)T_Press/100;    //For the purpose of display divide by hundred into a float
           
            printf("Temp: %0.1f DegC   Press: %4.1f mBar\r\n",fTemp,fPress);
 
            ISR_Flag=false;
}
 
void isr2(void){
      ISR_Flag=true;
}

6 years, 9 months ago.

Maybe this is been answered already, but the I2C component is not interrupt safe.

The I2C component takes locks to make it thread-safe, which of course should not be used in an ISR.

See https://docs.mbed.com/docs/mbed-os-handbook/en/latest/concepts/thread_safety/

Note carefully the definitions of interrupt-safe and thread-safe in this document.

This then begs the question how do we do precise timing with I2C devices?