Why do I miss certain things when breakpoint and single stepping functions (e.g. in CRYP or I2C)? Is there anything I can set to help this during debug?

[######]

An example is

while( (I2Cx->SR1 & I2C_SR1_ADDR) != I2C_SR1_ADDR)

breakpoint on this line means I loop indefinately, breakpoint before and after and it reads ok?

I'm using EWARM.

[Tesla DeLorean]

What part?

What does the code generated by the compiler look like? That's what the MCU runs, not the C code

Is optimization on?

Is this a CM7 part?

Is what you're doing logically correct/value?

Are things that need to be volatile, treated properly?

>>Is there anything I can set to help this during debug?

Perhaps you can instrument the code so you can understand what's happening less invasively?

[######]

Hi, thanks for replying.

It's an STM32F439.

Optimiziation is set to none.

>>What does the code generated by the compiler look like? That's what the MCU runs, not the C code

Is optimization on?

Thanks for this. I've always stepped through the C code, I'm assuming your suggestion is to step through using the disassembler instead which might provide finer control e.g. not miss the stuff. Is that correct?

>>Is what you doing logically correct/value?

In my opinion yes, i'm following the RM, and when I don't breakpoint on that line it works (ie breakpoint around the line, it catches the ADDR being SET and moves on), however if I do breakpoint on the line it doesn't work (wait in the while indicating a fault). I had a similar issue with the output FIFO from the CRYP peripheral, if I used a breakpoint when reading the data out of the FIFO it would stop.

>>Perhaps you can instrument the code so you can understand what's happening less invasively?

Sorry to ask, but can you give an example?

Thanks again for the above.

[Tesla DeLorean · Accepted solution]

>>Perhaps you can instrument the code so you can understand what's happening less invasively?

>>Sorry to ask, but can you give an example?

I mean read the values into variables and print them to a terminal in such a way you can see what the values are, in real-time, and with the natural flow of things, closer to the operational speed/expectations of the devices, and without constantly sticking your fingers in the gears.

If you have to single step your own code to unpack the behaviour and understand the logic you've already lost. The machine is running several million times faster than you can see, think or move your fingers.

Also if you look at data registers or FIFO structures from a "Debug View" this will almost certainly disturb the internal states. These are not "memory" devices, but complete state machines, with synchronous and combinational logic.

[S.Ma]

If you want clean breakpoint, as a code with test your condition and execute a NOP which you can stop. Once your breakpoint occured, reset and restart as the peripheral is probably disynchronized, interrupts pending are overdue, etc. Don t use watch window or peripheral window or live watch on hw registers as to show their value, debugger reads them and could unpend interrupts.

Sometime, create global debug variables you can observe. Sometime, use a global volatilr variable to manually activate code by nonzero its default value for debug.... few tricks like this would help in some situations.

I2C slave means SCL rythm comes from outside, responsive and latency plays their part. MCU replaces instant hw by timely SW...

[######]

Thanks for the reply.

[Pavel A.]

Yes, the debugger cannot step over certain constructs such as some one-line loops.

in this case try to step in disassembly mode.

Also remember that debugging is invasive. When the target stops on breakpoint, it can suspend certain other components besides of the core, and so on.