Hi!
I am now writing the code into my project that would require step debugging, but "step over" does not work at all and so it's impossible to debug. :(
Do anyone know what is the problem, how to solve it? (Ofc. putting a "disable irq" row before all my breakpoints work but it's mega pain... or putting a new bkpt. after the line I want to step over.)
"Mask interrupts while stepping" has no effect at all.
Thanks in advance!
Zoltan
meolsen 
Use Run To (in the right click menu). We are aware the the mask interrupt on step does not seem to work on the M7 cores...
Thank You.
May the issue be fixed in chips manufactured in the future? Currently I can afford to use "run to cursor" but later when the device is on the market, I would need a fully working step-debug environment to develop the new firmwares. Step over and into as well without going into the IRQs.
Or maybe a workaround in Atmel Studio 7, like putting a new breakpoint on the proper point, continue run and then remove the bkpt automatically?
meolsen It is actually a core bug: http://www.keil.com/support/docs...
Is there any workaround for this in latest Atmel Studio 7.0.1645?
I have SAM E70 Xplained board (which has Cortex-M7 r0p1) and got in the same problem with the debugger: it jumps on any interrupts endlesly during single-step... the only solution was to use run-to instead of step-in or step-over.
Segger "fixed" in their tools more than 1 year ago: https://www.segger.com/downloads...
Version V6.10b (2016-09-26)
5. DLL: Added single stepping workaround for buggy Cortex-M7 r0p0 and r0p1 devices (e.g. ST STM32F74xxx and STM32F75xxx series), so PC does not accidentally end up in ISR on single stepping.
Any chance Atmel will do something similar?
Thanks,
Daniel
PS: I use the embedded SWD debugger offered by the SAM E70 Xplained board so no 3rd party JTAG.
Do we have a solution for this issue yet?
scdoubleu 
Do we have a solution for this issue yet?
There is no perfect solution for M7 cores <= r0p1. The work-arounds try to paper over the cracks but they do not/cannot completely fix the problem.
Your best bet is to source a revision B part to replace the rev A part on the board. Good luck - microchipdirect.com has plenty of the rev A parts (I wonder why...) but a 12 month lead time on rev B parts!
Steve
