MCU 'pico' shutdown: i2c timeout

Basic Information:

Printer Model: Mercury One.1
MCU / Printerboard: OctopusPro
Host / SBC: BITTPI + PiCO
klippy.log
klippy (14).log (257.5 KB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

SHT15/21 Temp Module Works on gpio pins of the BTTPI - ran into out of memory issues on really long prints, turned i2c off on the bttpi overlay, instaleld a second sensor on a pico, flashed klipper, got the sensor to be seen, but constantly encouters a i2c timeout. pico resources are all low. and i’ve played with the report time to try and pace the temp checks out. Racking ym brain trying to find the issue, figured a second / thrid / 50 sets of eyes might help

I will just show you something:

The basic issue with PICO, is that it lacks of any error reporting for I2C.
There is patch, but I didn’t test it yet:

Fixed, reproduced and tested, you can test and leave your result here:
rp2040/i2c.c: Check for NACK/Start NACK by nefelim4ag · Pull Request #6692 · Klipper3d/klipper · GitHub (thanks)

If it works, It can be merged to klipper which should give a more or less clear error message in general with RP2040 and I2C.

SHT15 and SHT21 are different sensors.
SHT15 is not supported at all, I can’t find any code for it.

In general, dupon are loose and just making them tighter fit could help with I2C stability.
You can use tweezers, and needle nose pliers, to make metal female dupon tighter.

1 Like

I will look at those and try out the patch after work. For the sht15 while not listed as supported it did work when connected to the BTTpi for months so the family of sensors is supported I believe this is a pico issue, however I am building a ercf and will have a climate controlled cabinet - and the wire lengths would be pushing the limits for i2c sensors. I guess I could always go with PI0’s but $4 vs $24 is a budget savings when using 2-3.

Thank you for the information it’s much appreciated

I use SHT31 with 1-meter cable, twisted it as I can :smiley:
It works.

This will really depend on the cable, sensor, and HW devices on both sides.
You can make the signal better by replacing 10k resistors with 4.7k.
Or by the usage of level shifters and use 5V for the sensor (if it supports it) and 3.3V for MCU.
Both things will make the signal edges steeper.

BTW, I think my dirty async software I2C can also help with that, but I did not have issues, and haven’t an oscilloscope to directly reproduce and test that.

P.S. I tested RP2040 patch, and updated the link to the PR above.

Didn’t seem to help, actually made it error out more, but I am going to go back to the basics. i have a second pico and sensor, some of my solder joints look cold, so im going to try and solder the second one up right, twist the i2c cables and try again. if all else fails i have sourced a pi0w and ill use that - it should* be able to run multple sensors- also double checked the sensors are htu2d sht21 compatible replacments for sht15’s

Not sure if it’s the patch that fixed it or the new Pico and sensor that’s doing it but it’s back up and running it appears or at least it’s been 2 hours and no errors. Though it also occurred to me the Pico is small so I just wired the sensor on back of the Pico and I’ll just use a shielded USB cable to run it

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.