Disabled breakpoint annoyance.

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

When I disable a breakpoint, the debugger will stop at this disabled breakpoint once more.  After that, the "disabled" breakpoint is really disabled.

 

This is doubly annoying to me because I'm using USB and hitting a breakpoint kills the USB connection.  Is there a way to keep the USB running when I hit a breakpoint?

 

 

I'm using Studio version 6.2.1153

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

Can you put a hit count on it? (only thing is that probably slows operation as it has to stop at the b/p anyway to check the condition so that may break the USB link anyway).

 

I'm guessing Atmel will want to know which AVR and which debugger it is you are talking about.

 

(oh and is there any change switch from the Atmel debugger to avr-gdb as the backend?)

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

I can't reproduce it now.  So you can forget about it until further notice.

 

I'm using Xmega128A4u.  I use the regular debugger.  I haven't tried gdb.

 

While trying to reproduce the problem, I managed to set breakpoints that didn't hit.  I think I can reproduce this. 

 

Set a breakpoint.  Disable the breakpoint.  When the AVR is running, right click on the disabled breakpoint and click on "Enable breakpoint".  The breakpoint will appear to be enabled, but it won't be hit.

 

I noticed another minor inconsistency.  If I left click (not right click) on a disabled breakpoint, what happens depends on whether the AVR is running or not.  When running, the breakpoint is deleted.  When stopped, the breakpoint is enabled.

Last Edited: Wed. Oct 29, 2014 - 04:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have never been able to set a breakpoint on a running AVR.

 

AFIK,   the debugger only talks to the AVR when the AVR is stopped.

It reads memory,  sets /clears hardware breakpoints, ... , evaluates expressions,  ...

 

I suggest that you set up all your hardware breakpoints before you start the app running.

 

Cortex-M0 chips can talk to the JTAG/SWD debugger while they are running.

You can watch several 'variables' in real time (if your GUI can manage it)

 

David.

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

Well David, I dunno.  It sure seems I can set breakpoints while running.

 

Running without breakpoints:

 

 

Now I click to the left of "Half_second_tick()" and wham.  A breakpoint gets set and it gets hit.  How do you explain that?

 

The CPU does sleep when there is nothing to do.  Maybe that explains it.

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

I have had a similar problem. I'm using a JTAGICE MKII (a real one, not a clone). Studio 6.2, ATmega162. Every so often I'll set a breakpoint, do what I need to do then disable or delete it only to find that the program continues to stop at the instruction the breakpoint had been previously attached to. I tried a number of things to no avail, clean, rebuild, exit and restart. Finally, fixed it though. Reset the JTAGICE MKII by turning it off then back on. That fixes it. Hope this helps.

 

Greg

 

Last Edited: Wed. Oct 29, 2014 - 06:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay Captain, I also have the JTAGICE mkII.  I'll try that.  Now sit up straight and fly right.  smiley

 

Actually I didn't power off the JTAGICE but I may have inadvertently cured it another way.  I killed Studio and restarted it.

Last Edited: Wed. Oct 29, 2014 - 06:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Powering off the MKII JTAG ICE seems to be the answer. Stopping and re-starting AtmelStudio does not help. I have concluded the break points are stored in the JTAG ICE.

 

Thank you.