Flash [checkprogsize] error on debugging with simavr, compiler options won't help?

I have a weird initialization order fiasco (at least it looks like that) that I wanted to solve using the Debugger. I’m new to that tool so when I pressed the “start” button, I got the following error:
I thought that’s a quick one as a “release” compile would give me smaller size but even with compiler optimization set to -Os (optimized for size) would still give me near 130% which is why I cannot debug :cry:
I assume I cannot reduce size more because the debugger just needs the symbols. Just a bit disappointing as for complex projects flash useage of >50% “release” mode will most likely kill any try for a debug session.

Are there other Ideas I could try? My UnitTests are fine and the Inspector also tells everything OK (well, apart from size…) Else, I’ll go down the long and painful road of printfs.

And you controlled that via the debug_build_flags, not the regular build_flags?

You can also try and reduce the size of your firmware by cutting out your libraries / logic.

Yep, did that. image
To track down the segfault I wanted to keep all objects/libs in place. But maybe it’s quicker to remove them one by one than going through the println hell.

This still says build_flags and not debug_build_flags. I’d suggest debug_build_flags = -Os -ggdb3.

Whoops :sweat_smile:
But still

And it just got bigger :rofl:

What are the results for the size when you do a normal “Build” when you add

build_type = debug


build_type = release


They should be the same size if the debug build flags are correctly applied…

Yes, they are, used in [env:nanoatmega328]

I mean the bad way. As soon as I set my normal build environment to debug, it will produce ~50% larger builds.
When I set it back to release I’ll get the “normal” results

Then I don’t see why this shouldn’t work if they now both build in debug mode.

Please try the following: Keep the line build_type = debug in the platformio.ini in the project an build it once. It should go through.

Then choose the “PIO Debug (skip pre-debug)” option in the unified debugger as the configuration.

This works for me.

The firmware that is built there has the exact same size as in the release configuration.

RAM:   [==        ]  21.7% (used 444 bytes from 2048 bytes)
Flash: [==        ]  21.1% (used 6814 bytes from 32256 bytes)
1 Like

So what flash size do you have when you build it with release? Should be noticeably smaller due to the symbols not being built. I’m slowly starting to think that this is the way it is, and will start manual debugging tomorrow. Thanks for your extremely quick and engaged help!

When building with

platform = atmelavr
board = uno
framework = arduino
RAM:   [==        ]  21.7% (used 444 bytes from 2048 bytes)
Flash: [==        ]  21.1% (used 6814 bytes from 32256 bytes)

when building with added build_type = debug

RAM:   [==        ]  23.1% (used 474 bytes from 2048 bytes)
Flash: [===       ]  26.1% (used 8414 bytes from 32256 bytes)

(+1600 bytes in flash, +30 bytes in RAM)

When further adding debug_build_flags = -Os -ggdb3

RAM:   [==        ]  21.7% (used 444 bytes from 2048 bytes)
Flash: [==        ]  21.1% (used 6814 bytes from 32256 bytes)

back to the release size. This is practically the “Release with debug symbols” option.

1 Like

I must make a mistake here. Does it really build in [env:debug] when I hit the button? image
It somehow builds without optimizations. Will look into that tomorrow, your post shows there must be a solution for this.

Found it!
Both “Inspect” and “Debug” options by default DO NOT use [env:debug] but instead use the normal release environment, for me in this environment this is [env:nanoatmega328] so when I add the debug build flags while keeping the build_type = release like this image
Then the result is both a working inspection without [checkprogsize] error AND a working debugger on simavr!

Only remaining open question: why does [env:debug] neither affect Debug nor Inspect by default and how do I change that?

I don’t think PlatformIO is lookking for special environment names. Debugging might take the first available environment, so make sure it’s placed first or use default_envs.

1 Like

Yeah, assumptions might turn out wrong in the end :slight_smile: Thanks for your help with this!
Anyways, how can I link an application like Debug or Inspect to a custom [env:xxx] ?