Bebugger breaking with no breakpoints set

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using S7.0.1645, the target is a mega169 (not a Butterfly board!) and the debugger is AVR Dragon. In general, things are working OK, but I started having an odd problem. With no breakpoints set, I'll start debugging, and when I push a switch that generates a PC interrupt on PORTE, the program "breaks" in the interrupt function, even though no breakpoint is set. What is odd is that the timer2 interrupt doesn't do this, just the PCint on PORTE. It's as if the debugger still has a breakpoint set somewhere, but it is not displayed.

I tried closing the app and restarting, same result. If I disconnect the debugger and run the proto board standalone, the firmware runs normally.

Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I realized I should be more clear - when I said "app" I meant Studio 7, not the application I'm developing!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have seen my Atmel ICE hit phantom breakpoints.  I think they usually are breakpoints I've had set previously,

 

I think I solved the problem by cycling power on the Atmel ICE and the AVR,  and killing and restarting Studio.  Also I make sure the Atmel ICE reloads the software in the AVR.  I also do some cursing.  I'm not sure what fixed the problem.  I'm using Studio 7.

 

I don't remember this happening with my JTAGICE 2 and Studio 6.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:

I have seen my Atmel ICE hit phantom breakpoints.  I think they usually are breakpoints I've had set previously,

 

I think I solved the problem by cycling power on the Atmel ICE and the AVR,  and killing and restarting Studio.  Also I make sure the Atmel ICE reloads the software in the AVR.  I also do some cursing.  I'm not sure what fixed the problem.  I'm using Studio 7.

 

I don't remember this happening with my JTAGICE 2 and Studio 6.

Well, at this point, after setting/removing/disabling breakpoints, restarting S7 and cycling power, I seem to have fixed the issue for now. Hopefully, it won't keep happening. I did find that when I hit one of the "phantom" breakpoints, if I disabled it (rather than delete it) and run the debugger, then pause and delete, that seemed to fix the problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davetelling wrote:

steve17 wrote:

 

 I did find that when I hit one of the "phantom" breakpoints, if I disabled it (rather than delete it) and run the debugger, then pause and delete, that seemed to fix the problem.

Thanks for reminding me about that.  Now that you mentioned it, I think I found the same thing.  I guess I should put a note on my Atmel ICE.

 

It would be nice if we had a forum for reporting this stuff to Atmel.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now, doesn't one need to know the breakpoint mechanism used by the particular combination of AVR model and ICE model?  Aren't some breakpoints done by rewriting the flash page to "jump to breakpoint handling" when hit?  So, if you e.g. tun off power or otherwise reset the AVR then isn't the flash page still "corrupted"?  And when you start a new debugging session, it may well hit that spot.  Steve's and Dave's anecdotal workarounds would fit, right?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A test of that would be to read out the flash and look for BREAK opcodes.

Last Edited: Thu. Aug 16, 2018 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder if the OP uses C++ like I do.  That could explain why most people don't seem to have this problem.