How to use custom debug_build_flags per file

Hello everyone,
I am working on a program that is getting pretty big, and it’s causing some issues when building in debug mode.

I am using a Controllino Mega (Atmel 2560) and I have an ATMEL-ICE attached to it via JTAG to do some debugging using Microchip studio (PlatformIO does not support Atmel2560 JTAG debugging via the ATMEL-ICE AFAIK).

So long as my program was reasonably small, this worked fine when building with:
"debug_build_flags = -O0 -ggdb3 -g3 ".
Now that my program is getting bigger, I end up with 60% RAM used after compiling and less than 1k when running the program, and this is now resulting in undefined behavior. I would like to only compile some files with full debugging info and compile all other files like normal. I know how to do this in other IDES, but I have not been able to figure it out in PlatformIO. I know you can use a Python script to achieve something like this according to the official docs, but I don’t understand how to apply this to my particular problem. If anyone could point me in the right direction, I would be very grateful.
Thank you

This should be equivalent Granular optimisation settings - #2 by maxgerhardt.

1 Like

This does look like exactly what I need! Sadly, this produces a new error:

Now when building the linker can’t find ANY of my header files. I had this problem once before with this project and fixed it by adding: “lib_ldf_mode = deep+” to my plattformio.ini, but it seems that this is not helping rn.

My platformio.ini looks like this:

platform = atmelavr
board = controllino_mega
framework = arduino
monitor_speed = 115200
build_type = debug
lib_ldf_mode = deep+
extra_scripts =

;debug_build_flags = -Os -ggdb3 -g3
;debug_build_flags = -Og -g
;debug_build_flags = -O0 -g3
;build_flags= -fstack-usage -Wstack-usage=8000

lib_deps =
controllino-plc/CONTROLLINO @ ^3.0.7
br3ttb/PID @ ^1.2.1

And my folder structure is like this:

|…|…- sensor.hpp
|…|…- sensor.cpp
|…|…- main.cpp

The resulting error message when trying to build is:

Verbose mode can be enabled via -v, --verbose option
PLATFORM: Atmel AVR (4.1.0) > Controllino Mega
HARDWARE: ATMEGA2560 16MHz, 8KB RAM, 248KB Flash
DEBUG: Current (avr-stub) External (avr-stub, simavr)

  • framework-arduino-avr @ 5.1.0
  • toolchain-atmelavr @ 1.70300.191015 (7.3.0)
    LDF: Library Dependency Finder → x
    LDF Modes: Finder ~ deep+, Compatibility ~ soft
    Found 16 compatible libraries
    Scanning dependencies…
    Dependency Graph
    |-- CONTROLLINO @ 3.0.7
    |-- PID @ 1.2.1
    |-- interface
    |-- errorHandling
    |-- config
    |-- SPI @ 1.0
    |-- util
    |-- statemachine
    |-- dilumix
    |-- actors
    |-- sensors
    |-- UART
    Building in debug mode
    Compiling .pio\build\controllino_mega\src\main.cpp.o
    Compiling .pio\build\controllino_mega\lib638\SPI\SPI.cpp.o
    Compiling .pio\build\controllino_mega\lib162\CONTROLLINO\Controllino.cpp.o
    Compiling .pio\build\controllino_mega\lib4d5\PID\PID_v1.cpp.o
    Compiling .pio\build\controllino_mega\lib7b5\util\PID.cpp.o
    Compiling .pio\build\controllino_mega\lib7b5\util\analogRead.cpp.o
    Compiling .pio\build\controllino_mega\lib7b5\util\filters.cpp.o
    Compiling .pio\build\controllino_mega\lib7b5\util\stableCycleTime.cpp.o
    src\main.cpp:1:10: fatal error: CInterface.hpp: No such file or directory
    Compiling .pio\build\controllino_mega\lib7b5\util\timer.cpp.o

  • Looking for CInterface.hpp dependency? Check our library registry!
  • CLI > platformio lib search “header:CInterface.hpp”
  • Web > x

#include “CInterface.hpp”
compilation terminated.
Compiling .pio\build\controllino_mega\lib104\actors\actuonixP16.cpp.o
In file included from .pio\libdeps\controllino_mega\CONTROLLINO\Controllino.cpp:17:0:
.pio\libdeps\controllino_mega\CONTROLLINO\Controllino.h:23:10: fatal error: SPI.h: No such file or directory

  • Looking for SPI.h dependency? Check our library registry!
  • CLI > platformio lib search “header:SPI.h”
  • Web > x

#include “SPI.h”
compilation terminated.
Compiling .pio\build\controllino_mega\lib104\actors\dcMotor.cpp.o
Compiling .pio\build\controllino_mega\lib104\actors\valve.cpp.o
.pio\libdeps\controllino_mega\PID\PID_v1.cpp:14:10: fatal error: PID_v1.h: No such file or directory


I am not sure whether it has something to do with how my file structure is or if I messed up something else…
PS I had to break all links by putting an “x” before them since new users can’t post more than two links, apparently.

But the problem immediately goes away when you comment out the extra_scripts = line?

Yes, sorry, I should have added that.
It works flawlessly without the extra script but throws errors if I try to use it. I suspect it is the same error again that I originally “fixed” by adding the “deep+” option, but now that the files are treated differently I think the linker once again cannot find the files. Probably, I have to fix the underlying issue that caused this in the first place, but I have no idea on how to do that other than with “deep+”.

Yeah so this is actually minimally reproducable with even a pass-through of the original object wrapped in env.Object().


def exchange_debug_for_optimize_flag(node):
    print("Node %s env.GetBuildType()=%s" % (, str(env.GetBuildType())))
    # pass through
    return env.Object(node)

if env.GetBuildType() == "debug":

So either PlatformIO has a bug here that destroys the library dependency finder or the documenation is wrong:

It does work fine with a very direct return node though, but of course that doesn’t let one modify its compile settings…

That is quite interesting, but I still suspect I made some stupid mistake and broke the dependency finder in a different way and now because we are using the script to modify the files it is once again broken.
I know PlatformIO does not treat all folders the same and depending on where you store what code it gets compiled differently. Sadly, I don’t understand the details well enough to be sure I am using the folder structure the way it is intended. This solution does seem to work for other people so I am a bit hesitant to call it a bug when the problem is more likely located somewhere between keyboard and chair…

No, I’m very sure this bug is in PlatformIO. I was able to reproduce it in an absolute minimalistic setting and opened

This could only work where the code did not depend on libraries (at least from lib/).

1 Like

Holy crap…
Thanks a lot !