Recalcitrant SH1106 OLED [Solved: SCK & MOSI were swapped]

I’m having no success in getting the SH1106 1.3" oled working on my new homemade (based on SAMD21). I have been successful using the predecessor of this board with a modified Arduboy2 library and a (sadly too slow to refresh) LCD.

Now I have moved to an OLED and wanted something slightly larger than the 0.96" SSD1306 displays.

I can pop a schematic on here if needed but while I wait for a module to arrive in the post (which could be a long time in UK atm) please can anyone with a working, SPI driven SH1106 display let me know what voltages you are registering at IREF pin (on end of the resistor should do) and the ends of either of the charge pump caps, when you supply it from 3.3V? Perhaps @Mr.Blinky has one…? Also, if you have a working module, what’s the value of the resistor on it that’s connected to IREF?

Any known library mods for the SH1106 would be welcome. I’m going from a waveshare display datasheet at the moment and can’t tell if I’m turning the charge pump on incorrectly or whether it’s a wiring issue.


If the charge pump is enabled and working properly, you should see a high voltage (7 - 12V) on the Vcc pin 28.


I’ll run some tests tomorrow. the resistor value on my display reads 564 so 560K. For display initialisation I use pretty much the same command list as Arduboy. Only added the column address command. A schematic would be handy to see how you’ve wired up the display.

1 Like

@MLXXXp thanks, that’s what I thought - only seeing VCC.
@Mr.Blinky thanks too. I tried those to begin with (apart perhaps from the column address command)
Here’s the schematic:

Does anything seem to be a mistake in the layout?
Been using something like this as a guide (data and clock pullups unnecessary with the SPI pins on uC holding voltage high)

Looks fine to me.

Did some testson my SH1106 module @3.3V displaying mystic baloon title screen (regulators output @3.27V)

5.02V IREF
7.84V VCC

What’s your SPI clock speed? the display can’t handle speed >10MHz. I had a quick look at SAMD21 SPI application note and read multiple clocks are involved with SERCOM/SPI.

When I was in your situation I’d probably just repeatedly write the display initialisation code to the display with alternating all pixel on/off command with some delay in between.

If that didn’t show any result I’d go for configuring the pins as plain GPIO output pins and then bitbanging the display at a low speed. To rule out any misconfiguration of SERCOM/SPI

@Mr.Blinky thanks, those voltages are useful as they show there’s definitely a HW issue (which could be failed initialisation). I’m not getting any of the ones apart from VDD/VDDB at 3.3V. I purposely left pin headers holes on the MOSI/SCK/CD/RST/VCC/GND lines in case of this type of situation, so I will hopefully receive my eBay SH1106 module this weekend and be able to check that the SAMD21 is outputtting an initialisation instruction set and clock speed that is acceptable to at least the external display module. At that point, I think I will raise a case with the bare OLED seller as I don’t have time to make a standalone screen breakout PCB before I’d run out of time to seek redress from the seller. I have two other screens from the same seller, so I could desolder the eBay module and try one of them on that board, if it works on arrival. Glad I used low temp solder paste!

1 Like


You like that word you used it in your other post too :rofl:

1 Like

I thought repeating the use of the word would steer people on to what my post would be banging on about!

1 Like

I was actually expecting it to be a technical term to do with calcium.
I’d forgotten that ‘calx’ can also mean heel.

Evidently you are quite erudite. :P

Good news. I managed to use the SH1106 module to discover that I had disabled everything except the u8g2.begin() initialisation function. Once I added in some display commands, the module worked with the Arduino M0:

Bad news, changing the code didn’t help the prototype.

EDIT: I need to stop messing with this late at night, as THIS IS SO WRONG - LOOK AT THE VOLTAGE MR BLINKY REPORTED ON VCC!
Good news, while testing all pins / pads / components related to the OLED had continuity, I found that I had failed to make the net connected to the OLED VCC pin “actual VCC” and it was floating. Bodge wire inserted:

Bad news, it didn’t result in a working display or even the charge pump voltages on the CP caps.
*horrible soldering is explained by feeling the need to replace the caps on the charge pumps with something greater than 6.3V :roll_eyes: and not having 0805s in higher voltages to hand. That, and not caring at this time of night. Solder blobs and straight lines aren’t going to be what’s stopping this screen working.

I’m going to leave it there for tonight and desolder the display tomorrow, in order to see if a new display connected to power properly might work (I have a feeling that failing to provide VCC but making 3.3v available to the VDD pins and then trying to initialise may have damaged it).

Is there any libraries for that display and that chip within mbed? Maybe you can switch platforms to try things out.

Any chance you have a signal analyzer?

I have a 4 channel scope with SPI decode, which when I sort out the new OLED tomorrow (and remove the erroneous bodge wire) I will attach. The fact that the u8g2lib is working for the same oled on a module and the same chip (SAMD21) in the form of the Arduino M0 makes me think I should be looking at HW, signal and initialisation. So I’ll try and take a good look at the signal coming from the M0 and compare that to the Gamoo.

So I spent a large part of today not making much progress except to rule out several dead ends. I traced and probed the purchased module to see if the circuit differed from mine. Only thing I could see was two pullups @ 4.7k ohm on MOSI an SCK, which are there I suspect to facilitate the I2C interface that this module can be switched between. That and a 3.3v reg. I tried adding a couple of pullups of exactly the same value to the GAMOO but no change (the SPI signal was already looking identical between the successful M0 signal and the unsuccessful GAMOO signal).

I then desoldered the first bare OLED from the GAMOO and replaced it with a new one, in case something I had done had damaged the first one. With no joy there either, I desoldered the OLED on the module and (leaving it stuck in place on the rear of the PCB) soldered my third and final, new, bare OLED to the module to see if I had a duff batch. Sadly, in my case, the third OLED worked when soldered to the module, so either it’s a 1/3 working example and 2/3 are broken, or…

I think critically, I have never been able to get the charge pump firing on my board. So I went back to the datasheet and, based on the bootOled() function in Arduboy2.cpp, amended the initiation sequence and inserted it into a standalone Arduino sketch to loop through display initialisation every second. This was successful with the M0 but not GAMOO. I tested for false positives with the M0 by uploading blink.ino and checking that the charge pump capacitors were “idle” - they were. I then uploaded the initialisation sketch and the charge pump showed voltages > 6V, as expected. I even saw the last page in the display’s memory from the u8g2 demo code flash up every time initialisation finished and the display was turned on.

As I said before, the oscilloscope with SPI decode on shows the two boards (Arduino M0 and GAMOO) both spitting out clear protocols. My next steps are a) to desolder individual capacitors on the module to see if I am using wildly different values and b) desolder all the display-related passives on GAMOO, as well as the bare OLED and try to drive the module from GAMOO’s SPI header. I have tried this already but I have always had the additional passives and OLED populated so I never expected it to work. Feels like I’m clutching at straws though. I will also try to power the OLED on the module from a different power source when I connect GAMOO, just in case there’s something funny about the power supply that’s affecting it. But then again, it’s not even trying to start it’s charge pump, so I don’t think it’s a high likelihood of it being a supply issue.

Thoughts very welcome on other things to try. Hope you’re enjoying updates, if not progress.

Quiz: See if you can count how many OLED displays are in this picture.

At this point in a project for me would be when I start thinking if it needs to be calibrated with a hammer or perhaps adjusted with an open flame.

Have you tried soldering your ‘non working’ display to the module and see if it works on the module with the M0?

How about speed and voltage of those signals? and did you also include CS and D/C in the comparison besides MOSI and SCK ?

and what about display reset? (don’t forget it must be inactive high)

How about BS0…BS2 are they properly grounded so the display is configured properly for 4 wire SPI?

is display VDD/VDDB properly connected to MCU VCC and what voltage? and is PCB track wide enough? (add bodge wire to MCU VCC source?)

same for GND

Is display VCC only connected to the cap or maybe shorted to MCU VCC?

I count 4

My reward: a screenshot of a working GAMOO screen :wink:

@bateske you may hurt your self. I usually put it away for long enough so I forgot most of my frustrated attemps and can start it all over again. When you find the solution you feel silly and happy at the same time.

1 Like

I have made this confusing and I can’t say that the following will make it any clearer. Let’s call the three bare displays I got from aliexpress 1, 2 and 3 and the one on the module 4. When attached to the Arduino M0 we’ll call the combo M plus the number and when attached to GAMOO, G and then the number. If the module circuitry was used (such as OLED 4 attached to the Arduino M0 or GAMOO with it’s passives and OLED desoldered but connected to the module over jumper wires) we’ll add a * suffix. As at yesterday’s post I had tried:
G1, G2, M4*, M3*.
After that post I tried G3* to no avail. This makes me think it’s definitely nothing to do with the OLEDs, and is all down to my circuit on GAMOO. Very tempted to make an adjustable breakout PCB where I can solder jumper individual traces to a range of nets and play around with different passive values. I have left it alone today, favouring @Mr.Blinky’s approach over @bateske’s!

Voltage of signals seems fine at 3.3V ( have found two datasheets (1, that says logic can be 1.65 - 3.3V or 3.5V). Speed of signals is clock at 4MHz for both Arduino M0 and GAMOO. I have not double checked the RST and DC timings and polarity are exactly the same between code examples but I have checked they are within the datasheet tolerances, with plenty of pause before SCK and MOSI fire. CS is always low, on both the Arduino M0 and GAMOO.

yes, all three are grounded with no pulldown resistors in series.

Good questions. I will try bodge wire if no joy with other approaches, however the voltage seems bang on 3.3V from the regulator when measured at the header pin near the OLED VDD/VDDB pads. I will attach the scope and check for ripple though. I was concerned about this as the two datasheets above disagree on the minimum supply voltage when in a charge pump internal DC-DC mode, with one saying 3.7V is minimum and the other one (the bare chip) saying 3.3V. So I tried supplying it (the module when connected to GAMOO via header) from both the 3.3V (in case of current draw issues) and 5V from an Arduino Nano and still had no joy (although at that point there could have been issues with logic levels from the 3.3V SAMD21). I realise that was risking the SAMD21 but it is worth taking risks to try and flush out the issue.

Believe so but will add to list to double check. There’s a ground pour pretty much all round.

No, although this is what my silly bodge wire would have achieved if I hadn’t noticed my mistake and powered it on! It’s not showing anything like 3.3V at VCC (I believe because the charge pump isn’t working).


Not yet! But I’ll keep trying. Thanks for all your oversight - definitely helps to not be trying to do this on my own.

So given that GAMOO (with all display passives and onboard OLED desoldered) can’t get the module even initialised to the point of starting the charge pump, using code that does work on the Arduino M0, I am a bit stumped. But at least we’re narrowing things down again!

1 Like

Just to throw this out there: GAM0O.

So the final O is for OLED? What does GA stand for?

Gaming Apparatus with M0 and OLED.

No clue ¯\_(' _ ')_/¯ I’m making this up as I go along.

(Alternatively: Gaudy Acronym for Machine with Ostentatious Owner. :P
Or Gratuitous Acronym Made by Offensive Oaf. :P)