I2C: garbage output on DragonBoard410c

[ric96]

I get garbage OR whatever was there on the last frame displayed on the display, and the code hangs for a long time.
Here is an example of the oled displaying the last frame, while running the demo code in readme:

This library is working as expected, so at least its not hw.
https://github.com/codelectron/ssd1306

[ladyada]

do you know for sure that display is SSD1306? knockoffs often use other chipsets

[deshipu]

In particular, SH1106 is very popular, but sadly it doesn't support the addressing mode that SSD1306 uses by default (so most drivers won't work).

[ric96]

I've tried this display with Arduino, Zephyr, MRAA and the above mentioned library all worked fine so i'm assuming its SSD1306.

[makermelissa]

What is the exact code that you're running and what are the dimensions of that display? I'd like to test it out on a similar setup with an equivalent Adafruit display.

[makermelissa]

A couple of things I just thought of are if this is running on the DragonBoard 410c and you're using a logic level shifter:

1. Make sure it's I2C Safe such as https://www.adafruit.com/product/757
2. Make sure VCC is 3.3v and not 5V or at least the same voltage as the logic levels.

[ric96]

@makermelissa running the code that is in the Readme of this repo under usage example.
I've got a bmp280 working fine with this very setup.
I've separately tried a 128x32 and 128x64 oled display. Both of these had the i2c address set to 0x3c if that helps.
Again, the display works fine using another library so i think I'm good on the level shifter end.
PS. Using the Audio Mezzanine as the level shifter. This has worked well for i2c usecases over the years.

[makermelissa]

Hi, I finally got around to testing with https://www.adafruit.com/product/931 on the DragonBoard and can confirm that the issue occurs (random dots plus hanging) with Adafruit displays as well.

[makermelissa]

After hitting Control-C and waiting a couple minutes, I finally got this error output in addition to the expected keyboard interrupt error:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bus_device/i2c_device.py", line 68, in __init__
    i2c.writeto(device_address, b'')
  File "/usr/local/lib/python3.7/dist-packages/busio.py", line 65, in writeto
    return self._i2c.writeto(address, buffer, stop=stop)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", line 38, in writeto
    self._i2c_bus.write_bytes(address, buffer[start:end])
  File "/usr/local/lib/python3.7/dist-packages/Adafruit_PureIO/smbus.py", line 244, in write_bytes
    self._device.write(buf)
OSError: [Errno 22] Invalid argument

[makermelissa]

I wonder if this is related to adafruit/Adafruit_Python_PureIO#4

[ladyada]

probably not, smbus is the native I2C library/interface, havint it in pureio would be rad, but its really not essential. also repeated start isnt used on this display

[makermelissa]

Ok, good to know :)

[ric96]

Hi,
any updates on this?

[makermelissa]

Hi, thanks for checking in. I was planning on taking another look at this later this week.

[makermelissa]

I think I may have found something in that Blinka has trouble with i2c write-only devices on certain boards (DragonBoard 410c and Jetson Nano I've found). I'm looking into this further.

[makermelissa]

This might just need a reset line hooked up. I've seen similar behavior with microcontrollers. That solution will probably only work with the displays that have a reset line though.

[kattni]

@makermelissa What is the status of this?

[makermelissa]

Unknown at this time. I can take another look after I finish the I2C bitbangio library, which might be the solution to this.

[adamcandy]

It looks like you are seeing recognisable data on the screen, so it is possibly not the same issue as #56, but you could try using Page Addressing Mode in pull request #57. @ladyada and @deshipu hinted this could be the issue if the display is using SH1106 hardware instead of SSD1306. (and @ric96, even if other libraries work this is no guarantee this is a SSD1306 - I've used other libraries which worked - they were using the more widely-available Page Addressing Mode). These kind of issues are explored on this Arduino forum page and helped my investigations and subsequent fix.

(note if you have successfully used another method to load data onto the display then use this library and see some junk, the correct data shown could just be leftover from the previous method -- the subsequent method is just not writing to the display correctly leaving it to show correct data from before, possibly in just some areas of the display. This can be confusing because the screen appears only partially incorrect.)

[andrewerrington]

Hello. I'm trying to use this library with a 1.3" OLED in place of a 0.96" OLED in this project:
https://github.com/sethvoltz/OctoPrint-DisplayPanel

The 0.96" OLED is probably an SSD1306, which works. The supplier of the 1.3" OLED claims it is based on SSD1306, but I suspect it's actually SH1106. The back of the PCB says 1.30"IIC V2.0, and the OLED flex cable has GME12864-70 printed on it. I have two of these modules and they behave identically.

Here's what I see when I plug it in:

The message "Printer Not Connected" is the bottom line of the intended screen content.

After various adventures I put everything back as I it was and added only page_addressing=True when instantiating the display object. Now you can see that top-to-bottom everything is there, but left-to-right the screen is shifted half over, plus the four unused pixels in the SH1106 memory map (132 pixels wide instead of 128) are visible in the centre of the display:

I'm hoping not to have to delve too deeply, but I could if necessary. Any suggestions for things to try would be welcome, and I'll report back with any progress.

[andrewerrington]

Never mind. I decided to go with luma.oled here which supports SSH1306 and SH1106 (and others).