Inspecting Memory Changes Output Files?

PlatformIO IDE
1

I am currently in the middle of porting a project that was originally built in Keil uVision to PlatformIO. I was able to bring things over with relative ease and the project compiled and built without an issue. However, the output files were not working. The code should have started with the Reset_Handler, but it was starting at a seemingly random point in code.

However, while I was troubleshooting, I used the Inspect Memory tool to make sure everything had the right address and to see where exactly the code was starting. After doing so, the output files got larger. I am currently building an elf file and a hex file. After building, the elf file is 159.3 kB and the hex file is 78.2 kB. Then after using the Inspect Memory tool, the elf file is 384.0 kB and the hex file is 87.8 kB. Not only did the files get larger, but the bigger output files work perfectly! I can reproduce this consistently.

This doesn’t make any sense to me. Does anyone know what’s going on here? What does the Inspect Memory tool do that would alter the size of the output files and make them suddenly work?

2

Does the binary work when you modify the platformio.ini environment to include

build_type = debug

(docs) ?

3

It does work. So inspecting the memory rebuilds the binaries with the debug build type? Interesting. I guess now I need to figure out why the release build type won’t work. But that at least points me in the right direction. Thanks!

4

That was my intuition, since in order to inspect memory, all debug symbols need to be there. Apparently it builds then in debug mode too (which isn’t strictly necessary, you can enable symbols with -ggdb3 with -Os optimization, too…).

A classic that I have encountered here are delay loops which Keil can’t optimize away but GCC does, resulting in no delay. Have a look at the lower half of the post Build GD32 project with Platformio - #19 by maxgerhardt. The other gotcha with variables which are modified in ISRs (or other threads concurrently) but are not marked as volatile is the other big gotcha that will hurt when GCC optimizes the code.

Other than that it’s of course hard to tell without the code, but you seem to be on the case.

1 Like