We will do some testing. The software debugger does stop debugging when click the step because it can't step. It is possible that in the last release there is some confusion with the intercept of the step.

Great. That looks like an optimization problem. You can switch off optimization in a few ways. Optimization can increase program size, therefore there are various ways to disable the default which is probably -Os

1)

Right click the project name in the solution explorer and add an "extra flags (configuration)" of "-O0"

or

2)

In recent builds you can "Right click the project name in the solution explorer" and set "disable optimization project, libraries and/or core". This latter option has not been tested in atmel studio yet.

or

3)

You can just switch off optimization for a single code file or code part. 

//code to switch off optimization
//
   

  pragma GCC push_options
     pragma GCC optimize ("O0")
  

//code to revert optimization to the standard setting for the hardware
//

       pragma GCC pop_options
 

Let's check the build output. please follow the yellow guide at the top of this page. Click build>Clean then click debug Start. After that in the "Micro Build Output" window we will see your full build config. Please attach at .txt


Thanks

Great that explains a few things. You need to switch on "vMicro>Debugger>Use Atmel Studio Debugging". The Debug>Start will launch hardware debug instead of Serial debug and the compile will be for hardware debug too.

The F5 key then steps, the F9 key toggles a break-point. These are standard atmel short cuts and can be seen on the debug menu. With atmel debugging enabled the "Attach to process" and other functions will work better. 

The optimization will also be more flexible, the serial debugger will certainly clash and I guess it appeared after upload and you closed it then attempted to start atmel debugging manually?

Does any of this make sense?

Great, Now that you have atmel debugging enabled visual micro has nothing to do with breakpoints. After the debug launches that is 100% atmel studio.

Visual Micro is creating the build, same as the arduino ide but with an extra debug flag -g and also whatever optimization or extra settings you apply yourself. Atmel knows nothing about the build process except that we tell it where the resulting .elf program file is. It then uses the .elf to establish a debug session.

Visual Micro is performing the upload unless you have enabled "vMicro>Uploader>Use atmel studio device programming" in which case Visual Micro just tells atmel the location of the resulting program file (.elf/.hex) and then let's atmel do whatever it would normally do for the processor that is selected.

When you select an arduino board visual micro tells the atmel studio project which mcu is being used which it needs to know for intellisense, upload and/or debug.

The atmel studio intellisense is provided by the VisualAssistX plugin that is included free with atmel studio. Visual Micro simply ensures that the intellisense knows the mcu, include paths and pre-processor definitions based on the selected arduino board.

The visual micro web site and docs are worth a read. The home page has a link to the Atmel Studio 7 page which explains in red everything that you encountered.
https://www.visualmicro.com/page/Arduino-for-Atmel-Studio-7.aspx

Thank you