• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 392 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Strange debugger behavior

Mario Lepage
Prodigy 30 points
Other Parts Discussed in Thread: MSP430F5171

Hi,

The setup:

-Our own board with MSP430F5171.

-20MHz ceramic resonator.

-3.3V power supply.

-Spy-bi-wire programming and debug interface with MSP-FET430UIF.

-IAR 5.51.6 C compiler.

-Everything working perfectly both in Debug and Standalone mode except the "Strange behavior" described below.

The "Strange debugger behavior":

We configure the WDT with "WDTCTL = WDTPW | WDTSSEL__ACLK | WDTCNTCL | WDTIS__8192K;", compile and load the application to the MCU.

The debugger starts and halts on main() as expected, then we set a breakpoint somwhere in the code(anywhere after the init() routines) and hit RUN. The code runs perfectly, executing our clock, io,  and peripherals init() routines then eventually reaches the breakpoint and stops the cpu. So far so good BUT, at this point all ios have been reset to high impendance inputs and the SYSRSTIV register shows 0x16(WDT timeout). What's very strange is that we can step out of the breakpoint and continue the execution as if everything is ok. We,re lost... Does anyone have an explanation?

Thanks

  • 0
    Guru 227245 points

    Mario Lepage said:
    hen eventually reaches the breakpoint and stops the cpu.

    And if you didn't configure the debuger to stop ACLK, then teh WDT will timeout before you even see on screen that the breakpoint has been hit.

    Mario Lepage said:
    What's very strange is that we can step out of the breakpoint and continue the execution as if everything is ok.

    Probably, it's the debugger that sets the PC to where you hit the breakpoint. Maybe it is too smart here.
    Yes, sometimes the debugger can be a real bugger.

  • 0 in reply to Jens-Michael Gross
    Guru 35565 points

    Jens-Michael Gross said:
    sometimes the debugger can be a real bugger

    Excellent - I'll use that one!

  • 0 in reply to Jens-Michael Gross
    Prodigy 30 points

    Thanks for the reply Jens-Michael. It's just a little frustrating to know that we are not 100% in control of our tools but at least now we know we're not alone. Just so you know, we have tried a lot of different WDT configurations and debugger clocks control options, we have read all the relevant documentation, and searched extensively on the forums. We have spent a lot of time on this so for now we'll just let go and go on with our project. Thanks again for your support.

  • 0 in reply to Mario Lepage
    Guru 227245 points

    Mario Lepage said:
    It's just a little frustrating to know that we are not 100% in control of our tools

    Well, between the debugger and the MSP, there's Windows, an SUB stack, an USB->ser converter and the FET. So timing is the least thing I'd expect to be accurate and tight when using the debugger. Even if the debuger would be bug free. Unfortunately it isn't, and the clock control has shown soem ugly quirks in the past.

    Things like this happen if you have an existing design and then have to patch on it to add more features. Sooner or later you'll get into trouble as the new features cannot integrate smoothly into the old concept.

    It has a reason why ICEs for other MCUs are big expensive hardware. Now the primary goal with MSPs is not that they are easy to debug but that they are efficient in the final product.

    Woudl you believe that I never (!) used a debugger on an MSP? (mainly because my first MSP projects were related to external real-time signals, including radio signals, which a debugger couldn't sotp and signle-step at all).
    I extensively use one on Flash and C++ development, but never on MSP. Some debug code and an I/O pin with a scope attached gives a way better realtime response.

  • 0 in reply to Jens-Michael Gross
    Prodigy 30 points

    I completely agree with what you say, however from my perspective this is not a "realtime" related issue. Thanks again.

**Attention** This is a public forum