Compiler optimized program has errors

[Tobe]

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!

[waclawek.jan]

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

JW

[Tobe]

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

[Tesla DeLorean]

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

Sure the function doesn't enter twice?

[Andrew Neil]

---

@Tobe wrote:

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

---

Not true - make it static !

[Andrew Neil]

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

[Tobe]

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

[Andrew Neil]

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

[Tobe]

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;
	inputFrameCount++;
	inputWriteIndex++;
	if(inputWriteIndex >= INPUT_BUFFER_SIZE){
		inputWriteIndex = 0;
		inputOverFlow = true;
	}
	print(inputWriteIndex);
	print(inputOverFlow);
}

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.

[Tobe]

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.

[waclawek.jan]

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.

JW