cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Behavior different when on debugger

kaustubh
Associate II
Posted on November 07, 2013 at 15:44

Hello all,

Recently I came across a puzzling situation. I have a system that behaves differently depending on whether I am debugging the application or running otherwise. 

My environment

1) STM32F103x running at 8MHz

2) IAR jtrace debugger 

3) IAR Compiler for ARM

Some specifics

I have a timer configured in up counting mode with the update and one compare interrupt enabled. I use this timer to control some LEDs in a very elaborate pattern. 

What I see is that the behavior of the LEDs is perfect when I operate within the debugger; what happens in normal runtime is a completely different story. The LEDs show some strange artifacts in their pattern that _should_ not be there. 

What I have considered:

1) I can perhaps imagine the debugger introducing lags and fixing some strange race condition that there might be in normal operation.

2) I have measured the system ticks every time the timer interrupt fires to see if there is a difference depending on whether the debugger is present or not, but I have not seen any there.

Have any of you experienced anything like this ?  Any suggestions on how to go about debugging this where I cannot trust the debugger ? 

Thanks,

E

#stm32-debugger-behavior
3 REPLIES 3
Posted on November 07, 2013 at 17:44

Any suggestions on how to go about debugging this where I cannot trust the debugger?

Use a serial port, output telemetry, write a monitor app.

Dump out the state of peripheral registers and clock settings, in working vs non-working state, compare/contrast.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
jj2
Associate II
Posted on November 07, 2013 at 22:02

Sounds to this reporter like your debugger's connect is more correct/trustworthy than your, ''free run results.''

Beyond Clive's guidance - might your board (inadvertently) rely upon the JTAG probe for certain critical, ''pin load'' or input termination?  Are all of the JTAG pins properly pulled-up, is the treatment of all Reset pins proper - even (and especially) when the JTAG probe is removed?  

Longer shot - might your board be, ''at the margin'' for power - and thus aided by any phantom power supplied via your debug probe? 

And - as always - does this condition continue across multiple boards?  And across a different debugger?  (wager xx USD this is board issue - not debugger...)

s_
Associate III
Posted on November 08, 2013 at 10:56

One scenario where debug differs from non-debug is if the device is going into one of the low power modes where the clocks are stopped.

In non-debug, the clocks will be stopped as per the documentation.

However if a debug session is active then the clocks will continue to run (as they are required to keep debug working).