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