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

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).

@Mr.Blinky may beat me to this but I think I may have found the issue. Just getting some pics to explain, so have a quick sweepstake to see who’s right. I believe you have all had enough info to spot the error that I think it might be.



VERSUS


Now to figure out if I can greenwire it to confirm, before a board rev.

Actually I didn’t until you pointed it out.

I’m so gratified.
First:


Then:


So board respin it is then. Thanks for playing along at home with me - it really kept me going. I can at least get on with testing a few more things before I send the board off, just in case we find any more hilarious errors!
And now, back to our scheduled programme.
3 Likes

YAY! :clap: :+1: :tada:

2 Likes

Absolutely! Couldn’t have done it without everyone helping.

1 Like

I’m wondering if it’s still comfortable in your hands with some headphones plugged in. It looks like the plug will be sticking out into the palm of your hand a bit. Might be something to test before doing a respin.

1 Like

Wow, I’m so glad you mentioned this. From an ergonomic perspective, I think you’re probably right - the jack needs to be more aligned with the sides/battery axis.

However, the real save you have just provided is when I look at the PCB, none of the jack pads are connected to nets. I have checked why and it’s because the schematic part uses letters for its pin numbers and the footprint uses numbers, like every other part does. I will do some proper revision in that area!

1 Like

ye olde pin swap

1 Like