I am writing a fairly complex project for the nanaoatmega328 and wanted to try the static code checker using Home->Inspect. When I press “Inspect” for my environment, it looks like a normal build is started and my source files are compiled normally after the dependency check is done. But after compiling, I get this:
Doing an initial search, I rarely found ASM error popping up, e.g.
here, so I am a bit confused. Could one of the libs I am using create it?
Infact a debug build (-Og) is started, and probably some code doesn’t like it when it isn’t built in optimized mode.
Add the line (docs)
build_type = debug
to the platformio.ini and then build it.
The same error should appear, but in a bit more readable form. Can you post the output?
If it’s just about code inspection and not memory sizes, turn off “Inspect memory” as a crude workaround.
But otherwise we would of course be interested in what AVR/Arduino code is causing a debug build failure.
1 Like
Yep, your prophecy turned out 100% correct (I used pre-debug button
because I like GUIs

)
I think I’ll do some deep-dive into this tomorrow. Unfortunately, as the linker fails in firmware.elf, I don’t even know which file it doesn’t want to eat. Can I somehow decode the cryptic cc8IFU2J.s thingy?
Argh, the SoftwareSerial library that I use looks suspiciously similar to the error/solution description I found, linked in my first post.


Meh, it’s some temporary intermediate assembly listing. But if you look in C:\Users\Max\AppData\Local\Temp (or Windows + R → %temp% → Enter), that file is maybe there. The function / symbol name around lines 589 and 651 should give a clue where it fails.
But since you show have the software serial library, it is almost 100% the culprit. Have you tried changing +r to +w and rebuilding?
The post also says that it’s dependent on the compiler version, have you chosen a different toolchain-atmelvar version in your platformio.ini, to e.g. a newer compiler?
Also, if that doesn’t help, one can still workaround it by explicitly enabling optimization for that function. I assume your firmware builds “normally”, in release mode, which is -Os optimization level by default. Using certain attributes / GCC pragmas, you can apply the optimization level to the function with which it compiles.
Yep, this is the solution.
I am using
Didn’t know that this is old…
I will create an issue in the SoftwareSerial github repo, maybe this is something that should be fixed there as well.