The inner workings of JTAG, wearing out FLASH?

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

I have, for some time, been planning to complement my development bench with a JTAG "dongle", but this got me thinking:

In another thread (https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=26492&start=15), which I did not want to hi-jack lfmorrison claims that

Quote:
Don't forget, though -- When you're stepping through code with an ICE, you're actually re-flashing the chip on a repeated basis, inserting breakpoints. So it actually will contribute to wearing out your micro more quickly.

Is this really true?

I have done some reading of other threads here and found nothing conclusive.

I just browsed the JTAG section of the ATmega16 data sheet, and although I have to admit I really don't understand all of it yet (and probably need to read it a few times more) I rather get the impression (eg. figure 112 on page 221) that the JTAG part of the chip monitors the program counter in the AVR core and breaks when it "hits" a breakpoint address.

If so, this would not need any re-flashing of the chip, would it?

Stepping through code would then be implemented as setting a breakpoint at the next "step-stop" and when hitting that removing it and setting a new breakpoint at the next-next "step-stop" and so on.

An alternative to this model of having a parallell system monitoring the processor proper would be to have a special breakpoint instruction that is being inserted into the machine code being executed, and this would indeed require a re-flash every time a break-point is inserted or deleted. This would, however put no low restriction on the number of possible breakpoints but the data sheet talks about a maximum of four. So this also contradicts the notion of re-flashing for manipulating break-points.

So how does this really work? Are JTAG breakpoints implemented as special machine instructions in FLASH?

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

The information you're looking for is unpublished, but possibly available under NDA.

0x9598 disassembles to BREAK, and is indeed a FLASH breakpoint. The micro will halt, set a flag, and wait for input from the debugger.
This is used if more than 3 breakpoints are placed. The debugger can then supply the missing instruction, so one doesn't have to reprogram the flash to step over the flash breakpoint.

The 'first three' breakpoints are entirely in SRAM bits in the OCD module, and the OCD module compares the instruction pointer (and other things) to the three breakpoint registers, and breaks on match.
The same goes for single-step.

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

KKP!

Thank You for Your reply, and please don't interpret my somewhat sarcastic tone below as a mistrust or negative comment. I'ts just my way of trying to express that I really don't get what goes on...

So, if I get this right setting a fifth breakpoint will result in:
- AVR Studio figures out where in the HEX file a BREAK instruction is to be inserted, and thus also
- chages all jumps to absolute addresses higher than the address where the BREAK was inserted, and
- changes all relative jumps "over" (forward or backward) the address where the BREAK was inserted, and
- re-flashes the AVR with this.

A compete relocation and re-flash?

Read "jupms" above as "jumps, calls and other references to absolute addresses".

There is mention in the data-sheet that the JTAG system consumes the non-re-flashing breakpoints available in the OCD module at it's own discretion. Will I get a message when I'm placing a breakpoint or stepping in such a way that the debugging system will have to realize this through an insertion of a BREAK instruction and thus needing to re-flash?

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

No, placing the fifth breakpoint will not cause things to move around.
We start out with the following instructions:

0000 LDI R24,1
0001 LDI R25,0 we breakpoint here
0002 ADIW R25:24,1

and the flash looks like

0000 LDI R24,1
0001 BREAK (original instruction clobbered)
0002 ADIW R25:24,1

After reset the micro executes the LDI, then the BREAK, and stops. When you click run or singlestep, the debugger app sends the OCD module an execute_instruction* command with the missing "LDI R25,0" machine instruction, and the micro executes that one instead of the BREAK. Then the micro is let go, and executes the ADIW as normal.

So no relocation, and using execute_instruction one can avoid reflashing the entire device to set/clear these breakpoints, and make do with reprogramming the page the breakpoint resides in.

I seem to remember that AVR studio, with JTAG ICD, complains when you try to place the fourth breakpoint.

*execute_instruction is my name for undocumented JTAG instruction 0x0A, I don't know what Atmel calls it.

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

Thank You!
Much clearer now (although not anywhere near "crystal").

I suspected I was wrong but coult not invent any scheme that solved the problem. Clever little trick, indeed.

Anyone here able to give a positive report on if Studio warns before the "(re-)flash breakpoints" are being set?

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]