Welcome in the forum, imdat!
This problem has been seen very often and sadly cannot be avoided. The reason is that on a breakpoint the CPU is stopped, but the internal hardware continues to run, thus producing interrupts which are remembered. When starting by pressing F10 at first the interrupt gets handled. When finished the handler returns to the place it originally came from. And there is your breakpoint. So the program is halted again at the same point.
Ways out: When at the breakpoint, disable interrupts when single-stepping, before executing a run-command enable them again. There is an icon in the menu for interrupts.
remove Breakpoint and set a new one at the next line you want to stop, then execute a Run-command
This is one of the most annoying things I've ever encountered in a debugger! I've used IAR EW, Eclipse and Netbeans, and this behavior doesn't happen... why on PSoC Creator then???
It has nothing to do with the debugger, but PSoCs are chips with real internal hardware which causes that behaviour.
" why on PSoC Creator then???" I hoped to have explained that in deep. What you didn't understand? How would you suggest to avoid this hardware-interrupt problem?
I read this thread with a lot of interest because I am new to Cypress products and currently evaluating the EZ-BLE module. I agree that this behavior is very irritating and generally not present in other development environments. On the other hand, I would like to make some suggestions based on my experience, maybe you can tell if this could apply to Cypress IDE.
I have worked a lot with Microchip microcontrollers for the last few years, and I have the feeling that they also had to deal with interrupt issues with their debugger. But here are what their environment offers for dealing with that:
- For each hardware peripheral in their chip (uart, timers, spi, etc.), there is an option in the project debugger settings to make that peripheral "freeze" during a breakpoint. For example, we can configure the timers to freeze when a breakpoint is encountered, so that a 100ms timer for example would not expire during single stepping.
- Even when peripheral are configured to not freeze during breakpoints, a single step (step over) always go to the next execution line in the source code (not the disassembly code). That is, even if a timer interrupt is pending, when hitting the step over button, the code execution will only break when the next source code line is encountered (that is, pending interrupts ARE actually processed before the code execution breaks at the next line). My personal feeling (not confirmed though) is that when using the step over button, the debugger will actually place a temporary breakpoint on the next source code line and run the code.
Actually, maybe adding a debugging option in PSoC Creator to decide the behavior of the "Step Over" would do the trick. Options would be either the current behavior (which jumps in the pending interrupts) or a "put a breakpoint on the next source code line and run".
I hope this can give some ideas to improve PSoC Creator experience.
Welcome in the forum, Francois!
Yes, I think everybody would be pleased when a better step-over solution could be implemented in the (afaik ARM-supplied) debugger package. Since this is a developer forum only, I would suggest you to create a support case (top of this page "Design Support") to focus Cypress's attention on this behavior. You can even support them with a link to this thread.