I2C Probe - A community project

[mnfisher]

I had the idea to try this while working on another project. Would it be possible to create a simple circuit to probe an i2c connection between an MCU and an i2c device. It's not possible (I think!) to use the MCUs i2c hardware - as it wants to assert ACK/NACK etc.

Initially - I worked with an ATTiny chip - I wanted it to be as small and simple as possible with just 4 connections (VCC, Gnd, SCL and SDA) to the target circuit.

Initially the plan was for a self-contained device - and yes I know a logic analyser can do all this when connected to a PC (It's a baby logic analyser!)

With an ATTiny861 - running at 16MHz (20 would be possible with an external crystal) - and my own SPI driver (for size and speed) and ST7789V code - I added a 7 x 5 font- to allow a maximum of data per line (it's also 'bitwise' packed to take up minimum memory - it's displayed at 2x size).

The ATTiny worked well - and could decode i2c signals at 40k baud !

However - most i2c is at 100k (or 400k!) so although the Tiny was putting in a good effort - I wasn't sure I could push it that fast.....

So - then I got an esp32-s3 (note this should work okay on the C3 or plain esp32) - I added a couple of SPI routines (to initialise and send) - and the display works quickly! (Of course with all the extra memory I could use the display component)

However - on adding pin interrupts for SDA and SCL - I found it could only read i2c at 1k. I was somewhat disappointed.

So - I moved the ISRs to supplementary code (using the view code option to get the C) - and stored them in IRAM - I also modified the setup for these to allow for this. I changed the pin reads (in the SDA_Change_ISR to gpio_get_level(pin); - which works in IRAM as well.

This pushed the speed to 60k - better - and then changing the build options (using idf.py menuconfig) to optimise for speed gets us reading 400k

So - the questions:

1) The esp32 only allows 3V3 signals - I'd like it to work with 5V or 3V3 - any electronics folk any ideas on an easy way to allow either (and possibly other voltages)
2) The display - which I have set to landscape (this can be changed in properties) - doesn't allow hardware scrolling (it does in portrait!) - and the display 'wraps' clearing the next line. The esp32 is probably fast enough to scroll either orientation - but suggestions as to layout? The current layout is perhaps a little squashed!
3) I use a green block for START, white for ACK, cyan for NACK and blue (really) for STOP - better suggestions please.
4) Once I started I thought of lots of ideas (decode UART, an app allowing signal 'injection', a probe of attached i2c devices etc) Ideas (and help with coding) welcome...
5) Help designing a PCB (KiCAD tests my mouse control/vision to breaking point)
6) Ideas for other functions etc
7) It's possible to speed up the display somewhat - the ATTiny has just 512bytes of RAM - so buffers were small by necessity.

So far I have tested with another esp32-s3 reading a ds3231 RTC - I have tested using the FC component (a bit boring) and my own component (which does multi-byte reads)

Wiring the display - the pins are defined in supplementary code for SPI
#define PIN_NUM_MOSI 11
#define PIN_NUM_MISO -1 // Not supported by my display - a touchscreen might be nice?
#define PIN_NUM_SCLK 12
#define PIN_NUM_CS 10 // I do connect this - but some displays don't have a CS pin and an option is to pull it to Gnd.
DC is 8
Reset 9
Backlight I pull to VCC - but could be controlled if required.
SCL of the circuit to be probed is A5 and SDA A4 (note that the interrupt on SCL only needs a rising pin, SDA - needs rising and falling)

As can be seen in the image - both MCUs are powered by one USB connection..

i2c_probe.png (677.82 KiB) Viewed 234 times

Martin

[chipfryer27]

Hi Martin

Sorry to be brief

If only monitoring then a CMOS buffer would do your conversion, or if space is tight then a couple of FETs, both would run off 3v3 and not care of input up to 15, but if you are considering injecting then perhaps a bidirectional converter would suit?

https://www.amazon.co.uk/Converter-Bi-D ... 372&sr=8-9

I haven't checked out the above or similar so can't say best suited or not.

I'm sure someone will offer their KiCad (or similar) skills and I do know of one forum member that's really, really good at making boards. Hopefully Gerbers will be included to allow anyone to build, package independent.

Catch up soon,

Regards

[medelec35]

Thanks Martin that is great.
one thing to remember since I2C are open collectors, you should not require level shifters.
To be on the save side in case accidently setting an output high you can use two Schottky diodes where the cathodes connect to the device under test.
All the device undertest will be doing is pulling the voltage down.

[mnfisher]

Thanks Iain & Martin,

I'd looked at level converters - and the one I looked up was described up to 28800bps - I do have some so I might try one... It leaves the problem of 'powering' the device too - which I was hoping could be off of the system under test (although this is not essential - as long as there is a common ground)

The 'target' system is setting the i2c levels so it may well have 5V on the i2c pins (10k or 4k7 pullup resistors) - so do need some protection?

I've not used a Schottky diode - will take a look...

Martin

[medelec35]

Hi Martin.
I have added some extra information.

Connecting a 3.3V I²C Master (ESP32) to a 5V (works on 3v3 as well) Slave Without Level Shifters
The key principle is that the target system (5V slave) operates in open-drain mode and will only pull the I²C lines low - it won't actively drive them high.

Target system has pull-up resistors (to 5V):
Without protection, you will have 5V on the I²C lines when idle, which could damage the ESP32.
The solution is to add diodes in series with the ESP32's I²C pins. When the target tries to pull lines up to 5V, the diodes become reverse-biased and block the current.
The target can still pull lines low as the diodes are forward-biased for current flow.
The ESP32's pull-ups to 3.3V work normally through the forward-biased diodes, resulting in lines idling at approximately 3.0V (3.3V minus diode drop), which is still a valid logic high.

Target system has no pull-up resistors:
The ESP32 provides the only pull-up resistors (4.7kΩ to 3.3V).
The diodes are forward-biased when the ESP32 pulls up the lines.
When neither device is transmitting, the lines are pulled up to approximately 3.0V (3.3V minus 0.3V diode drop).
When either device transmits, it pulls the line low (0V).
The 3.0V level is well above the logic high threshold for 5V devices.
The diodes essentially isolate the ESP32 from any 5V pull-ups whilst maintaining proper I²C operation at a safe 3.0V level.
Use Schottky diodes (like BAT54) to minimise voltage drop.

[mnfisher]

A few tweaks.

Fixed a bug in the hex print routine ('A'..'F' is so yesterday - 'J'... is where it's at now)
Tidied the buffer for i2c received - had 2 before (faster on 8 bit MCU) - but moved to one 16 bit array (might be quicker using 32 bit?) - also tried using message passing from the interrupt handlers - but this seemed too slow..
Added an address probe - this displays the addresses of any attached i2c devices at start (I added a display so got 3 (the RTC board also has a memory device)) - all looked good.

Needs work on layout and display - and some thought on control - and possibly some 'filtering' - only display messages to address 'x'. The display handling needs some more thought - print string should probably wrap and advance line - and newline on stop condition might not be ideal either?

Ordered some TXS level shifters - which look as though they ideal for this....

Martin

[mnfisher]

An interesting problem - anyone any ideas.

My PC suddenly started losing focus on windows (any window including start menu) - Edge for example - the title bar would change 'grey' and input would be going somewhere else. I seems to have fixed - but not really sure how / or why.

Martin