It's been few months that I'm trying to make my Newhaven OLED SSD1322 256x64 display works properly (NHD-3.12-25664UCW2).
Basically it's works great, but after an unspecified amount of time, it freezes.
It's wired as 4-SPI.
I've tested 3 different setup :
Adafruit FTDP chip + python lib luma.oled (on Windows)
Arduino Nano V3 + u8g2 or u8x8
Raspbery Pi Zero + python lib luma.oled (on Raspbian)
Each time it's the same issue : OLED display works very well, but at some point it freeze (usually last displayed screen), while program still running normaly.
Just restarting the program usually doesn't work, display stays frozen.
But if I unplug the screen for a moment (event while program still runs), and plug it again, it start working again, but only for a short period of time. That time seems proportionnal to the time beeing power-off though.
Because it probably doesn't come from the software (same issue on different software stack), I don't provide any code here.
I've search the web a lot, found some persons with a similar issue (link1, link2, link3, link4, link5), but never with a solution.
If you found others with a similar issue, could you please give a link to it.
This is not the same as the very cheap I2C OLED displays, those have the habit to disturb the I2C bus for others and they are sold as 3 - 5V, but their I2C bus is 3.3V.
You tried different things, that is a good test
The Nano is a 5V Arduino board. Do you have a 3.3V Arduino board ?
Could you show a photo that shows the wiring ? I hope the wires are not too long.
The SPI bus can be set at a lower speed or done in software. The SPI bus in software has more timing space between the edges, that might help for some devices.
You could add a decoupling capacitor at the display, for example 100nF + 100µF. You would be surprised to know how many projects come to life with enough decoupling capacitors.
You could try a different interface. Is the clock + data or else the full 8-bit data the only two options ?
In the end, the display could be damaged. Keep that in mind. Do you have more displays (that have not been connected to a 5V Arduino board yet) ? The Arduino Nano can output 5V up to 40mA with a output pin, you don't want to push that into a pin of the display.
I just received an Adafruit QT Py RP2040, which runs at 3.3V.
I've tried so basic program in CircuitPython but until now I did managed to make it work properly at all, I'm still on it.
I will also try a stability test with a basic Arduino program.
Yes I will prepare some pictures, but I used so many configurations, which one / what do you want to see ?
No it's very short wires.
Do you have values that I should try please ?
Can you elaborate this idea please ?
That is too much work? Moreover SPI is supposed to be better so I'd rather stick to it.
I've bought a new one yesterday, I'll try it soon.
Why did you choose the repo of a TFT display instead of one of their Ssd1322? It's just for a test?
As I said, I didn't put any code to lighten the post : I've tried so many different things that it would be a book. For instance, I had the same problem when just running the clock.py example of the luma library. No special code.
Concerning the 5V Arduino, that may be a mistake on my side (even if power pin is 3v!). But do you think that a voltage issue may provoque that issue where display works fine but only for fewer hours, even when properly powered?
If there is a Ssd1322 repository somewhere, then please give a link to it. If you have spotted a bug in that code on Github, then feel free to make a Issue at Github.
It is possible to damage a chip only for a part. For example, if the Arduino Uno gets too much voltage on a analog pin, then that pin could be damaged, or the whole analog section could be damaged, while the rest of the chip still works.
I noticed that you added links to your top post.
The links to this Arduino forum are typical cheap I2C OLED problems, there are many more.
The links to the Newhaven forum are very interesting. Together with what your describe it could be a internal charge pump problem inside the display.
It seems that the "while(0);" is supposed to be a very small delay. I think that the compiler knows that it does nothing and that delay is removed.
I don't know the display and I don't know how long the delay should be.
You could try to replace all of those "while(0);" with "__builtin_avr_delay_cycles(2);". Try a number of 2 or 10 clock cycles (or any other number that you can think of).
PORTB &= ~(1<<PORTB1); //digitalWrite(OLED_CLK, LOW);
__builtin_avr_delay_cycles(2); // <--- a very small delay
PORTB |=(1<< PORTB1); //digitalWrite(OLED_CLK, HIGH);
[ADDED] Now that I think of it, that code is only for the Arduino Uno or Mega and you should not use those anyway (not without voltage level shifting).
There is a circuit inside the OLED that pumps a higher voltage into a capacitor. Since others have similar problems on the NewHaven forum, I suggest to try to get your money back for the faulty ones.
Thanks for creating theses issues, I hope it will help others.
I finally bought another oled screen (same size, same controller, another brand).
I've tested it on the QT Py, and it works perfectly well, even for hours (with same code).
so it definitely was a hardware default.
I lost so much time on that... But I also learn a lot!
