Single stepping with Studio and JTAGICE-mkII

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

JTAGICE-mkII have problems with debugging. Most of the time you will have to press F11 (Single step) several times to get past a C-line. I guessed this was because of the C-compiler but now I have had reports that this is only an issue with JTAGICE-mkII.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

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

bengtr,

Viewing the assembly listing of your code and steping (using F11) you must see the cursor goes to the next assembly step. For sure the most C instructions consisted of more than one assembly instructions. So it is very normal when pressing F11 to step in the same C instruction for more than one times.

Try this: when steping in C use the F10.

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

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

The normal behaviour is that a single step shall execute one line of C-code that of course is the same as several lines of assembler. The intereting fact is that this is only a JTAGICE-mkII problem although I have not been able to verify this myself.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

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

bengtr wrote:
The normal behaviour is that a single step shall execute one line of C-code that of course is the same as several lines of assembler. The intereting fact is that this is only a JTAGICE-mkII problem although I have not been able to verify this myself.
I do not have this problem using the JTAGICE-mkII on a mega2560.

It is very possible that if you have optimization turned on (and usually you should), the compiler has optimized your code into assembly code that does not map 1-to-1 to the C code (it performs the same function and gives the same results, but is tighter and more efficient that strict C-into-assembly translation). Try setting optimization to -O0 and see if that helps.

Warning: Don't leave your optimization at -O0! Some functions in avr-libc will not work correctly (or at all) with optimization set to -O0! Delays and watchdog functions are some of these functions.

See the thread https://www.avrfreaks.net/index.p... for more on this issue.

Stu

Edit 1: Just saw that you are using the ImageCraft compiler -- check for a similar problem with that compiler. As always, read your compiler's documentation first!

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

The person who reported this problem to me [/edit: not the problem but that it was only on JTAGICE-mkII] said that the designes at his workplace struggled to use the old emulator (don't remember what is was, ICE-200 maybe) whenever possible just because of this problem. So before anyone else can do some real tests I think this is more of a tool problem than a software. But you are right that the comiler usually affects this type of problems and make it trickier for the emulator to do a correct single step.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

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

So where are we with this? Does everyone agree that single stepping in C (i.e. f10, as opposed to stepping into wth f11) with a mkII behaves a little strange?

I find that I have to press it many times to get past a single line line of C. I understand that this is because it may be doing a single step in ASM behind the scenes, but this is an annoying characteristic.

I too use the imagecraft compiler. Is the problem lying there? Is there a solution to making it behave more 'inuitively'. I expect that when hit f10, it should move to the next line of C code.

Unless otherwise stated:
uC: ATMega128 or 644P
Compiler: Imagecraft ICCAVR V7.2
Debugger: AVRstudio 4.16
Programmer: Atmel, JTAG MKII
Experience: 20 years of C
Dismal ASM skills

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

Shandor wrote:
I too use the imagecraft compiler. Is the problem lying there? Is there a solution to making it behave more 'inuitively'. I expect that when I hit f10, it should move to the next line of C code.
As I said in my earlier post, the most likely "problem" is that the optimizer is changing the underlying instructions enough that there is no longer a one-to-one relationship between executing code and C.

This behavior of the optimizer "morphing" the code is stronger with RISC processors like the AVR as opposed to more CISC-like processors like the x86, 805x, and so on. The given reason for that is the RISC architecture provides more opportunities for optimization, if only through larger register sets.

The fact that optimized code doesn't follow the C code line-by-line is good news -- that means the compiler has digested your intent as expressed in the C code and generated faster/better/smaller code than slavishly following your exact lines. The compiler is utilizing more resources from the processor than a simple translation would in order to get you the same answer, faster. Kewl, huh? :D

Your best bet is to read the Imagecraft documentation or to post a question to their support folks. Again, as I posted earlier, telling the compiler to "turn off" optimization in the code you are interested in is the approach I would (and do) take.

There is nothing that the AVRStudio guys can do to help with this.

Stu

PS: If you think the optimization causes a lot of morphing here, you should see what happens with VLIW machines like the Itanium. :shock:

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

thanks for the explaination. I am confused at one thing though:

Quote:
There is nothing that the AVRStudio guys can do to help with this.

When look at the disassembler window, the ASM s written and each adn every line of C code is commented in there too. It seems that AVR studio could peform a "run to here" type of thing, goings through all the ASM commands until it reaches the next commented C line, interrupt, or jump instruction. Then it would nto matter how the code was compiled since it would be looking for the commented C code.

Unless otherwise stated:
uC: ATMega128 or 644P
Compiler: Imagecraft ICCAVR V7.2
Debugger: AVRstudio 4.16
Programmer: Atmel, JTAG MKII
Experience: 20 years of C
Dismal ASM skills

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

Hi.
I asked the same question in the email list of Imagecraft ICCAVR and Rick Drolet gave me the solution:

"Yes. This happens with 4.13 when reloading a lot of times. You can clear this by leaving the debug session & reloading.
Or go to 4.14 - latest build. this fixes the step."

So maybe we can forget all complicated guesses about any undelaying C structure. It's Studio and nothing else and it should have been fixed now! Sorry Stu but I hope that you like I can live with that you couldn't have right always.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

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

Actually, I think I see what Stu was getting at. It's not AVRStudio that actually does the running or stepping. Its the JTAG hardware on the chip (correct me if I am wrong).

That hardware doesnt care about commented C code. However, it does still seem like AVR studio could do a better job of telling the JTAG hardware where to stop.

Unless otherwise stated:
uC: ATMega128 or 644P
Compiler: Imagecraft ICCAVR V7.2
Debugger: AVRstudio 4.16
Programmer: Atmel, JTAG MKII
Experience: 20 years of C
Dismal ASM skills

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

Studio can only read what the ELF file output from the compiler/linkers is telling it. When code is built with -g (so it contains debug info, probably DWARF2) then there's the binary code image in the file but also links saying "these four opcodes came from fred.c line 51" or whatever. It then tries to match the C source and what's actually being executed on the target. If you position on that line and press single step then it'll run four opcodes and move the "pointer" on in the C. But suppose the optimiser has mixed the code up so you have ten opcodes, the first 4 from line 51, then next 3 from line 52 and the final 3 from line 51. Then on the first press of [step] it'll run four and and on the next it'll run three.

If you build the code without optimisation so that there's a one to one correspondence between a bunch of opcodes and a line of C then you'll probably get the "expected" behaviour (but using VERY inefficent machine code!)

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

Cliff wrote:
If you build the code without optimisation so that there's a one to one correspondence between a bunch of opcodes and a line of C then you'll probably get the "expected" behaviour (but using VERY inefficient machine code!)
Thank you, Cliff, that's exactly what I was trying to say!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Just for your information. I have not changed my compiler and the global optimizer is turned off. But it is most interesting to find that there is no Studio version 4.14 yet so I wonder what Rick is talking about. Also note that there is no problem running the same code with another emulator. The problem must be in Studio and/or mkII firmware, nothing about compiler mixing up something.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

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

Quote:

But it is most interesting to find that there is no Studio version 4.14 yet so I wonder what Rick is talking about

There is, and he probably is talking about this: http://www.atmel.no/beta_ware/

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Just found it. It is released on the ordinary place. I was looking among the bottom of the software files list and there only the service packs of 4.13 was listed. Just a mistake from my side. But thanks Johan to point me to the beta place. Could be useful.

After installing it, it will download an upgrade of the firmware of the mkII so obviously the problem was on the mkII/Studio side, not the compiler.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.