I am still having difficulty in trying to get the Nano 33 IoT to communicate using the I2C with another Nano 33 IoT. The specific problem I am experiencing is that data just stops receiving at the master. When this occurs a reset the Nano by pressing the button on the board. Reseting either the slave or master will resume activity (I would think reseting the master is what would be needed but reseting the slave seems to do the same thing). During data transfer some of the data is corrupted, displaying a space or reverse "?" or even an "!" at times.

I have reloaded the IDE along with the SAMD Core for the Nano 33 IoT. Thinking hardware could be a problem, I used an MPU6050 to see if I could communicate with it over I2C and was successfull for each of the Nano 33 IoT's. They each were able to keep a connection and return raw data using the Wire library for over 45 minutes each.

I am powering from a laptop computer via USB. I measured voltage on the 3.3V pin and have 3.289 volts I don't think I have a problem here. I am allowing the on board 4700 Ohm resistors to serve as pull-up resistors. I suppose I could remove one of the resistors by desoldering but I am not sure that will help and it also may have other effects for I2C communications I do not know about which may be occurring on the Nano 33 IoT board.

I also performed an additional test where I used two Nano's (older model) to communicate using the I2C using the same setup. The only difference being the hardware and software. They worked well and were very stable even after reducing the delay() time in the example and also increasing the clock to 400000 (setClock(400000)). I had never done this setup beforef and I wanted to see how things would perform.

My code I am using for the slave_sender and master_reader is from the example folder included with the Wire library.

I adjusted the code at the master and noticed that the data stops when the "wire.available()" is no longer available. Even when the code executes the next statement in the loop, "Wire.requestFrom(2, 6)", no further data is available. The result is the connection just stops. To correct this problem I inserted "Wire.begin()" after the wire is no longer available. By doing this I have been able to keep the connection sending the "hello ". It is as if I pressed the reset buton and it started again. I guess you could call this a workaround for the problem I am having but I don't like it.

I am wondering if it is something in the library - I am not that familiar with the library and find it difficult to follow. Could it be a timing problem? I have played around with the "delay()" statements on both the slave and master and it did not help.

I have attached my code and other references. Sketches are master and slave. Photo is setup. Console output from master. Also included scope activity when data is being transferred normally and then I tried to capture point when Wire.available() was lost.

Maybe someone could try to reproduce or offer an explanation for why it is behaving the way it does. I am not sure what to try next.

 

I have run into problems with I2C communications on Arduino using the wire.h library and I am not the only one. There are quite a few forums with people asking for solutions. Maybe this will help:
https://github.com/Richard-Gemmell/teensy4_i2c
Good luck,
Keith

 

I am still having difficulty in trying to get the Nano 33 IoT to communicate using the I2C with another Nano 33 IoT. The specific problem I am experiencing is that data just stops receiving at the master. When this occurs a reset the Nano by pressing the button on the board. Reseting either the slave or master will resume activity (I would think reseting the master is what would be needed but reseting the slave seems to do the same thing). During data transfer some of the data is corrupted, displaying a space or reverse "?" or even an "!" at times.

I have reloaded the IDE along with the SAMD Core for the Nano 33 IoT. Thinking hardware could be a problem, I used an MPU6050 to see if I could communicate with it over I2C and was successfull for each of the Nano 33 IoT's. They each were able to keep a connection and return raw data using the Wire library for over 45 minutes each.

I am powering from a laptop computer via USB. I measured voltage on the 3.3V pin and have 3.289 volts I don't think I have a problem here. I am allowing the on board 4700 Ohm resistors to serve as pull-up resistors. I suppose I could remove one of the resistors by desoldering but I am not sure that will help and it also may have other effects for I2C communications I do not know about which may be occurring on the Nano 33 IoT board.

I also performed an additional test where I used two Nano's (older model) to communicate using the I2C using the same setup. The only difference being the hardware and software. They worked well and were very stable even after reducing the delay() time in the example and also increasing the clock to 400000 (setClock(400000)). I had never done this setup beforef and I wanted to see how things would perform.

My code I am using for the slave_sender and master_reader is from the example folder included with the Wire library.

I adjusted the code at the master and noticed that the data stops when the "wire.available()" is no longer available. Even when the code executes the next statement in the loop, "Wire.requestFrom(2, 6)", no further data is available. The result is the connection just stops. To correct this problem I inserted "Wire.begin()" after the wire is no longer available. By doing this I have been able to keep the connection sending the "hello ". It is as if I pressed the reset buton and it started again. I guess you could call this a workaround for the problem I am having but I don't like it.

I am wondering if it is something in the library - I am not that familiar with the library and find it difficult to follow. Could it be a timing problem? I have played around with the "delay()" statements on both the slave and master and it did not help.

I have attached my code and other references. Sketches are master and slave. Photo is setup. Console output from master. Also included scope activity when data is being transferred normally and then I tried to capture point when Wire.available() was lost.

Maybe someone could try to reproduce or offer an explanation for why it is behaving the way it does. I am not sure what to try next.

View attachment 214473

i2c/twi isn't difficult. At all. Unfortunately, most developers make something incredibly simple, very difficult because of their lack of understanding of how to work WITH the machine, rather than against it; how to correctly write code that is both efficient, and robust; and a misunderstanding of specifics of the protocol/standard . I'm not referring to you, I'm referring to the author of the library you're attempting to use. He's got _way_ too much code to do i2c.

First of all, you should have an oscilloscope so you can see exactly what is happening signal-wise, so there is no ambiguity or guesswork. Period. If you don't have an o-scope, join your local electronics group, contact your local maker community, whatever- and find someone with an o-scope to help you diagnose.

Usually, the most common cause of comm failure in i2c falls into one of 3 areas- 1) incorrect pull-up resistor values (which should be sized based on comm speed, and a few other factors), 2) comm-speed too fast for various reasons (EMI, bad connections, etc), and 3) the slave is confused, and it hangs one of the 2 signal lines indefinitely to indicate it got lost, and Master needs to reset, and retry.

SDA and SCL High at Idle (both High):


If a slave is confused, it will kill the clock by pulling SCL low and holding it there, irregardless of SDA High or Low.

 

I Found A Solution!!!!

I disconnected the scope (I thought I had done before). After disconnecting the scope I did not get any interference or lock-ups. I am not clear why this worked - maybe capacitance of the scope leads (about 30 inches long) effected things?

I was able to connect two nano 33 IoT to communicate with each other and I extended the SDA/SCL data lines to 30 inches (although the ground line remains at 8 inches). I also operated with Wire.setClock(400000). I used minimal delay(10) times. I obtained a rather quick connection that was error free and did not lock up.

I am going to attach a MPU6050 and see if I can get it to work also.

Attached is the slave and master code I am using in this little stress test. I also attached what I was seeing on the scope (when I was operating at 100 KHz) when it was failing. The picture of my setup is BEFORE I extended the SDA and SCL wires.

Thanks Much!!!

 

If communication line capacitance is high then you should use smaller resistance pullups.

 

This is interesting because I am also chasing down an interference issue with a Nano 33 IoT and a string for WS2811 christmas lights and the length of the wire has a direct relationship to the severity of the interference. A length of wire 2M between the board and the first WS2811 chip causes a great deal of interference, but an 8M length of the same wire causes very little-to-no interference. All this, using Shielded Twisted Pair wire.