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

Good point, it appears that way on the SH1106 1.3" flex cables too. So that’s one more variable closed off.

Yes but they definitely are electrically connected - I just didn’t draw the wire between them because the GND symbol puts them both on the same net, at least in Kicad.

Yes, that’s what I think but we have to try everything at this stage, no matter how improbable.

This is a really good point, I do need to start probing more carefully on the GAMOO PCB, especially for shorts across any of the SPI lines. I have a few other PCBs but prefer not to have to reflow the microcontrollers if I don’t have to. Although we’re getting into that territory!

If you had a problem with this, then the module wired to your GAMOO board probably wouldn’t work either.

I’m leaning towards it being something to do with the charge pump.

Something you might be able to try is not using the pump and feeding Vcc pin 28 with an external high voltage. If you don’t have a 7V - 12V supply, a 9V battery would do. You would have to remove the capacitors on pins 2 - 5 and remove the code to enable the charge pump in the command sequence.

Oh yes, that’s one of the reasons I tried GAMOO plus module - to check the GAMOO SPI integrity.

I would not be surprised by the charge pump either but the only difference between the GAMOO PCB and the OLED module in that respect is three capacitor values. I wonder if the charge pump pulse timing / SH1106 internal clock settings need to be well matched with the capacitor values. More datasheet digging required perhaps.

That’s assuming you have no shorts or opens or other wiring or bad component problems that you haven’t discovered.

I very much doubt it. Again, you could try changing the capacitor values on the module to match yours, to confirm this. It’s really only the ones on pins 2, 3 and 4, 5 that should matter. All the other caps are just for power supply decoupling.

My money is on a trace being bad.

Look at the whole board under a microscope.

2 Likes

sorry for ther late reply

Mines grounded at the flex cable as below. Crazy thought: what If your bare display isn’t an SH1106 but actually SSD1306?
afbeelding

2 Likes

Thanks for checking, although @MLXXXp rightly pointed out that the pin 7 net is irrelevant as it terminates on the flex cable and isn’t electrically connected to the display.

Your crazy thought would also have to be a crazy coincidence too as the current bare OLED soldered to the module PCB is the third bare OLED I received in a pack of three. The first two I tried on GAMOO unsuccessfully. So although I haven’t completely confirmed the drivers on all three are SH1106, I think it’s unlikely that two out of three in the same order were SSD1306 and by chance the third one was SH1106. But I will keep it in the back pocket! Going to get the microscope out tomorrow, as recommended by @bateske and will receive the “desperation” caps on Tuesday.

1 Like

There should be one or more part numbers printed on the displays. If the numbers are all the same then they would almost definitely be SH1106 (since it’s been proven at least one is).

Even if some numbers are different, that doesn’t necessarily disprove it. There could be a date code, batch number, manufacturing machine number, etc. A close physical examination for any differences between them may help.

1 Like


I’ve had enough of a break now and am about to solder on the lower value caps. I probed the GAMOO PCB with no display installed and there don’t appear to be any shorts between the nets and I have continuity from the SAMD pins to the PCB pads for the OLED.

1 Like

I’m sorry again for not being fully aware of the state of things, but just confirming you are actually able to bring up your MCU and program it successfully right?

If so, you could also run through some kind of diagnostic on the controller side of things as far as itself testing if anything is shorted.

What does your power supply circuit look like? Are you using a regulator? Is it possible you for some strange reason don’t have enough current to drive the display?

Have you tried shaking it?

So the SAMD21 is perfectly well able to drive the SH1106 OLED module from the power and signal breakout header for the display. I couldn’t get it to drive (or even set the charge pump to produce the internal voltage required to drive) the bare SH1106 displays when soldered to pads about 10mm away from the header pins.
This is the most conclusive photo yet that I have no idea what’s going on!
image
So here we have the microcontroller connected to two displays - one on-board bare and one on the module. The code is clearly running and producing a satisfactory signal for the module to work. The power must also be good enough. I swapped some of the caps to be the same between GAMOO and the module (the charge pumps are both now 150nF and the decoupling caps near the charge pumps are the same - 150nF and 33nF, as per the probing a couple of weeks ago). The two resistors at the other end (VCOMH and VCC, both to GND) have been left as higher values 4.7uF and 2.2uF, rather than the 150nF and 2x 150nF respectively on the module. I may change them but as @MLXXXp has said, this is not really a likely cause and I’m scraping the barrel.

For those confused about the bare OLED on the module, I tested that my batch of bare OLEDs were not faulty by desoldering the module and mounting one of my new ones on there to make sure it worked. It did. I have now desoldered the new bare OLED that was confirmed working on the module and that’s the one on GAMOO in the picture above (resoldered the original one back, with only a little yellowing from the hot air damage). This means that it’s a known-working OLED that is failing to function on the GAMOO.

The only part of the module that I haven’t addressed on GAMOO is what appears to be a voltage regulator (3 pin SOT with lettering 662K) paired with a small cap on the high side, to make the module 5V compliant. Just looking into the ripple.

Yes, it’s a 3.3V regulator. You could confirm that by feeding 5V to the VCC pin of the module and checking for 3.3V on the output of the regulator (with the module standalone, disconnected from anything).

Since your GAMOO runs at 3.3V, you could also remove the regulator from the module and short the input and output pads, to rule out any possibilty of the regulator affecting anything.

1 Like

All I can think of is that the Module has extra caps on VCC besides the regulator that are not on your GAMOO. but they’re not that large.

Just wondering how long after powerup do you reset the display and how long is the reset pulse?

You could try a long delay before you do any initialisation and a long reset pulse so there’s more time for Vcc to get more stable.

1 Like

Where are these caps you’re talking about?

1 Like

Near the voltage regulator

1 Like

You’ll have to explain better how these caps would affect things. The extremely short delays resulting from having to charge any of the capacitors between VCC and ground couldn’t possibly affect anything.

However, removing the regulator and shorting its input and output pads on the PCB, as I suggested, would be a way of ruling that out.

1 Like

OK, just removed the VReg and associated high-side cap. Shorted Vin and Vout. Also changed the GAMOO remaining two caps to match the module value. No joy - still got images on the module and nothing on GAMOO. I also rechecked for continuity and shorts between OLED pads.

Before that, I probed for ripple and although it was ~120mV p-p on the SAMD side, it was way worse on the OLED side of the 662K.

To answer @Mr.Blinky’s question, I’m using the stock u8g2 lib graphicsTest.ino with U8G2_SH1106_128X64_NONAME_F_4W_HW_SPI u8g2(U8G2_R0, /* cs=*/ 10, /* dc=*/ 6, /* reset=*/ 7); configured. I also tried your standalone code and my own (using one of the datasheet initialisation flow charts). Reset was pulled low for a second in one case, I believe, and I have never seen the charge pump initialise using any of the code I’ve tried.

Does anyone here run Kicad and would be willing to look over my PCB files? I’m clearly too close to the problem (and greatly value the vicarious inspiration you lot are offering - thank you).

I’m not sure I can progress any further with this PCB otherwise. I’ll need to make some sort of breakout for just the power, OLED and SAMD21, with plenty of test points and pin headers broken out of every OLED pad so I can effectively breadboard it.

It was a long shot. Just looking what could be different.

I’ve installed Kicad 5.02 a while ago. Haven’t used it much but could have a look at your PCB.

1 Like

I believe you have a 4 channel digital oscilloscope with a deep memory. If so, and assuming you still have the module and GAMOO on board display wired in parallel, you might try putting your probes as close as possible to the display flex cable connections (right on them, if possible), on the data and clock lines of each.

Capture and compare the start up command sequence. You could also compare the other signals: reset, DC, CS (like with one reset line as a trigger plus DC or CS).