Showing results for 
Search instead for 
Did you mean: 

Compiler optimized program has errors

Senior III

While trying to debug a problem, it seems that another one is giving me a hard time.

One function call is not shown, another has the wrong name ("writeFLASHDoubleWord" should be "waitForBusy").

The breakpoint is also missed.


Originally the code worked, but then i moved to the new prototype. I copied the project, and made a few minor changes. Mainly just the pins.

I had some hardfault before, which happend seemingly at "CLEAR_BIT(FLASH->CR, FLASH_CR_PG);" after writing FLASH. But after seeing the above, i doubt this!


You can use data breakpoint (watchpoint) to find out, where does a variable get written.


No, the debugger wont really work with O2. The program runs fine with Og. This is quite an annoying error.

Likely not the issue, but using uint8_t for an index doesn't provide any efficiency 


Sure the function doesn't enter twice?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

@Tobe wrote:

The value has to persist, so it has to be global.

Not true - make it static !

Have you tried it (data breakpoint/watchpoint)  ?

The debugger still has full access to the chip's resources - it's mostly lining up source lines to executable code where the problem happens

I cant think how it then would work to set breakpoints at the right places...

The suggestion was to set data breakpoints - ie, on the variables

If the breakpoint dont "break" where they should, its not possible to debug really isnt it?

I had now printed the value of the variables:

	lastBusActivityMicros = nowMicros; //TODO: DELETE VARIABLE (is not used)
	inputBuffer[inputWriteIndex].timeMicros= nowMicros;
	if(inputWriteIndex >= INPUT_BUFFER_SIZE){
		inputWriteIndex = 0;
		inputOverFlow = true;

The counting of the inputWriteIndex counts as expected, and the overlow is only true, when inputWriteIndex is 1.

How in the world is this possible? Im getting crazy.


Another new finding:

The last 3 print lines are executed 2 times immediately after each other. The arrow shows the delay, that comes after those 3 lines.

See picture attached.

I've just looked at the timestamps in that screenshot in the 2024-03-19 11:54 PM post, and they are consecutive.

It means, your conclusion that the index is incremented by 2 is incorrect.

What IMO happens is, that the messages are buffered in the CAN controller, and you read them out incorrectly/late/in incorrect order.