How to listen to a separate I2c master-slave using an arduino

So I am attempting to reverse engineer a touch LED controller, i do not need the controller part anymore and would like to use the touch panel with 4 capacitive touch buttons and 1 slider. Problem is when i searched the marking of the IC the capacitive nothing shows up, with a lot of continuity checks i managed to know the which header connects to where.

TL:DR : i managed to get an address of the touch panel using just a typical arduino i2c scanner but i dont know what to send to it. So i was thinking of hookiing back the original microcontroller back to it and i would like to "listen" using my uno to what the touch panel and original mCU is communicating. Essentially the circuit looking like this

My end goal is to be able to use the touch panel with uno, how would i code my uno to "listen" to an i2c buss.

Get a logic analyzer. A cheap USB one with open source software is good enough for I2C.

https://sigrok.org/wiki/PulseView

Klaus_K:
Get a logic analyzer. A cheap USB one with open source software is good enough for I2C.

PulseView - sigrok

Buying one would take weeks :frowning: is it not possible with arduino uno alone ? The one I ordered will arive in about 8-10 days (https://www.sparkfun.com/products/15033)

You can do it with an Arduino. I've used an UNO clone to listen in to an I2C bus. It wasn't very successful for 2 main reasons:

  • It was all done in software so limited to around 120kHz
  • There's only 2K of RAM so not many messages can be stored.

I can post the code it would be useful.

Forget using an existing I2C library. Read the processor data sheet and learn how to manipulate the registers used for I2C. You will probably have to set it up for slave and read each byte as it is transmitted, save it and then send to the serial monitor to study.

Expect to lose some hair.

markd833:
You can do it with an Arduino. I've used an UNO clone to listen in to an I2C bus. It wasn't very successful for 2 main reasons:

  • It was all done in software so limited to around 120kHz
  • There's only 2K of RAM so not many messages can be stored.

I can post the code it would be useful.

I dont need much since for sure the master controller is just doing fetch request to the touch IC, I also have a bit more powerfull arduinos arduino DUE and MKR1000.
Yes i would like to see your code :slight_smile:

PerryBebbington:
Forget using an existing I2C library. Read the processor data sheet and learn how to manipulate the registers used for I2C. You will probably have to set it up for slave and read each byte as it is transmitted, save it and then send to the serial monitor to study.

Expect to lose some hair.

You gave me an idea sir, cant i just connect my arduino to the old mCU and have tthe arduino the same address to the touch ic and i just record whatever is sent to the arduino, then ill disconnect the old mCU and now connect my arduino and resend whatever it recieved to the touch IC and see whatever is its response.
I will try this later

I don't know. Worth trying.

From my point of view I have written code in both C and assembly language to directly control the I2C registers on various PICs, so if I were trying to do what you want to do that's the way I'd go. You might succeed using an I2C library but my concern is that if the library wasn't written to do what you want then it will get in the way rather than helping. However, I am a strong advocate for trying things to learn so I encourage you to try what you suggest.

Good luck and have fun :slight_smile:

As Perry says, be careful which I2C library you use. Most, if not all of them, are written to handle I2C master or I2C slave modes. You need to make sure that the library you try is written to monitor the I2C bus. You don't want your hardware to play an active part in the bus (i.e. inserting ACK and NACK signals) as that will interfere with the communications.

I'll post the code in this thread when I get to my desktop system.

As promised, attached is the code for the I2C sniffer/monitor. It was originally written by someone called "rricharz" for an Arduino Mega 2506. I took their basic idea and reworked it to run on an UNO clone that I have here. There weren't many comments in the original code so it was initially difficult to figure out what was occurring. I've added lots of comments to the code to try and explain what it is doing.

Probably the most important thing you need to know is that it expects the SDA to be on PB1 (pin 9) and SCL to be on PB0 (pin 8 ). And, as I said previously, it seems to work ok with a 100kHz bus with the occasional hiccup. Above 120kHz, it starts to struggle badly, so don't expect it to handle a 400kHz bus.

The code was written just after I got into programming on the Arduino platform, so there may well be more efficient ways of doing things.

The UNO only has 2K of RAM so that limits the number of I2C messages the software can store to around 10 or so. I did try implementing a much more efficient storage method but the critical data capture section of the code started taking too long to run, even at 100kHz.

Enjoy ....

i2c-sniffer-v3.ino (14.6 KB)

markd833:
As promised, attached is the code for the I2C sniffer/monitor.

Thanks, added to the "Sniffer" section here: I2C Sniffers · Testato/SoftwareWire Wiki · GitHub.

@John41234, use a logic analyzer. The Arduino Sniffers are very limited.
I'm very fond of the LHT00SU1 logic analyzer in combination with sigrok/PulseView software. They run better in linux.

@Koepel - No worries. Hopefully it will be useful to others as a quick look-see.

@john41234 - The LA you've got on order from Sparkfun will run rings around my UNO code and will serve you well for quite some time.

Sorry for taking so long to reply again but, i first tried using this guide from arduino project hub . And got this result. Looking good the data seems consistent and repeating, this is without the touchpad connected to the master, so basically whats on the bus is the master and my uno.

i tried my best to decipher it here. Every makes sense so far, i have found the start bit, and the first bits are the address, which is CORRECT ! , followed by what it seems to be a WRITE BIT, which is weird since i thought it will just keep reading the touch pa status. but anyway the bit after that is the acknowledge bit which supposed to be pulled low but since there is no slave device there is no one to acknowledge it thus the next bit is an END bit where the SDA pulls high after the SCL.

SO FAR SO GOOD EVERYTHING SO FAR MAKES SENSE.

But the good news ends there, when i connect the pannel to the buss the UNO refuse to read, I change my wires thinking that i might exceed the capacitance on the i2c buss , but still oesnt work, it only doesnt work when i connect the touch panel, when its removed it can read fine. This is not good for me because the master didnt get to the point of sendding the commands data, since there is no acknowledggement

I think this where my idea comes in ill set my arduino as the slave device and set its address to be the same as the touch pannel ( igot the address of the touch panel using tthe i2c scanner where i connectedd the touch panel to the arduino and scanne the i2c addresses and it returned me an address).

image.

using the slave recieve example i ggot these numbers consistently but i dont understand them there is a pattern onthe middle numbers but the first and last doesnt fit, also the first number is 4 data. Thats it for me where im stuck.

The main problem is the host wont communicate(or my uno refusing to analyze the buss) to the touch pad if i probe it with my uno, i can confirm the touchpad and the controller is not broken because if i put them back together with out the uno its still does it job.

Will update again if i ever have any more progress

I am not sure if the library prints the initial address and the acknowledgement bits which makes it harder for me to trace. most likely not because the binary of 177 ( b10110001 ) does not contain a 53 (b110101). Another theory of mine is its initializing the registers of the chip, with the first number in the serial monitor the addrress and followed by the value (dunno about the last 0 though) but this also does not makes sense.

Can you hold your horses and wait until the logic analyzer arrives ?

A Arduino that uses its I2C hardware does disturb the bus. Only a ATtiny with its USI can be a sniffer. The sketch by markd833 does not disturb the bus, since it just reads the pins without any I2C hardware.

The Slave Receiver sketch is not okay, because the official example by Arduino is super weird.
Do you want a sketch that shows the received data ?

I think that you found the start in the picture with the waveform. Those are indeed the 7 bit address followed by the r/w bit followed by the ACK/NACK.

There is a possibility that the touch panel does not use the standard I2C. Perhaps the controller is adapted for it. Because it was detected by the I2C Scanner, there is a good chance that it uses standard I2C.