Where is PC pointing to when BREAK is hit during debugging?

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


According to the AVR instruction set manual, executing a break instruction will advance the PC by 1:

 

 

Debugging the following test

int main(void) {
  asm volatile("break"::);
  for(;;);
}

in MPLAB X stops automatically and the PC points to the start of the break instruction.  Tested with the simulator for attiny24, and on hardware on atmega4809 Curiosity Nano.  Qemu-avr also rewinds the PC (https://github.com/qemu/qemu/blo...) after hitting the break instruction to point to the start of the break instruction (although the relevant code is disabled by default). The unofficial debugwire protocol suggests that the on board PC is pointing to the next instruction to be executed, but an implementation such as Dwire-debug subtracts a word from the debugwire reported PC, effectively pointing to the start of a break instruction after the controller is in stop mode.

 

1. What value is loaded in PC (on the controller itself) after a break instruction was / is to be executed and the interruption is signaled to the driver?

2. Is there an implicit convention that PC should be adjusted to before the break instruction before the driver reports PC to a debugger?

3. Or does the debugger itself rewind the PC when it detects a stop condition due to a break instruction, before displaying the debug state to a user?

4. Is the documented behaviour of break wrong in the sense that hitting a break instruction does not advance PC?

 

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

I think the manual claims this because BREAKs are "executed" as NOPs when the debug system is disabled, so you have an increment of 1 when its executed.

 

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

ccrause wrote:
executing a break instruction will advance the PC by 1

Presumably, that happens after the debugger "releases" the break?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mraardvark wrote:

I think the manual claims this because BREAKs are "executed" as NOPs when the debug system is disabled, so you have an increment of 1 when its executed.

That is fair enough, but then what happens if a debug probe is attached?  I'm asking from the perspective of a debugger.  Should the debugger expect PC to still point to the break instruction?  It would appear so, but that case is not covered by the documentation.

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

awneil wrote:

ccrause wrote:
executing a break instruction will advance the PC by 1

Presumably, that happens after the debugger "releases" the break?

I'm adding AVR support to a debugger and I'm trying to clarify exactly what the situation is when it receives a trap signal, so that the debugger can take appropriate steps.  So I need to figure out what exactly "releases" entail.  It seems that  one needs to increment PC by 1 word, then issue a continue or step command to move past the break.

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

You might need to raise a ticket with Microchip to get a definitive answer on that...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...