Freddie Chopin wrote: > Thomas Kindler pisze: >> Hi! >> >> When single stepping on a STM32, I'm constantly caught in interrupt >> handler code. This makes debugging almost impossible for non-trivial >> programs with timer and other peripheral interrupts. >> >> I have seen that there's an "cortex_m3 maskisr on/off" command, but >> it's awkward to use from eclipse. There seems to be no way to issue >> monitor commands to OpenOCD during a debug session, or even bind >> commands to a GUI button (perhaps a nice feature for Zylin-CDT?). >> >> Is there a good way to tell OpenOCD to mask ISRs after hitting a >> breakpoint/single-stepping, but re-enable interrupts on run? > > That's not your problem.
Unfortunately - it is ;) > On STM32 when the core is halted (whatever was the reason) some > peripherals (including timers) continue to operate normally. This is a > good thing - imagine writing a software for SMSP and no possibility to > halt the chip - you'd have 50% chance of frying the coil and the switch > when the PWM would stop working. That's why when you stop your program > some peripherals keep working and keep sending interrupt signals, making > single stepping virtually impossible. No, these are two different things. The timer and PWM outputs may (and should) continue to work, I just don't want to see their interrupts. This is exactly what cortex_m3 maskisr on/off does. We also have some commercial JTAG interfaces in our company, and Hitex' HiTop, for example, offers a dialog to selectively disable interrupts while stepping. The timer is left running, but doesn't fire interrupts. After pressing "run", interrupts are re-enabled automatically. So, as David asked: yes, maskisr does solve my problem. It only lacks automation. I would like to use "some OpenOCD GDB events" like Oyvind suggested.. but _how_ to do it?! My goal, after all, is to replace our existing commercial toolchain with CodeSourcery/Eclipse/armgnueclipse/OpenOCD without loosing too much comfort. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
