Go Down

Topic: The more text printed, the more noise on all program on I2C SSD1306 OLED 0.96 (Read 162 times) previous topic - next topic


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)
1. 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"
2. 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().
3. If I add 3rd possible outcome slide, MCU starts rebooting every second similarly to as if I printed long string in 2nd outcome.
4. 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
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
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)

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.


It sounds to me like you are out of RAM. Try it on a Mega or change your print statements to print from flash. Example:
Serial.print("Hello and Good Morning ishwyk");  with,  Serial.print(F("Hello and Good Morning  ishwyk")); will save you 29 bytes of RAM.  As I understand the compiler; all messages are put into RAM when it starts and before giving your program control. 
Good Luck & Have Fun!


Thank you for an idea!
(quick note - the program actually doesn't do any serial, just added for debugging and then commented back out)
So are you saying the whole program is loaded into RAM first? My program is very segmented (like 20 functions call each other CONSECUTIVELY - maybe stack overflow? just thought for a moment), so I thought RAM would not be an issue, because it's always short scope where I operate variables and "toss them out"... I think I just might have realized I could have overflown the stack? Function 1 calls function 2 on the last line, Function 2 calls function 3 on the last line, so I never end previous function? I guess I'll have to do some googling on optimizing RAM. It's triple frustrating considering the program is like at 95% completeness and I just need to print one of the 5 messages.

You're a massive help!

If anyone else has advice/curses, they're always welcome :)

Edit: I think I have already come up with workaround as to how to save RAM and de-dumbify my code, considering the needs and abilities of my program. But I'm still open to all sorts of advice.


Re-wrote the code to run each function in sequence one after another not to fill up the stack, enabled LTO. Problem gone. If I were a girl, I would jump onto you and kiss you (no homo)
I've had a good lesson, never encountered RAM issue before.

Thank you!

Go Up