Thanks for the report.

We would expect it to stop on each iteration of the loop as described.

A few questions to help us understand further:

• Does the watch expression data show that the loop needs to run multiple times?
• If you put a simple Serial.print(p) into the loop does this output multiple times as expected?
• Also with the Serial.print code present, does it iterate the loop correctly in the Hardware Debugger?

Another observation:

If I clear the serial2 terminal after I stopped the debug-session and starts the debug session I can see that it programs via the Atmel-ICE, but before hitting the first break-point in the loop, it seems to have run the program twice, from what I can see in the Serial2 terminal:
Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:90057
Starting up ok
pStart:537337856
pEnd:537427913
pStartStack:537427912
dummy_cnt:90057

I have also attached the output from "Micro Build"

Thanks for the detail.

If you add a Serial.print(".") to the inside of the loop is this all still the same?
(This may prevent the compiler unrolling the looped statements is the reason for this request)

It could also be that the loop has run by the time the debugger attaches, if you add a breakpoint above the while loop, does it land there, and then allow stepping through the loop?
Alternatively adding a delay(3000) at the top of loop can achieve the same aim if the load timing is an issue.

Conditional Breaks and Hit Counts are not supported in Hardware debugging, however are fully supported using the Serial Debugger.

Thanks for the detail, and it makes more sense its a timing issue now.

If you want to reset the chip when using "Debug > Attach To Process", you can add a Local board.txt to the project (vMicro > Add Code > Add Local board.txt), and put the below content in, and save it.

# Force the Chip to Reset when Debug > Attach to Process is used for AtmelICE (vMicro)
vs-cmd.Debug.AttachtoProcess.tools.atmelICE.server.initCmd=-c "init; reset halt" 

This will run the reset command as part of the attach process as well as the debug > start.

I'm not sure at present if a different debugger will avoid this, and would have to check with other probes.  It could also be affected by the PC speed, and possibly the software stack being loaded (MI/OpenOCD/GDB), though if it was the software stack I would expect to see it on all boards.

The software modification to wait a second or two before continuing with the main code may be the safest way to work with this particular setup, and this could be wrapped in a #ifdef to ensure it only affects your Debug Builds, and not release builds.

#ifdef _DEBUG
	while (millis() < 3000) {
		delay(100);
	}
#endif 

With the board.txt change, the board will reset every time the Debug > Attach to Process is used (so you don't need to use Debug > Start Debugging, and do the build and upload every time you want to start at the start of the program).

I expect two resets should only happen when the Debug > Start is used, and will see if we are resetting at two different layers of the software.

The delay wont prevent the double reset, however if it is still waiting when the second reset occurs, the program essentially wouldn't have done anything yet, so should achieve the same thing from the perspective of watching the Serial output.

ok I read again and see your last sentence with the double reset explanation when having a delay before printing will "cover" the reset behavior

Thanks for the detail.

I have not been able to reproduce this at present on our setup, and continue iterates through the loop as expected on my test.

I'll try again shortly and update, and if possible could you send the whole project as a ZIP to us at sales@visualmicro.com, just so we have all of the same setup when testing.

Thanks for the project, and it seems this is due to how the compiler interprets the code to assembler.  I believe it has moved the looping construct to the ASM instruction level so it doesn't return from the ASM until the loop completes essentially, which matches the behaviour we see.

To land on the break within the loop each time the below solutions all seemed to work for me:
1) Move the Serial.begin(115200) above the loop (not sure why this alone worked but it did for me)
2) with #1 in place add a Serial.print(*p) to the inside of the loop (if #1 works alone then not really needed).
3) Force absolutely no optimization within setup() using the #pragma directives below (can remove #1 & #2 here):

#pragma GCC push_options
#pragma GCC optimize ("O0")
void setup()
{
// Your Setup Code
}
#pragma GCC pop_options 

Let us know if this helps, and which of the solutions works for you when you've had chance to try it.