I2C gibberish

Hardware MKR Family MKRGSM1400
1

So learning to use this MKR board has been ummm... "interesting". My latest concern is I2C, which is giving me all sorts of odd data.

Just using the "master-writer" built-in example, I get this period of gibberish, which looks like it's trying to write to some device with ID "6B", but then there are ACK's in there, which tell me that it has to be something stray rather than intentional. I added a delay after "Wire.begin()", and the gibberish is as long as the delay I put in. In this pic, the gibberish is between the 2 markers A1 and A2.

Is this really doing something intentional here, such as perhaps looking for an I2C bootload device?
And how do I turn this off?

1920×1080 270 KB

This is the code I'm using...

#include <Wire.h>

void setup()
{
  Wire.begin(); // join i2c bus (address optional for master)
  delay(3000);        // Gibberish on I2C occurs as long as this delay
}

byte x = 0;

void loop()
{
  Wire.beginTransmission(4); // transmit to device #4
  Wire.write("x is ");        // sends five bytes
  Wire.write(x);              // sends one byte  
  Wire.endTransmission();    // stop transmitting

  x++;
  delay(500);
}
2

Hi neilster,

I tested your code on my custom SAMD21 board with a standard Arduino Zero bootloader, but didn't find any I2C traffic on start up.

However, digging a little deeper and looking at the MKR GSM1400 bootloader definition file, it contains some PMIC (Power Management Integrated Circuit) definitions that include the I2C pins. These definitions are not present in the standard Arduino Zero bootloader.

It turns out that the I2C traffic you're seeing on start up, is the bootloader configuring the board's BQ24195L, I2C Controlled 2.5A/4.5A Single Cell Charger, whose I2C address also happens to be 0x6B.

3

Oooh... nice find Martin.
What's interesting, is that these extra I2C messages are as long as I allow between Wire.begin() and Wire.beginTransmission(), which seems really odd to me.

I'm going to try adding Wire.beginTransmission() and Wire.endTransmission() to see if that ends those messages and frees up the bus.

Thanks,
-Neil.

4

So yes, once I do a Wire.beginTransmission() and Wire.endTransmission(), those 0x6B messages stop. But they still get a bunch of these messages in during that time. Technically, my other I2C device (0x21 for configuring a camera) should just ignore these, but seems to be getting messed up because of these. I will focus on fixing the camera for now.