Different binary data when running directly

[Nickelgrass]

Hello,

I have a strange problem that I already lost a lot of hair over. 

I am using cubeIDE with an stlink v2 (STM32G441 with a blank C/C++ project and CMSIS). 

All run very well until today. So I am sure the code itself is ok.

If I compile the project bin and elf files are generated. If I flash the generated files from the release folder with cubeProgrammer the program does not run. 

If I choose the run setting directly in cubeIDE the program runs fine. If I then read out the flash with cubeProgrammer the bin file is different from the one that was compiled in the release folder. 

So cubeIDE is running a different bin file than the one it generates in the release folder. How can that be? What am I missing here? This started out of nowhere. I can not recall changing anything other than the code itself. But of course I must have botched something up. I just don't know what could cause this.

Edit: the generated bin file in the release folder is much shorter than the one I read out of the flash. So it seems that the problem is that the debug file works while the release file does not. 

Edit: ok the program runns if I choose optimization for speed and not size. So I guess the optimizer generated something that did not work. 

[Pavel A.]

[removed]

[MM..1]

You mix many bad info. 1. binary data loaded into MCU is equal, when you load same build config.

2. optimized code builds not work when is errors in your code.

3. debug and release have after project setup different build config setups

4. CubeIDE can have many configs defined on project not only Debug and Release, but you choice what is build and load...

[Nickelgrass]

Thanks for the replies. 

Yes, it was an issue with different optimization in debug and release. The optimize for code size does not work. Optimizing for speed works. I do not know why or how to debug this. But as long as the release with speed optimization works its ok.

[Tesla DeLorean]

Most likely latent errors that optimization exposes.

Pay special attention to variables that need to be volatile, and you check them in one loop, vs change them under interrupt or call back.

Stop in the debugger, or instrument to understand flow, etc. Perhaps in SysTick interrupt print the return address once a second, or make a small table/log of the most frequent addresses, might pin-point a specific loop.

Make sure Error_Handler() and HardFault_Handler() output actionable data to see if they are stuck in those loops.

[Nickelgrass]

I could not resolve the problem cause so far. I will have to dig a bit deeper when I have the time Thanks for all the replies.