Breakpoints not hit.

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


I have a new project with some dummy code.

 

#include <avr/io.h>

int main(void) {
  const short foo = 10;

  while (1) {
    short bar;
    bar += foo;
  }
}

I have breakpoints on the const short foo = 10; line and bar += foo; line.  i have the debugger set to 

 

I have the Selected debugger/programmer set to Simulator.

 

If I run with debugging then the breakpoints are never hit.  They are hollowed out

 

 

If I pause the debugger then the next line is stuck before the first executable statement.

 

 

Trying to step over/into just causes the yellow marker to flash, but stay where it is.

 

This is my first attempt using Atmel Studio, I don't know what I might need to change in order to fix this.  I suspect that there's a process that it's waiting to attach to and not finding, but I don't know what that might be.

 

Any suggestions?

 

Thanks

 

Dave

This topic has a solution.
Last Edited: Sun. Dec 19, 2021 - 04:58 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You need to read my tutorial...

 

https://www.avrfreaks.net/forum/tutcoptimization-and-importance-volatile-gcc

 

Bottom line.. The optimizer will discard everything as the program doesn't actually do anything, it has no outputs. "volatile" basically says "this is an output that must be calculated / updated" 

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

Ah.  That makes perfect sense then.  I assumed (shouldn't have assumed) that as the config was debug mode that there wouldn't be any optimising things away.

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

These days for "Debug" Studio 7 applies optimization level "-Og" but that still applies some optimization and will discard code that looks completely pointless. It's the same reason you can't just do a "for(int i=0; i < 10000; i++)" delay loop. Even at low levels of optimization the compiler will spot that it does not achieve anything so will discard the code.

 

Apart from "volatile" another good way to get things updated is to give them global scope as the compiler will assume the value may be used in another compilation unit. But if you did

foo = 13;
for (int i=0; i < 5: i++) foo += 3;

and foo were global all this would simply produce "foo = 28;" as that can be calculated at compile time. 

 

Because the AVR SFR registers like TCNT1, PORTB, DDRC, etc are all defined as "volatile" they are a good source and destination for inputs and outputs in "test code" as the compiler must write them when told and it cannot make any assumptions what value they return when read.

 

Bottom line : if you want to "test" some paradigm when using AVR just write real AVR code. 

 

If, on the other hand, you just want to see "computer science" in action you are far better doing that in PC code (Visual Studio say) when it builds "Debug" it really is the most sub-optimal, bloated/slow code but on a 3GHz octacore that doesn't actually matter! 

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

Writing to registers is a brilliant idea.  I didn't think of that 

Are the General Registers good for that?