Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2C: garbage output on DragonBoard410c #28

Open
ric96 opened this issue Jul 24, 2019 · 20 comments
Open

I2C: garbage output on DragonBoard410c #28

ric96 opened this issue Jul 24, 2019 · 20 comments
Labels

Comments

@ric96
Copy link

ric96 commented Jul 24, 2019

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
Copy link
Member

ladyada commented Jul 24, 2019

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

@deshipu
Copy link
Contributor

deshipu commented Jul 24, 2019

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
Copy link
Author

ric96 commented Jul 24, 2019

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

@makermelissa
Copy link
Collaborator

makermelissa commented Jul 24, 2019

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
Copy link
Collaborator

makermelissa commented Jul 25, 2019

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
Copy link
Author

ric96 commented Jul 25, 2019

@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
Copy link
Collaborator

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
Copy link
Collaborator

makermelissa commented Jul 29, 2019

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
Copy link
Collaborator

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

@ladyada
Copy link
Member

ladyada commented Jul 31, 2019

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
Copy link
Collaborator

Ok, good to know :)

@ric96
Copy link
Author

ric96 commented Sep 9, 2019

Hi,
any updates on this?

@makermelissa
Copy link
Collaborator

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

@makermelissa
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor

kattni commented May 4, 2020

@makermelissa What is the status of this?

@kattni kattni added the bug label May 4, 2020
@makermelissa
Copy link
Collaborator

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

@adamcandy
Copy link
Contributor

adamcandy commented Feb 20, 2021

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
Copy link

andrewerrington commented Jan 26, 2022

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:
IMG_20220125_164643~2

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:
IMG_20220126_131400~2

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants