Using both I2C lines on STM32F103C8 results in NACKs after some time.

[TByte007]

I'm using the I2C on PB6/PB7 for communicating with another controller - ESP8266 as master and STM32F103C8 as slave and the I2C on PB10/PB11 as master to communicate with sensors. But after a while (random) the ESP8266 receives only Wire error "2:received NACK on transmit of address" on Wire.endTransmission() until I reset the F103C8. I'm guessing there it's some kind of interrupt race condition happening but I thought that the controller should be able to manage both I2C without interference ? If I disable the second I2C (PB10/11) everything works forever but I want the sensors :)

PS1: May be mask I2C1 interrupt vector when communicating on I2C2 - could that be a
part of the Wire library ?

PS2: This made it work with frequent errors to the master but at least the F103C8 doesn't die horribly :)

    Wire.end();
    err = compass.read();
    Wire.begin(I2C_DRIVEMOD);         // join i2c bus
    Wire.onRequest(requestEvent); // register event
    Wire.onReceive(receiveEvent); // register event

Of course that is insane way of doing it and it's crazy slow - I'm sure there should be a better way of using both I2C lines :)

PS3: I found the same problem described on the STM's site and it doesn't seem like anybody from STM cared to reply for a year ...

https://community.st.com/s/question/0D50X00009yHD6SSAW/issue-when-using-i2c1-and-i2c2-simultaneously-with-stm32cubefwf0v190

[fpistm]

Hi @TByte007
In fact the error raised by the ESP (2) is not linked to NACK.
We are currently working on error management of I2C which is not aligned with Arduino. Currently, -2 is Timeout error.

1. As each instance has the same IRQ priority this should not be an issue
2. Wait the fix about error management
3. IIRW the STM32F103 errata sheet talk about issue with both I2C usage. I will have to check.

[TByte007]

Do you have any idea how quick can that be fixed ? Because if it takes too long I might temporary switch to serial communication for testing. The problem is that the ESP controller should communicate with multiple STMs (2-3) and the serial communication is only p2p.

[fpistm]

This will come soon (in the coming weeks) but I could not guarantee that it will correct the problem.

[TByte007]

Is there somebody you can ask (hardware engineer ?) what is the problem and why people can't use both I2C lines at the same time. I mean is it an SDK/HAL problem or a hardware problem so we should look for other chips ? Because that is a real show stopper. Or it will require extra hardware which wasn't calculated initially.

[uzi18]

this is not a solution but esp has no hardware i2c, so best to use it as master

[TByte007]

this is not a solution but esp has no hardware i2c, so best to use it as master

Yes - the ESP is a master. It basically gives commands to the STMs which come from the WiFi and reads and reports its status back over WiFi.

[fpistm]

I never told you can't use bot I2C at the same time. I've just told we have identified an issue about error management.
Morevover, it can be linked to your implementation so please give more precision.
Wiring? Which sensors? sketches?...

[TByte007]

I never told you can't use bot I2C at the same time. I've just told we have identified an issue about error management.
Morevover, it can be linked to your implementation so please give more precision.
Wiring? Which sensors? sketches?...

I will try to make a minimum sketch that fails because the current one has too many lines. Although everything works if I only use one I2C no matter if it is the line to ESP or to the sensor (basically forever). The sensor is QMC5883LC board which has it's own pullups.

[TByte007]

It's basically ESP -> STM -> QMC5883L. There is nothing else connected now. It works for sometime and then keeps repeating error 2. After the link to the ESP dies the link to QMC5883L still works I can see that the azimuth changes on the STM's serial output. If I reset the STM everything works again. I dont have to reset the ESP - it always works.
PS1: Did a test - requested azimuth every 30 min and it worked for 3 hours. The moment I started requesting the azimuth every 250ms and the STM stopped responding after 4-5 sec.

#include <Wire.h>
#include <QMC5883LCompass.h>

#include "InterMCU.h"

#define DEBUG 1

const int16_t I2C_DRIVEMOD = 0x02;

byte i2c_req = 0;
// SDA STM32 PB7 -> ESP8266 D2 (4)
// SCL STM32 PB6 -> ESP8266 D1 (5)

QMC5883LCompass compass;
TwoWire Wire2(PB11, PB10); // SCL - PB10, SDA - PB11

#ifdef DEBUG
u_long imalive = 0;
byte __i2c_cmd = 0;
#endif

int __last_status = STATUS_OK;

int     cazimuth = 0; // current azimuth
u_long  next_get_azimuth = 0;

void setup() {
#ifdef DEBUG
  Serial.begin(74880);           // start serial for output
//  Serial.begin(9600);           // start serial for output
#endif
/* */
  pinMode(LED_BUILTIN, OUTPUT);


//  Wire.setSCL(PB10);
//  Wire.setSDA(PB11);
  Wire.begin(I2C_DRIVEMOD);         // join i2c bus
  Wire.onRequest(requestEvent); // register event
  Wire.onReceive(receiveEvent); // register event

  Wire2.begin();
  compass.init(Wire2);
  compass.setSmoothing(3, true); // Test that
}

void loop() {
 u_long cms = millis();
 int err = 0;

#ifdef DEBUG
  if(cms > imalive) {
    Serial.print("i2c: "); Serial.print(__i2c_cmd);
    Serial.print(", az: "); Serial.print(cazimuth);
    Serial.println();
    imalive = cms + 1000;
  }
#endif

// ============= Get the Azimuth ===========
  if(cms >= next_get_azimuth) {
    err = compass.read();
    if(err) { // I2C error check
      cazimuth = -err; // negative I2C error
    } else {
      cazimuth = compass.getAzimuth();
      next_get_azimuth = cms + 10; // Every 10ms
    }
  }
}

u_int read_from_iic(byte *buf, size_t bufsize) {
  size_t rval = Wire.readBytes(buf, bufsize);
  if(rval == bufsize)
    return 0;
  else {
    __last_status = ERR_I2C_READ;
    return rval; // return bytes read
  }
}

void receiveEvent(__attribute__((unused)) int howMany) { // unused for now
  while(Wire.available()) {
    __last_status = STATUS_OK;
    byte cmd = Wire.read();

#ifdef DEBUG
    __i2c_cmd = cmd;
#endif
    if(cmd >= GET_CMD_BEGIN && cmd <= GET_CMD_END) {
      i2c_req = cmd;
      return;
    }
  }
}

void requestEvent() {
  switch(i2c_req) {
    case CMD_GET_AZIMUTH: Wire.write((char*)&cazimuth, sizeof(cazimuth)); break;
  }
  i2c_req = 0;
}

[TByte007]

I just received my logic analyzer and this is what I see. SCL is D0 and SDA is D1.
This is when it works:

And this is when it fails:

I dont have experience with wire level i2c debug to know why it fails. I can do more tests if you want me to.
For now I was using an interrupt from the ESP to the STM to reset the i2c line but that dont work for higher speed communication and that halts my project.

[TByte007]

@fpistm What I noticed is that if I disconnect the magnetometer from the other line (PB10/PB11) the STM (I guess) pulls the SCL line down on the OTHER I2C line on PB6/PB7 (why?) and it NEVER recovers until i reset the line with Wire.end()/Wire.begin(). Then it works until the next attempt to read from the PB10/PB11. If I dont attempt to read from the magnetometer (//err = compass.read();) the other i2c line never dies (SCL is never permanently pulled down).

[fpistm]

@TByte007
I'm currently working on the I2C to fix repeated start and errors management.
I've almost finished and doing several test.
I've set up something similar than you:
A Nucleo F103RB acting as master on the I2C1 of the BP.
And The BP as master on I2C2 to read temperature.
I use the example: master_reader_writer on the Nucleo F103RB and the slave_sender_receiver on the BP.
I've updated the slave_sender_receiver to read on I2C2 the temperature and send the temperature value to I2C1 master on request.
This works fine
Edit: after a while seems I2C1 line is broken, so I'm able to reproduce.
Edit2: Working Fine, having a wiring issue.

Wire Master Reader Writer / Wire Slave Sender Receiver

Wire Master Reader Writer on NucleoF103RB

/* Wire Master Reader Writer
by Wi6Labs

Demonstrates use of the Wire library.
Reads/writes data from/to an I2C/TWI slave device.
Refer to the "Wire Slave Sender Receiver" example for use with this.

Created 27 June 2017
Updated 14 August 2017
  - this example is now common to all STM32 boards

This example code is in the public domain.
*/

#include <Wire.h>

#define I2C_ADDR  2

byte x = 0;

void setup()
{
  Wire.begin();        // join i2c bus (address optional for master)
  Serial.begin(9600);  // start serial for output
  Serial.println("Master reader writer");              // print the character

}

void loop()
{
  Wire.requestFrom(I2C_ADDR, 6);  // request 6 bytes from slave device

  while(Wire.available())         // slave may send less than requested
  {
    char c = Wire.read();         // receive a byte as character
    Serial.print(c);              // print the character
  }

  delay(10);

  Wire.beginTransmission(I2C_ADDR); // transmit to device
  Wire.write("x is ");              // sends five bytes
  Wire.write(x);                    // sends one byte
  Wire.endTransmission();           // stop transmitting
  x++;

  delay(500);
}

Wire Slave Sender Receiver on BP

/* Wire Slave Receiver
by Wi6Labs

Demonstrates use of the Wire library.
Receives/sends data as an I2C/TWI slave device.
Refer to the "Wire Master Reader Writer" example for use with this.

Created 27 June 2017
Updated 14 August 2017
  - this example is now common to all STM32 boards

This example code is in the public domain.
*/

#include <Wire.h>
#include <M2M_LM75A.h>

#define I2C_ADDR  2

M2M_LM75A lm75a;
TwoWire Wire2(PB7, PB6); // SCL - PB10, SDA - PB11
volatile float temp;
char sout[8];

void setup()
{
  Wire.setSDA(PB11);
  Wire.setSCL(PB10);

  Wire2.begin(I2C_ADDR);         // join i2c bus with address #4
  Wire2.onRequest(requestEvent); // register event
  Wire2.onReceive(receiveEvent); // register event
  lm75a.begin();
  Serial.begin(9600);           // start serial for output
  Serial.println("Slave sender receiver start");          // print the integer

}

void loop()
{
  //empty loop
  Serial.print(F("Temperature in Celsius: "));
  temp = lm75a.getTemperature();
  dtostrf(temp, 5, 2, sout);
  sout[5] = '\n';
  sout[6] = 0;
  Serial.print(temp);
  Serial.println(F(" *C"));

  Serial.print(F("Hysteris temperature: "));
  Serial.print(lm75a.getHysterisisTemperature());
  Serial.println(F(" *C"));

  Serial.print(F("OS trip temperature: "));
  Serial.print(lm75a.getOSTripTemperature());
  Serial.println(F(" *C"));
  delay(500);
}

// function that executes whenever data is received from master
// this function is registered as an event, see setup()
void receiveEvent(int howMany)
{
  UNUSED(howMany);
  while(1 < Wire2.available()) // loop through all but the last
  {
    char c = Wire2.read();     // receive byte as a character
    Serial.print(c);          // print the character
  }
  int x = Wire2.read();        // receive byte as an integer
  Serial.println(x);          // print the integer
}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent()
{
  //Wire.write("hello\n");  // respond with message of 6 bytes
                          // as expected by master
  Wire2.write(sout);  // respond with message of 6 bytes
                          // as expected by master
}

[TByte007]

lm75a

You wait too long - 500ms. That will save you (to some extent) from both I2C lines interfering with each other. That one time that the i2c died could have been that rare interference and not the cabling I guess :) . Try doing the same thing but with 10ms delay (I read them mag every 10ms). And I access the STM via the other line every about 250ms. The more frequently I do it the faster it dies.

PS: Try disconnecting the temperature sensor too but dont remove the access attempt (lm75a.getTemperature(); ) . In my case that kills the other I2C pretty much immediately.

[joej970]

@TByte007
How did you disable other I2C ports?
In my project I have MPU9250 on PB6/7 and after some random time (2 mins) Blue Pill does not read the MPU anymore. I do not need other i2c ports so disabling them would fix a problem for me. Hopefully.

What SCK speed do you use? Increasing clock to 400kHz results in a crash even faster, after several seconds. And I read data every 100 ms.