Sketch with compiled size >= 19482 bytes: Resets in setup

Hi all,

I have an issue running a sketch with a compiled code size of 19482 bytes on a bare Atmega328p.

Problem description:
Any sketch with a compiled code size of <= 19478 bytes runs perfect.
Any sketch with a compiled code size of >= 19482 bytes resets repeatedly within setup.
I checked on another identical device, the behaviour is the same.

Complete first code lines of my setup function:

   oled_128x64.begin(&Adafruit128x64, OLED_I2C_ADDRESS, -1);
   strncpy((char*) display_some_text, "Some Text...", DISPLAY_SOME_TEXT_SIZE);
   oled_128x64.setCursor( 0*1*6, 0); 
   oled_128x64.print("Init .");

After reset, the Arduino starts to execute setup and starts to print “Init .” on the display, but only “I” is dispayed, then the Arduino resets again.
I may share the complete code, but it is relatively lengthy and probably hard to read. I don’t use dynamic memory allocation at all and the sketch uses only approx. 10 bytes for dynamic variables (most variables are static for sake of ressource transparency)

Some details:

  • Device: Atmega328P U (cheap source)
  • Clock: 16 MHz quartz
  • Bootloader: from Arduino IDE version 1.8.9 for Arduino Uno
  • Sketch type: control 3 x Servos, 2 x VL53L0X, 1 H-Bridge, 1 x MPU-9250, 1 x 0.96"-OLED, 4 x ADC and 8 x WS2812 by USART protocol
  • Libraries in Sketch: Using Wire.h, SSD1306Ascii.h, SSD1306AsciiWire.h, VL53L0X.h, MPU9250_asukiaaa.h
  • RAM usage: 1417 Bytes (69%)

Up to now I manage to deal with the issue by code optimization.
However, it’s sad that the IDE reports a total of 32256 bytes ROM of which 60% are used, but in reality only < 19480 bytes ROM can be used effectively.

I wonder if anybody has experienced a similar issue - or has an idea how to exploit the full ROM.

Thankfully for any reply

Please post your full sketch.

All the available flash on a 328p can be used without issue; there is some bug in your code (or possibly one of the libraries - include a link to them, as there are many copies of libraries with same name but slightly different code floating around), as well as the full sketch.

What does the compile say about how much "dynamic memory" is used/available?
Getting close to maximum RAM usage can easily cause symptoms like you are seeing.
Also, out-of-bounds memory accesses can cause damage that doesn't show up "all the time."

!!! S O R R Y !!!

False Alarm.

When I encountered this issue, I reworked the code to save memory.
Now, when I increase the code size above 19482 bytes, I cannot reproduce the issue. The 328p works perfect with bigger code sizes than 19482 bytes.

So you're right, something in my sketch must have been the root cause for the issue.

Sorry again and thanks for your posts!!