PARTLY SOLVED: Cannot set breakpoints.

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

Hello, I changed from AVR Studio 4.18 to 6.1 and I don't seem to be able to set breakpoints any longer. What happens is when I click at the beginning of the line I get a message: "The breakpoint will not currently be hit. Unable to set requested breakpoint on target. Note: The current selected device is unable to set breakpoints during runtime." This applies to every line in every source file (I am assuming that but believe me: I tried enough lines). I am using a JTAGICE2 (genuine Atmel) and the CPU is an ATMEGA1281. Optimisation is off. Debug information is included in the ELF file. The CPU is stopped at the time I see this message. The build process is the same as before for 4.18. I can single step fine and when I stop the program the correct source file and line is displayed. The only thing I could think of is: I load the ELF file and the source files are residing in a different directory structure but I resolved all that at startup. Is there a problem when the source files are not as per ELF file path? And why does Studio 6.1 say the target is running?

This topic has a solution.
Last Edited: Mon. Apr 6, 2015 - 06:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found out more.

When I use "Set breakpoint on function" a breakpoint is set, shows in the source file and it works on the hardware. When I go to the disassembler view I can set and delete breakpoints and they show properly in the corresponding C file. But when I click on the line in the C file view the breakpoint is being deleted but clicking again does not set the breakpoint and I get the same error message again.

Any ideas, suggestions, hints? Which one of the 2000 tick boxes in the 150 submenues of the "Options" dialogue have I missed?

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

Are you using -relax?

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

no. Is that the magic word? If yes, why does the same ELF file then work in AS4.18?

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

I'm sat here right now using 6.1.2730 and a JTAGICEmkII and when it will actually connect (about 1 in every 3 times I start AS6) then after that all debugging works as expected. So there shouldn't be an issue except that, as I say, there seems to be a problem in AS6 actually "seeing" the ICE in the first place - I often get an error about JTAGID not being valid when it does not connect.

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

Jtagice2 communication works 100% every time.

Problem is reproduceable.

Breakpoints can be set in assembler view but not in C file view. C files are displayed correctly (also in assembler view).

Have you tried moving an ELF file into another directory and then opening the ELF file for debugging and then remapping the source files when asked?

Or is it related to the message saying target is running? But it is the same in the assembler view: stopped in both cases. And as I said: Jtag communication via USB works fine.

edit: version here is also 6.1.2730 (Service Pack 2)

edit2: What is the situation with -relax? Should I be using it? Could not find much useful about that subject through Google.

edit3: The source file / ELF file reading must be ok; all variables can be used in the watch; even local variables in registers work fine (showing even the enumerated values from the source file; cool...).

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

Quote:

Have you tried moving an ELF file into another directory and then opening the ELF file for debugging and then remapping the source files when asked?
I have done that but I don't really see the point. AS6 does a grand job of building C code.

Atmel added a new toolchain wide option to set -relax in 2730. If you want to use relax you must do it that way and not -Wl,-relax or the C and asm get out of step and breakpoints can get set in the wrong place. If you don’t want to use relax just ignore all this.

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

I could not find -relax. Is it -mrelax, --relax, -mlink-relax or --debug-relax?

I'll try it but I don't think this is related to my problem. In the Disassembler view or using "Breakpoint at function" breakpoints can be set and they are in the right place.

Quote:
AS6 does a grand job of building C code.

I disagree.

How do you tell AS6 that one of the source files in the project has to be compiled with an X86 compiler, the output executable then run on the underlying OS to create a C or assembler source file which then has to be compiled with an AVR compiler to be linked into an AVR executable?

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

I tried -mrelax (reverse engineered from a sample project).

Makes no difference.

I think the key is: "Note: The current selected device is unable to set breakpoints during runtime."

Is that some generic message from VisualStudio or did Atmel put that in? If the latter: why does the debugger think the processor is running?

Or can you only set breakpoints in the source files and then start debugging (i.e. downloading the executable onto the target and starting the target)?

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

I've been battling a similar problem for 3 weeks.

I just wanted a breakpoint in the C code for WSN Demo. As soon as the debugger ran the breakpoints disappeared. The code compiled OK and even ran on the target OK.

I could set breakpoints at assembler level.

After trying AS5.1, AS6.0, AS6.1, AS6.1SP2 and having to downgrade the USB driver for my JTAGICE3 to get that to work again I think I've found the root cause.

I say think because I've a whole lot of cleaning up to do.

Atmel support were no help either.

Anyway it seems to the filepaths in the Atmel Project that are the problem. I'm building using a Makefile and that's compiling just fine, but I think I moved some folders at some stage and the AS project just can't find the C files that correspond to the breakpoint.

Oh and you also need to make sure the optimisation is set to -O1 rather than the default -Os for WSN Demo.

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

Quote:

Anyway it seems to the filepaths in the Atmel Project that are the problem

I had the same problem. To work on my project I was always opening the .cproj file. I solved the issue by using the .atsln file instead, now the breakpoints are fully working.

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

I had the same problem and Message.
After finding this thread it dawned on me I had moved the Project. So I did make clean solution and rebuild solution. That fixed it!
I must say AvrFreaks was a *lot* more useful than the error Message in Studio6!. :-)

Einar Sjaavik

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

This may no longer be relevent, but I was having the same problem today trying to run & debug the AVR1886 demo (mixing c with asm).

Found a drop down box in the middle of the top tool bar, just below the help tab, that said "release". Changed it to 'debug' & the problems went away.

Now it steps through the c & asm code rather than the disassembly listing & breaks work.

 

 

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

I am having a problem with AS 6.2.1502 with the same error posted for breakpoints.

AS6.2 does not hit the breakpoint. The breakpoints is not a red circle it is a empty cirlce.

 

I am not able to see local, Auto and added watches.

Nothing populates in the local and auto when the program is debugging.

If I add a variable to watch1. The name is shown correctly under the name column, Under the value column it shows unknown identifier and under the type column is shows error.

 

All help is appreciated.

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

Sounds like -g has been turned off - you are building Debug not Release aren't you?

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

I could not find the -g at the output window after a build while in Debug. So if -g is a flag to turn on something, I am not seeing the -g at the output window on a line that appears to be a command line.

 

Right now I see that I am in Debug. Still no working breakpoint when enabled or variable in any watch window.

 

I misspoke saying I seen two places where I could select Debug or Release.

I discovered I was actually changing Debug in the same place in the Build menu's Configuration Manager.

I just took two different navigation paths to the same place.

 

I still need help..

 

Where else can I look to get AS6.2 to stop at enabled breakpoints?

 

I could post or send information what I see.

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgot to add it in this thread: I moved back to Studio 4.19, that fixed it for me.    I cannot have Studio 6.x dictating where I place my files, it is too slow to use it efficiently and using it for the build is totally out of question.

 

Unfortunately a lot of the processor register files are missing.    Is there any way to get the files built for 4.19 or move / modify them from 6.2?   I tried modifying one by hand but there seem to be too many dependencies / redundancy built in.

 

 

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

Unless there are things you need in 4.19, use 4.18 .

There are some broken things in 4.19 (for sure some compile status things).

 

I use 4.18 with this compiler WinAVR-20100110 and that seems to be stable. (the org compiler sometimes made big errors).

 

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

I do not use any form of IDE for the system build (for reasons mentioned above).   I use gcc-avr under Linux (4.7.2 at the moment), a very good compiler by the way, my compilments to the developers!  Only very rarely I need a debugger, that's where Avr Studio is used.   Since 6.x creeps like a crippled worm and is bloated it is a no go area for me.

 

I had installed 4.19 mainly because of some extra Xmega devices I needed that were missing in 4.18.    As far as I can see all the processor specific definitions are in XML files.    The 6.x format seems to have changed, so simply copying them doesn't work.   Also editing them by hand did not lead to a success; I think I missed some dependecies; maybe some depencies are even hard coded in the executable.   So if anybody had success adding processors to 4.18/9 any advice would be appreciated.   Or maybe Atmel could be so kind to create the files for 4.18/9 for newer processors.

 

 

p.s.:

If I cannot get other processors working with 4.18/9 I'd see myself forced to move away from Atmel for future development projects.    A pity really because I think in particular the Xmega devices are a really good design.

Last Edited: Wed. Apr 8, 2015 - 07:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or maybe Atmel could be so kind to create the files for 4.18/9 for newer processors.

Why would they do that? Surely they (and their users!) would want them to dedicate all their development budget to improving the already excellent Studio 6?

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

Maybe they would do that to keep designers using their controllers and not moving to competitors products?

 

Imho that Microsoft based Studio 6 bloatware is not leading anywhere (long term).  

Wrt to excellent: see my post #8, last sentence.    Companies seem to live in a dreamworld that only consists of their products and an island solution for software development.

Last Edited: Fri. Apr 10, 2015 - 03:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I have to disagree with you, the auto-completion of AS6 is one of the new features (compared to Studio 4) that is a major + for me.

And I have re-read the last sentence of post #8, but I cannot see a typical application for this...Can you provide a clear example where it could be useful ?

Have a nice day,
Kraal

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

I change a C header file with system specific constants.    I run our system build which does:

 

1. update X86 tools if dependencies exist.

2. compile an X86 C source that includes this header.

3. run the executable created in 2 which generates AVR assembler code (a few thousand lines).

4. compile another X86 C source which also contains this header.

5. run the executable created in 4 which generates Verilog HDL source

6. run Altera FPGA tools that convert Verilog source code from 5 into a binary FPGA programming file.

7. run another X86 tool executable that converts the FPGA programming file into AVR C source code.

8. assemble all AVR assembler source files.

9. compile all AVR C source files.

10. link all AVR object files.

11. dump binary file from AVR ELF file.

12.  run X86 tool executable that adds CRC to binary and creates programming file for use with boot loader.

13. optionally fuses and boot loader are programmed onto AVR processor on target board with avrdude and programming file loaded using bootloader.

 

One typical example of a software build.  

Multi processor systems may require integration of software build for other processors (ARM, DSPs, ...).

Three key strokes required to build the system from source and program it onto the target hardware.

Have I missed that the "Auto Completion" feature of Studio 6 can handle that ?

Last Edited: Fri. Apr 10, 2015 - 04:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the auto-completion of AS6 is one of the new features

Fortunately "helpful" feature like that can be turned OFF along with other "useful" stuff. angry

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Obviously there is a discrepancy in the requirements for beginners and professionals.    It is up to Atmel to decide where most profit is being made and how they structure their development tools and how accurate they keep their documentation.   Having to reverse engineer sample code they throw at you is not how I like to develop software.    Just yesterday I had another bad experience where Atmel wasted a lot of my time with faulty documentation and where I eventually found the solution here in the forum (thanks to Leon who did the tedious task of reverse engineering): https://www.avrfreaks.net/comment/862035#comment-862035

 

And coming back to the original problem (post #1): in Studio 4.18 it was possible to simply open an ELF file for debugging.   If the directory structure did not match you were asked to specify the location of the files and that was it.   There may be new "features" in AS 6 but very basic functions are not working any longer.

 

 

p.s.: just checked: 3 years after their documentation fault was discovered it is still not corrected (XMEGA AU Manual, chapter 33.11.2.4 Erase Flash Page).

 

Last Edited: Sat. Apr 11, 2015 - 08:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't expect Atmel to correct errors in the documentation!

The AVR1200 the first public AVR died with errors in the data sheet (the first chip should have been the AVR1300), they unfortunately don't care. sad

 

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

They should.   It is damaging their business.    Very sad when you design first class products and they are rejected simply because the documentation and tools are faulty.

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

Yes it's sad , but it seems to be the way they do business, they have followed that strategy all the time I have used Atmel CPU's  (back in about 1996 with 8051 chips.)

I think they relay on FAE's for the big business and something like this forum for the rest.
 

Last Edited: Sat. Apr 11, 2015 - 01:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I hope they got their numbers right.    We are doing designs (and make the design decisions) for companies that then take over the manufacturing, so they cannot know how much business they are losing.    We are using NXP ARM when a bit more processing power is required and never had any problems with their documentation or the tools: read the data sheet, type in the code, works.   I had a quick look at their web site this morning, they have small ARM devices for around $2 in 10 piece quantities, so no reason hanging on to AVR any longer (for good reason we never used ASF or Atmel sample code and hence can move to other processors with no effort).   And no hassle with Microsoft based tools.

Last Edited: Sat. Apr 11, 2015 - 02:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Returning to topic start, I had the same problem "The breakpoint will not currently be hit. Unable to set requested breakpoint on target." on Atmel Studio 6.2 debugging ATTiny24A. To fix the problem, I:

1) Moved my project to directory with no spaces and non-ASCII letters (i.e. "H:\AVR"), I had Cyrillic letters in path;

2) In Project -> Properties -> Toolchain ->AVR/GNU C Compiler ->Optimizations changed optiimization level to "None (-O0)", in Project -> Properties -> Toolchain ->AVR/GNU C Compiler ->Debugging set debug level to "Maximum (-g3)".  (Ensure that you have Configuration: Active (Debug))

 

_delay_ms() started complaining but now I can set breakpoints.

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

Thanks dkorobkov, had the same issue and this solved it for me!

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

Thank you very much  dkorobkov,The problem has been bothering me for more than a month.this solved it for me!

 

Go for it

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

Changing optimisation to -O0 is a TERRIBLE idea!

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

Thanks! Same problem was solved for me by setting debug level to maximum in Atmel STudio 7. No need to change optimization or remove blanks though.