Optimization in CooCox on an STM32F415VG

[jdcowpland]

Posted on July 07, 2015 at 11:49

Hi guys,

I have code that has been working great for a couple of months now on an STM32F415VG, but I added some libaries/code yesterday which took it beyond the flash sectors that I wanted it to sit in (it's a custom bootloader). I decided today to try enabling optimization to see if I could reduce the memory footprint, and it reduced it by quite a bit. However, it now no longer seems to run when I write it to the flash. I've tried disabling optimization again and even my original binary files don't seem to run (i've compared them to my backups from yesterday and they're identical). I'm using CooCox as my IDE and GNU compiler for ARM (4.8). Anyone know how to either get my code running with optimization, or how to get it back to a running state without it? #optimization

[waclawek.jan]

Posted on July 07, 2015 at 12:17

My crystal ball says you neglected to add a ''volatile'' qualifier, maybe when writing the value to the FLASH array at the very moment of programming. But you know how it is with crystal balls.

And this has nothing to do with Coocox. JW

[jdcowpland]

Posted on July 07, 2015 at 12:50

Bu then surely when I disable optimization, it should go back to working?

[waclawek.jan]

Posted on July 07, 2015 at 13:21

Probably yes, but it's still too little information.

Can you program the same piece of FLASH are from ''outside''? JW

[Tesla DeLorean]

Posted on July 07, 2015 at 17:42

Optimizers tend to stress marginal code. You may have positional dependencies. The data/static sections may extend beyond the end of the code. Things move out of the stack, and into registers. Stack utilization will change. The compiler/linker may have bugs, but you'd have to know your own code well enough, and show the assembler output is actually flawed, to convince people who matter.

At the end of the day you're going to have to debug your code, and get a better idea exactly what's failing. This might mean instrumenting your own code, checking the parameters and returned values, or adding asserts(). You need to constrain the failure, and walk back from there.