I2C Arduino slave sending multiple bytes to non-arduino master failed!

Please consider to not bother users with new terminology in this thread. This is an Arduino forum based on well understood technical terminology.

In technical discussions conventions are more important than wrong understood political correctness. Slavery is a fact and has been a fact for centuries, so that the wording is well understood and unchanged during centuries, and application to other than persons can not be an offence. And replacing master by controller likewise will cause confusion for absolutely no practical reason.

Feel free to open your own thread about the introduction of new I2C terminology in Arduino context and wait for reactions. Will NPX also consider to rename male and female connectors for some political discomfort?

As I said before, Philips created the I2C bus. That part of Philips became NXP. If NXP says it is "Controller" and "Target" from now on, then so it is.
See also my post about it: https://forum.arduino.cc/t/new-i2c-standard-document-by-nxp-controller-and-target/913956

So yes, I will continue to get everyone's attention that it is "Controller" and "Target" from now on, regardless what my personal opinion is.

Bothering is my middle name :kissing_heart:

Something I notice in the data sheet, between the command and the response there is suppose to be an I2C Repeated Start, while in your arduino master simulation you call Wire.endTransmission then start a new I2C communication with Wire.requestFrom. Arduino should support the repeated start format by giving endTransmission a false parameter such as Wire.endTransmission(false). Without this the I2C but will be released between I2C communications.

1 Like

The Nano board you are using runs at 5 volts - it will be out of spec powered by 3.3 volts, and needs a level translator to use on a 3.3 volt I2C bus. I originally thought you were using the Nano 33 BLE, but you have a 3rd party board that combines a classic atmega328 Nano with BLE on the same board.

@Koepel the port is one from the magnetic sensor and the original system works fine. I guess the GND should be okay? The diagram with weird jump is the system with non-arduino master and arduino slave.

I realise arduino boards always send ACK bit while the non-arduino master does not. And yes I think the weird jump is caused by the ACK from slave. Not sure how should I solve this.

I even tried to connect an arduino (master/controller) with the original magnetic position sensor (slave/target) and the data transmission was just fine.

I guess the non-arduino master is really the one causing trouble for it's abnormal I2C protocol.

Guys is there any custom I2C library out there that allows me to decide when to send the ACK bit??

I realised the non-arduino master & sensor slave does not follow the pattern stated in the datasheet. But somehow the system still works fine. But yes following the datasheet will always be better.

That sounds very troublesome just to connect the I2C bus. So how should the circuit look like?

The ACK by a Arduino as Target (Slave) is done in hardware.

Because it is a working product, that does not mean that it has no shortcut on the I2C bus. I have seen enough bad examples by big companies. Don't assume that the original product is any good.

The Renesas document about the "simplified" I2C bus is not that bad. I think that if the original Controller (Master) is according to the "simplified" I2C, then it would be according to the I2C standard.
It is almost as if the original Controller (Master) puts aside the "simplified" I2C and makes something far worse.

A I2C level shifter is a bidirectional level shifter that can connect a 3.3V I2C bus to a 5V I2C bus. https://learn.sparkfun.com/tutorials/bi-directional-logic-level-converter-hookup-guide/all
If both sides are high, it does nothing. If either side is low, it connects the signals.

You could add a resistor in the signal path of 100Ω to 470Ω and measure both sides to be able to detect if it is really a shortcut. But I'm afraid that the more tests you do, the more bad things will be discovered. It really does not look good.

First thing I would do is get the arduino slave properly set up to interface with a 3.3 volt system, if that is indeed what you have. I notice your picture of the simulated master / slave setup uses a node MCU, which is a 3.3 volt device, you could temporarily use that as the slave device as a test.

I certainly hope you are not using 4.7 ohm resistors as the pull-ups on the I2C bus.

Do you have a complete list of the sequence of commands that the original master is sending the original slave? It may be that your simplified slave code is not responding properly at some point.

The spike you are concerned about is nowhere near a transition of the clock signal, so that in itself may not be a problem with the actual communications.