Hello, friends.
I’ve run into a very weird problem with the popular 0.96 I2C display
This usual thing (bought from someone else, but you know this standard thing. Besides, I had an issue with the same display from another source.
So, back to the point.
Problem encountered with Arduino Nano and breadboard Atmega328p with internal oscillator and a proper bootloader (runs other stuff perfectly), totally identical problem. Latest arduino version. Atmega328p running on Minicore. Tried different BODS and LTO.
Libraries included in the project:
#include <SPI.h> //never actually use spi
#include <Wire.h> //for oled
#include <Adafruit_GFX.h> //for oled
#include <Adafruit_SSD1306.h>//for oled
#include <EEPROM.h>//i store a pair of pics in eeprom, read from there and print, all ok
#include “Arduino.h” //i think this one is for deep sleep, haven’t implemented yet
#include <avr/sleep.h> //same
#include <PWMFrequency.h> //change pwm frequency on pin
I have a pretty large program that does some computations, runs animations on screen. The whole program takes around 8-10s, but there is some drawwork and a bit of brainy thing.
It powers up, shows logo, then it runs some stuff while animating progress bars, then in the end it has a screen with the result of computations. I have 5 possible outcomes for the final screen (like for example good, bad, very bad etc). Only one outcome runs each time the program runs, depends on what it read on analog pins.
If I program only one outcome and comment out all other ones, all is fine.
If I program two outcomes and comment out the other three, then the longer string of code I display.println(“String”), the more noise I get on the bottom right of the screen DURING THE WHOLE PROGRAM RUN FROM THE START FROM THE LOGO SCREEN. So the function that’s basically called last in the program corrupts the picture from the start of the program. And that 2nd outcome may even never be called because the program may have another outcome, yet picture is corrupted during the whole process regardless.
Things undertaken:
0. Wiring checked. Another screen from another source tested. Tried nano and breadboard 328p. Same thing. Power consumption of the breadboard thing never exceeded 30mA (it’s mainly send pwm - filter - measure stuff, compare, repeat several times). The program takes around 60% of memory and variable space (not at hand at the moment, but it was like 61% and 55% or something)
- The longer the string I print on the last “slide” (2nd possible outcome, other outcomes commented out atm) - the more noise (just a pair false pixels if I write “OK”, corrupted area of like 20x10 (no way to measure) if I write “text text text text OK”
- If I print even longer string, the MCU reboots every second or so (serial output confirms it, the display blinks with the last picture on it). But it’s totally programmable. Problem stays without using serial or even serial.begin().
- If I add 3rd possible outcome slide, MCU starts rebooting every second similarly to as if I printed long string in 2nd outcome.
- If I try to make a bitmap drawing instead of text, same thing occurs. The more pixels I draw, the more noise. Until it hits “critical mass of text” and sends the mcu into previously described bootloop. At other times (seems random for every time I program it) the program freezes before it has to draw a bitmap (never froze with print text output attempts).
So, to put it short, my program looks like this
START
LOGO - corrupted bottom-right corner of the screen
PROCESS ONE w ANIMATION - corrupted bottom-right corner of the screen
PROCESS TWO w ANIMATION - corrupted bottom-right corner of the screen
PROCESS THREE w ANIMATION - corrupted bottom-right corner of the screen
outcomes:
OUTCOME 1 SCREEN - corrupted bottom-right corner of the screen
OUTCOME 2 SCREEN - if I display.println here. No print/draw - no corrupted pixels anywhere, all cool |(corrupted corner is here if printed as well)
/OUTCOME 3 SCREEN
OUTCOME 4 SCREEN
OUTCOME 5 SCREEN/
END
This weird thing feels very counterintuitive, and I have no idea what the problem could be. I would be very grateful if you could throw in any ideas. So far my only idea is to unpower the display before the outcome screens and reconnect to it, will be able to try it in a pair of days when i get the pcb where I have a mosfet on a display power line.
