Studio 7/mega169/JTAG can't remove "phantom" breakpoints

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

I'm trying to debug a mega169 project (not a Butterfly board) using Studio 7.0.1645, and when I run with the AVR Dragon as the debug tool, the program keeps halting at a place where I had placed a breakpoint days ago. I have tried deleting, disabling, rebuilding the project, to no avail. At this point I am stumped, as I cannot get past this.

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

Do they "show" as breakpoints?

 

Have you tried "remove all breakpoints" or what ever it is called?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

ka7ehk wrote:

Do they "show" as breakpoints?

 

Have you tried "remove all breakpoints" or what ever it is called?

 

Jim

They do not show as breakpoints, and I have tried remove all.

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

Then it is breaking for some other reason (than being a standard breakpoint). I'll bet that it has nothing to do with the previous breakpoint placement. 

 

There are, as I recall, a couple of other (more rare) causes for breaks. I seem to remember, but may be wrong, that

break;

.... outside of a select block will do it. There may be something in the project dialog that is causing this to happen.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

ka7ehk wrote:

Then it is breaking for some other reason (than being a standard breakpoint). I'll bet that it has nothing to do with the previous breakpoint placement. 

 

There are, as I recall, a couple of other (more rare) causes for breaks. I seem to remember, but may be wrong, that

break;

.... outside of a select block will do it. There may be something in the project dialog that is causing this to happen.

 

Jim

Jim, sadly I do not understand what you mean here. the disassembled code has no break statements in it, and the C code doesn't, either. I can say that all the times this has occurred, it has been on a line in the source where I had previously placed a "legitimate" breakpoint for debugging.

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

All I can add at this point is that I've never had any problem with phantom breakpoints that did not have an actual (though maybe not obvious) cause.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

ka7ehk wrote:

All I can add at this point is that I've never had any problem with phantom breakpoints that did not have an actual (though maybe not obvious) cause.

 

Jim

I am sure there is an actual cause, but it is proving to be elusive! I took the function that had the phantom breakpoint, and moved it to the end of the code. The phantom breakpoint then appeared in the function that was previously just below the original function, so it's not traveling with the function, it seems to be staying near a particular area of program memory.

I just did an experiment where I moved several functions around (i.e. their position in the source) and found that the phantom break seems to occur at address  0x00000478 when looking at the disassembler. The instruction there usually seems to be a MOVW, but not always.

After trying this technique several times, I found that the phantom break no longer occurred. Looking at the same memory location, I saw that it now contained a subroutine call, instead of a move or load instruction. No idea why this happened.

Very frustrating!

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

Jim is wrong about break:
.
That usually just just compiles to some kind of RJMP to jump out of a loop.
.
An asm(" BREAK") would be something else, that would encode an opcode that would cause the debugger to break.

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

OK, I mis-remembered the use of "break". Mea Culpa.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

This problem plagues me as well, and code stopping on "non-existing" breakpoints is a YUGE nuisance in code that's handling an incoming bitstream.  I cannot dependably toggle breakpoints off, cannot disable them, cannot delete all or any individually, no matter how I do it.  Only workaround is to break the debug session and re-start it after deleting all, offline.  Sometimes execution breaks on "non-existing" breakpoints of unknown origin, seemingly at random.  At least 80% of the breakpoints I delete using delete all remain active, but invisible.  The problem is costing me a long ton of time.

 

I'm using Atmel Studio 7 with the toolchain below.  The appl is a mix of C and assembly, and I have not seen the problem in any of the assembly files.  The device is an ATTINY416 nano (using its native debugger).

 

As always, all commentary and advice is gratefully received.

 

Jeff

 

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

Followup - I just had exactly the same problem two weeks ago. I had to do a power off reset of the target, power down the programmer/debugger, and restart AS7. It happened after the system had been running continuously for several days. Neither individual clearing of the phantoms nor "remove all" had any effect.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Mar 16, 2019 - 11:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad it's not just me.  When you say "the system had been running..."  do you mean the dev box? Or, do you mean the dev platform (i.e. AS7 and the target board)?  This happens to me even even immediately after starting a new instance of AS7.  I have been compiling with -Og (the tn416 is 83%+ full), so I tried to build with -O0 for improvement and it won't even link.  No descriptive diagnostics, just "Build FAILED" (still working on that though)(if it runs out of progmem it says so).  But yes, separate issue.

 

This debugging bug is significant and it has to be in the IDE.  The workaround, which is barely that, is an onerous productivity destroyer.  I began using AT7 only recently, and I don't yet know what to expect from the owner of the product given Microchip's tangled family tree.  Do they release patches?  Or regular updates?  Do you think this will be addressed?  Is there some specific way it must be escalated into the bug list?  "The community" cannot fix these bugs.  AT7 could be great, but it's riddled with bugs, which I needn't go into here.

 

I appreciate your help Jim - thank you 8)

 

Jeff

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

Ned Zeppelin wrote:
Is there some specific way it must be escalated into the bug list?
Microchip/Atmel support page | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

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

I had all of this running:

 

1) My dev board target

2) Atmel Dragon Programmer/Debugger powered from USB hub and connected to target.

3) Saleae Logic Analyzer powered from same USB hub and connected to target.

4) USB hub powered from the  host

5) Dell laptop host running current Win10 and TeamViewer and AS7 and Salaea Logic program

6) iMac desktop linked to host vial TeamViewer so that AS7 and Salaea LA are visible in another location.

 

It ran probably 36-48 hours continuously. When I did a break-all, I cleared all of the breakpoints using delete or remove all breakpoints. When I reset the target via the debugger, then did continue, it hit a former breakpoint that had been erased and stopped as if at a standard breakpoint. This was repeated on several other former breakpoints. Further attempts to remove the former breakpoints individually did not remove those, either.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Mar 18, 2019 - 05:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jim,
I doubt if your hardware would make any difference.
AS7 keeps a list of your Breakpoints. It should be able to clear one or all Breakpoints from its list.
Hardware Breakpoiints are different in debugWIRE or JTAG.
It seems unlikely that a stray command has somehow got to ATMEL-ICE or AVR.
.
If you can reproduce this problem, please ZIP up your project and attach.
As far as I know AS7 reloads Flash memory, Breakpoints and resets debugger with a fresh Debug or Restart.
.
Morten could confirm the behaviour. I am just guessing.
.
David.

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

We've logged a bug on this for investigation...(AVRSV-8180)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Unfortunately, I can't afford the time (say 2 days of continuous operation) to replicate the conditions of the problem.

 

I do know that I requested a break-all, then tried to clear all the breakpoints; the markers in the left margin of the code viewer did go away. When I reset (after that break-all), then continued. it stopped at the first breakpoint that HAD been present. The code viewer highlighted that line with yellow but there was no indication (by color, margin marks, etc) of the presence of a breakpoint. It just stopped. When I continued, it stopped again at another former breakpoint.

 

Given the fairly extreme conditions to get this to happen, I am going to let it pass for now.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

I don't know how much of Microsoft is involved in this but just to say I used to see this multiple phantom breakpoint thing a lot in VS2010 and still do now I use VS2017 daily.

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

workarounds (disable breakpoint, child breakpoint?) ?

debugging - Visual Studio refuses to forget breakpoints? - Stack Overflow

 

"Dare to be naïve." - Buckminster Fuller

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

" The problem is that child breakpoints of your breakpoints persist. Child breakpoints are created (in certain situations) when setting breakpoints during a debug session " Yup that describes what I see in 2010/2017. It's when there are "child" breapoints (a tree diagram "+" shown next to the entry in the Breakpoint list") You need to delete the "parent" not just one or more of the children.

 

In that SO question/answers it's a real shame that the link: https://connect.microsoft.com/Vi... has died as I would have liked to have seen M$'s justification for the behaviour. Maybe I'll find it on the "way back when" machine...

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

just my 2 cents,

I do not use a debugger, so never really played with setting breakpoints but it seems to be a m$ visual studio thing then and not an AS7 shell thing.

I wonder if these things are not maintained in a separate text file somewhere on the PC as I can not imagine these things will be stored in the registry, so they should be in an external file, that actually belongs to the project.

Why that.... because else once you set a breakpoint and it becomes a ghost you would have a problem with it in every project you run not just the project were it was created in. Now if that were the case I think it would have been flagged here already much earlier.

 

I wonder if Morten knows at what location these things should be stored.

I do know that in my my-docs folder there is an AS7 folder that holds a number of files with part of the name being ' settings'

Also there is a section on AS7 in 'appdata'  ( a normally hiddenfolder) were a lot of files reside.

 

Now I do not know if the info is in there somewhere, but that should become clear if you play with setting and removing break points and then doing a run. It should safe the files were the breakpoints are residing so it might be that you can in that way find the location of and remove these ghost breakpoints.

 

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

They are stored in the suo file next to the solution or project file, or in the .vs folder. IT is safe to delete that file, as it only contains 'workspace information'.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Hi Morten, 

 

After a lot of Googling... Your suggestion of removing the ".vs" directory has solved my issues with phantom breakpoints.

 

Many thanks,

 

Paul.

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

Still no joy. Tried a variety of things, including deleting the .vs folder under different circumstances (app running and not running) re-starting app, re-building, reloading the project, to no avail. I finally tried disconnecting the debugger (AVR Dragon on JTAG), re-starting the app and re-loading the project, and the phantom breakpoint went away, but that level of clumsiness is not acceptable. There has got to be a better way!

 

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

If you want to ZIP up your project and PM it top me I can see if I run into the same issues here on my kit.  Project will be deleted afterwards.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:

If you want to ZIP up your project and PM it top me I can see if I run into the same issues here on my kit.  Project will be deleted afterwards.

 

JIm

Jim, I don't mind doing that, but the problem is that there seems to be no consistently reproducible way to cause this. For example, since my last post, the debugger has run flawlessly. However, FWIW, I also noticed that one particular issue I was trying to debug (I'm reading some switches and using those data to determine program flow) was intermittent when running the debugger (i.e. it would work correctly multiple times, then suddenly act as if it was not reading the switches. If I inserted a breakpoint in the interrupt handler, it always worked. I subsequently found out that if I just ran the development board standalone, it always worked, so this makes me wonder if there is some odd interaction in the debugging process. I was running the JTAG clock at 200 KHz (with a 1 MHz system clock), and just for fun, slowed it down to 90 KHz, and the function ran without a hitch. Does that give you any clues as to what might be happening? I'll PM the project to you.

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

davetelling wrote:
I was running the JTAG clock at 200 KHz (with a 1 MHz system clock), and just for fun, slowed it down to 90 KHz, and the function ran without a hitch.

megaAVR Special Considerations | Atmel-ICE

JTAG clock

[debugging : JTAG frequency < CPU frequency/4]

When using the internal RC oscillator, be aware that the frequency may vary from device to device and is affected by temperature and VCC changes. Be conservative when specifying the target clock frequency.

 

"Dare to be naïve." - Buckminster Fuller