Arduino as I2C Slave returns sometimes 0 bytes instead of 4.

system · June 16, 2013, 8:36am

Hi,

I have an Arduino as I2C Slave which returns 4 byte after a request from the Master.
However sometimes 0 bytes are received by the Master.

I run into this problem with an ATmega8L as Slave, but the same problem happens with a Arduino Uno as Slave. A Mega 2560 is the Master with onboard pull-up resistors of 10k.
The Slave acts as a sensor, with a (simulated) register address that has to be set first.

Changing the pull-up resistors from 10k to 2k doesn't change anything.
Adding 470pF to SDA or SCL doesn't change it.
Adding more decoupling capacitors or different ground paths makes no difference.
Using a ATmegaL at 8MHz makes it worse.
Using 5V or 3.3V (with level shifter) for that ATMegaL doesn't make a difference.

The problem gets a lot worse if don't release the bus after the (simulated) register address is set.
Wire.endTransmission(); -> 1 in 50 to 1 in 1000 is wrong.
Wire.endTransmission(false); -> they are all wrong !

Code for Master
(the Master has 'avail' being zero, no other errors)

// TEST_i2c_Master
// Arduino 1.0.5

#include <Wire.h>

int good = 0;

void setup()
{
  Serial.begin( 9600);
  Serial.println( "Start");
  
  Wire.begin();
}  

void loop() 
{
  Wire.beginTransmission( 0x2B);
  Wire.write( 0x11); // for the (simulated) register address.
  byte error = Wire.endTransmission(false); // hold bus
  if( error != 0)
  {
    Serial.print("endTransmission error = ");
    Serial.println( error);
  }
  else
  {
    Wire.requestFrom( 0x2B, 4, true);  // release bus after this
    byte avail = Wire.available();
    if( avail != 4)
    {
      Serial.print( "avail = ");
      Serial.println( avail);
      Serial.print( "good = ");
      Serial.println( good);
      good = 0;
    }
    else
    {
      char buffer[10];
      buffer[0] = Wire.read();
      buffer[1] = Wire.read();
      buffer[2] = Wire.read();
      buffer[3] = Wire.read();
      if( buffer[0] != 'A' || buffer[1] != 'B' || buffer[2] != 'C' || buffer[3] != 'D')
      {
        Serial.print( "data : ");
        buffer[4] = '\0';
        Serial.println( buffer);
      }
      else
      {
        good++;
      }
    }
  }
  delay( random( 2, 1500));
}

Code for Slave
(the Slave does not detect an error)

// TEST_i2c_Slave
// Arduino 1.0.5

#include <Wire.h>

volatile byte error = 0;

void setup()
{
  Serial.begin( 9600);
  pinMode( 13, OUTPUT);
  
  Wire.begin( 0x2B);

  Wire.onReceive( receiveEvent);
  Wire.onRequest( requestEvent);
}  

void loop() 
{
  if( error != 0)
  {
    digitalWrite( 13, HIGH);
    Serial.print("error = ");
    Serial.println( error);
    error = 0;
  }
}

void receiveEvent( int howMany)
{
  if( howMany != 1)
  {
    error = 100; 
    digitalWrite( 13, HIGH);
  }
  
  Wire.read(); // read the (simulated) register address
}

void requestEvent( void)
{
  byte n;
  
  n = Wire.write( (const byte *) "ABCD", 4);
  if( n != 4)
  {
    error = 110;
    digitalWrite( 13, HIGH);
  }
}

UPDATE 1: I completely rewrote this post, since I was able to replicate it with normal Arduino boards.
Notified this as a bug, Bug in Wire library with Master-Receiver and Slave-Transmitter. - Suggestions for the Arduino Project - Arduino Forum

UPDATE 2: This fixes the problem with the "Wire.endTransmission(false);" causing it to fail always.

github.com/arduino/Arduino

Wire Library doesn't handle Repeated START commands in I2C slave mode [imported]

opened 06:53PM - 15 Nov 12 UTC

closed 02:03PM - 06 Oct 15 UTC

cmaglie

Library: Wire

This is [Issue 848](http://code.google.com/p/arduino/issues/detail?id=848) moved… from a Google Code project. Added by 2012-03-07T03:05:19.000Z by [natew...@gmail.com](http://code.google.com/u/116340569797703823875/). Please review that bug for more context and additional comments, but update this bug. Original labels: Type-Defect, Priority-Medium ### Original description **What steps will reproduce the problem?** 1.Create a Slave I2C device (Wire.begin(0xCA >> 1)). 2.On the I2C master, send a request that contains a repeated START command 3.Verify that the Arduino does not respond to the second request Using the BusPirate, to generate a read request the following commands are given to write to the I2C slave to specify the register to read, followed by the actual read request. Let's assume the 'Read' register is 0x00. [OxCA 0x00 [0xCB rr] English description of the above. The start command [ is given, and we are writing to the device (LSB addres bit is 0, and the data we are writing is '0x00', the register we intend on reading. After writing to the register, in order to do an atomic transaction to indicate we want to read from this register, the master creates another START request [. This time, the request is a read (address LSB bit is now 1) and we are requesting two bytes. **What is the expected output? What do you see instead?** In the Arduino, the Wire.onReceive() callback is called correctly for the write, but due to addition of twi_stop() in the TW_SR_STOP case of the interrupt service routine, the master times waiting for the slave. Note, sending a STOP bit is not a valid response in the two-wire protocol per the Atmel documentation (see page 237 of the Atmel documentation in the two-wire section for case 0xA0{TW_SR_STOP}). The slave code should never be sending a STOP bit. Inferring the original intent of the author from the provided comment, if the desire was to support clock stretching, the way to do that is to NOT clear the TWINT flag until the callback completes. This is what the original code did, and the new code would do in twi_busRlease() if the two_stop() method and comment is removed. **What version of the Arduino software are you using? On what operating** **system? Which Arduino board are you using?** Arduino 1.0 software on OS/X, using multiple Arduino UNO boards. Tests were done using a BusPirate (http://dangerousprototypes.com/category/bus-pirate/) as well as a National Instruments cRIO, both running as an I2C master attempting to do atomic reads of a register address on an I2C slave. The code follows the same patterns as used in most I2C drivers, including those in LeJOS (http://www.lejos.org). Using both, I verified the incorrect behavior with the stock 1.0 Arudino Wire library (really, the twi.c ISR), and with the two_stop() method removed, the Arduino responded correctly when requested from the two separate I2C masters. **Please provide any additional information below.** See comment from both wallclimber1 and HelenaRobotics (myself). https://github.com/arduino/Arduino/commit/7392f8514de9d68659c744fb956c089f7b3932ef#libraries/Wire/utility/twi.c

The timing problem that occurs only now and then (and more with 8MHz I2C slave) still exists. The bug notified on Github:

github.com/arduino/Arduino

I2C/Wire library: Timing issue between Master-receiver and Slave-transmitter

opened 11:13PM - 20 Jun 13 UTC

closed 02:39PM - 22 Oct 15 UTC

ghost

Component: Core Type: Bug Library: Wire

This happens only with an Arduino as I2C Slave (connected to an Arduino as I2C M…aster). If the Master requests a few byte with Wire.requestFrom(), and the Slave writes a few bytes in the onRequest handler, the Master sometimes gets 0 bytes. Arduino version 1.0.5 This issue came in view with a slave at 8Mhz. With two 16MHz Arduino boards, this problem still occurs at an average of 1 in 100 times. With other boards it could happen only 1 in 1000 times, but also all the time. A workaround seems to be a "delay(1)" between the "Wire.endTransmission()" and the "Wire.requestFrom()" in the Master. The Wire.endTransmission is part of writing the (virtual) registers address to the Slave, since I programmed the Slave to act like a sensor or memory chip. After some testing I found that 6 micro seconds delay was enough. I have made a test sketch and more explanation here, http://forum.arduino.cc/index.php?topic=172296.0

UPDATE 3: The sketch above has been tested on Teensy 2.0 (ATmega32U4) and Teensy 3.0 (MK20DX128 ARM chip). The problem when using the repeated start with "Wire.endTransmission(false);" also exists in the library for Teensy 2.0, but without it there is no error at all. Teensy 3.0 runs also without that error.
I don't know what to think of it: I have always an error within a number of minutes, but the Teensy 2.0 with avr chip doesn't have them.

pjrc · June 23, 2013, 12:26pm

I modified your code slightly, to print the number of times the test passed and the number of times failed.

It's been running on a pair of Teensy 2.0 boards for many hours, currently up to this:

good response, ok=101325, err=0

// TEST_i2c_Master
// Arduino 1.0.5
// http://forum.arduino.cc/index.php?topic=172296.0

#include <Wire.h>

void setup()
{
Serial.begin(9600);
Serial.println("Start");
Wire.begin();
}

unsigned long okcount=0, errcount=0;

void loop()
{
Wire.beginTransmission(0x2B);
Wire.write(0x11); // for the (simulated) register address.

//byte error = Wire.endTransmission(false); // hold bus (errors)
byte error = Wire.endTransmission(); // release bus (works)

if( error != 0) {
Serial.print("endTransmission error = ");
Serial.print(error);
errcount++;
} else {
Wire.requestFrom( 0x2B, 4, true); // release bus after this
byte avail = Wire.available();
if (avail != 4) {
Serial.print("avail = ");
Serial.print( avail);
errcount++;
} else {
char buffer[10];
buffer[0] = Wire.read();
buffer[1] = Wire.read();
buffer[2] = Wire.read();
buffer[3] = Wire.read();
if( buffer[0] != 'A' || buffer[1] != 'B' || buffer[2] != 'C' || buffer[3] != 'D') {
Serial.print("bad data : ");
buffer[4] = '\0';
Serial.print(buffer);
errcount++;
} else {
Serial.print("good response");
okcount++;
}
}
}
Serial.print(", ok=");
Serial.print(okcount);
Serial.print(", err=");
Serial.print(errcount);
Serial.println();
delay(random( 2, 1500));
}

and...

// TEST_i2c_Slave
// Arduino 1.0.5
// http://forum.arduino.cc/index.php?topic=172296.0

#include <Wire.h>

volatile byte error = 0;

const int led = LED_BUILTIN;

void setup()
{
Serial.begin( 9600);
pinMode(led, OUTPUT);

Wire.begin(0x2B);

Wire.onReceive(receiveEvent);
Wire.onRequest(requestEvent);
}

void loop()
{
if (error != 0) {
digitalWrite(led, HIGH);
Serial.print("error = ");
Serial.println( error);
error = 0;
}
}

void receiveEvent( int howMany)
{
if (howMany != 1) {
error = 100;
digitalWrite(led, HIGH);
}

Wire.read(); // read the (simulated) register address
}

void requestEvent( void)
{
byte n;

n = Wire.write((const byte *)"ABCD", 4);
if (n != 4) {
error = 110;
digitalWrite(led, HIGH);
}
}

pjrc · June 23, 2013, 1:06pm

I hooked up a couple official Arduino boards. The slave code is running on a Mega 2560 and the master is running on an Uno R1.

So far, it's looking like no errors:

good response, ok=524, err=0

EDIT: looks like the Mega2560 & Uno are having occasional problems....

good response, ok=1253, err=2
good response, ok=1254, err=2
good response, ok=1255, err=2
avail = 0, ok=1255, err=3
good response, ok=1256, err=3
good response, ok=1257, err=3
good response, ok=1258, err=3

system · June 23, 2013, 4:35pm

Thanks for your time and effort.

What you found is the problem: 'avail' being zero.

I had made changes to the I2C library, so I downloaded a fresh 1.0.5 and used your sketches with Mega 2560 (R1 or R2) as Slave and Uno (R1 or R2) as Master.
Would you believe it, the error occurs all the time! Only 1 in 100 was good.

I added a delay in the Master between Wire.endtransmission() and Wire.requestFrom(). That seems to solve the problem.

  byte error = Wire.endTransmission(); // release bus (works)
  delay(1);              // --->  seems to fix timing problem
  ...

Instead of that "delay(1);", I tried changing the delay at the bottom of the loop to "delay(random( 200, 1500));", that did not fix the problem.

I don't understand the Wire library very well, but at least this is a workaround. I will add this to my bug report on Github, I2C/Wire library: Timing issue between Master-receiver and Slave-transmitter · Issue #1477 · arduino/Arduino · GitHub

To find the minimal delay, I reduced the sketch and found that about 6 microseconds is enough with a 16MHz Master and 16MHz Slave.
According to the timing info by Nick Gammon ( http://gammon.com.au/interrupts ), one or two interrupt service routines could be executed in 6 microseconds.

...
Wire.endTransmission();      // release bus (works)
delayMicroseconds( 6);        // seems to fix the timing problem.
Wire.requestFrom( 0x2B, 4, true);  // release bus after this
...

pjrc · June 23, 2013, 7:39pm

I added a 10us delay and ran it on the 2 Arduino boards. So far, 2885 tests with no errors.

pjrc · June 23, 2013, 7:43pm

It's strange that your boards showed so many errors. On these two Arduino boards, it seems to be about 1 error in every 300 to 400 tests.

I can't get the error to happen on any Teensy board, even the AVR ones. But Teensy2 does have a much more efficient timer0 interrupt for millis() and the USB communication doesn't interrupt the CPU for every byte like Arduino Uno's hardware serial does. Since adding a small delay makes this work on Arduino, it seems doubly strange the problem never happens on Teensy2 where interrupts aren't taking as much CPU time.

Hopefully someone will investigate and truly get to the bottom of what's going on here?

system · June 23, 2013, 8:02pm

Yes, let's hope so.
I'm not investigating it further. I just use the delay.
Thanks for all you help.

I have this also without use of the Serial library and without USB connection.
I made the system led turn on (in the Master and in the Slave) if that error occurs, to be able to run it without my computer.
Perhaps that optimization for timer0 has effect on this.

Is this the file for millis ? The normal Arduino library seems the same for the Arduino Uno and Arduino Leonardo.
https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring.c

This came to my mind: The functions endTransmission() and requestFrom() need time for the parameters and stack and so. Suppose there will be a total time of 4us for that. With de delay of 6us, the total between the 'real' action is 10us. That is remarkable, since 10us is a clock pulse of the I2C at 100kHz.

system · July 4, 2013, 3:07am

UPDATE 1: I completely rewrote this post, since I was able to replicate it with normal Arduino boards.
Notified this as a bug, Bug in Wire library with Master-Receiver and Slave-Transmitter. - Suggestions for the Arduino Project - Arduino Forum

It's not a bug per se but an aspect of the hardware for the Atmega 328. Per the datasheet on page 326, there is a parameter called tBUF which is the Bus free time between a STOP and START condition and is spec'd at 4.7us for 100kHz bus speed and 1.3us for bus speeds above 100kHz. It works very well using the repeated start instead, but you need to modify the Wire library on the slave device to handle the repeated starts.

system · July 4, 2013, 9:36am

With a 'fixed' library (commented out the line for the stop) I still had that problem.
Could it be that a repeated start also needs such a delay ?

I also had this problem with 5us delay and only with an Arduino as Slave.

I still think that it is a bug in the Wire library. The library should take care of this situation.

system · December 1, 2014, 8:53pm

Just for your info and the search engines:

I have a working solution between an Arduino UNO (slave) and the Raspberry PI (with kernel parameter, I2C transfer handling etc....)

See at Raspberry PI Forum / I2C clock stretching

Topic		Replies	Views
I2C Wire.h: Slave Returning 0s When Nothing To Send (Is I2C the Right Solution?) Programming Questions	24	7083	May 5, 2021
Bug in the arduino I2C library? Programming Questions	13	1983	March 30, 2022
I2C SLAVE Networking, Protocols, and Devices	2	477	May 6, 2021
Arduino Zero as I2C slave. NAK address. Networking, Protocols, and Devices	1	2416	May 6, 2021
Problem with I2C communication Troubleshooting	3	1475	May 6, 2021

Arduino as I2C Slave returns sometimes 0 bytes instead of 4.

Related Topics