Problem with SSD1306 OLED

[PeterFW]

Edit:

Never mind, incorrectly labeled, different controller.... SH1106 instead of SSD1306, works now. The cheap price allways comes at a cost. (No pun intendet)

Hello!
I have 3 pieces of this display, two identical and a third that is from a different batch.
The two identical both show the same problem, as seen here:



Has someone got an idea why? I would say, they are broken... but, who knows.
They are controlled by an AtMega328P, at 5V over SPI and with the u8glib routines.
Both should be 5V tolerant.

Greetings,
Peter

[bktemp]

It looks like you need to increment the horizontal address by 2 when writing data: On the right side there are two colums showing random data (non initialized RAM data).

[danadak]

Consider looking at the write timing with oscope to the display. Also
examine logic levels correct at display.

The spec does not mention 5 V tolerance, in fact page 35 of spec shows max
Vih of Vdd1.

Regards, Dana.

[PeterFW]

Hello and thanks for your reply!

Consider looking at the write timing with oscope to the display. Also
examine logic levels correct at display.

The problem was wrong labeling, the controller on the display is not a SSD1306, it is the SH1106, it works now like it should.

The spec does not mention 5 V tolerance, in fact page 35 of spec shows max
Vih of Vdd1.

The boards both have a regulator and what appears some level shifting and were sold as 5V compatible. Should have checked to make sure but...

Greetings,
Peter

[amyk]

The SH1106 is a 132x64, whereas the SSD1306 is 128x64. Command set appears nearly identical. Did you get 256 extra pixels?

[bktemp]

The SH1106 is a 132x64, whereas the SSD1306 is 128x64. Command set appears nearly identical. Did you get 256 extra pixels?

The 128x64 pixels are centred in the 132x64 RAM area. That's why a 2 pixel adress offset is necessary.
I have no idea why there are so many 132 pixel wide controllers, almost all displays only have 128 pixels.