On Tue, Dec 7, 2010 at 5:13 PM, Freddie Chopin <freddie_cho...@op.pl> wrote: > On 2010-12-03 23:27, Ian Lambert wrote: >> >> Hey guys. I've been using the Openocd-0.4.0 with the Olimex ARM-USB-TINY >> Jtag on the Luminary lm3s6965 chip (Running FreeRTOS) for a while, and >> I've noticed some major problems with stepping in GDB. >> >> If it's of any help, I am using the Codesourcery arm-2009q3 toolchain. >> >> I'd appreciate any help. >> >> Ian Lambert >> >> Every time I try to step one line of code or to step into a function, I >> end up breaking in an ISR. >> >> Has anyone experienced similar problems? >> >> (I've attached my configuration for the perusal of anyone interested) > > IMO this is perfectly normal and I experience similar behaviour on STM32, > especially with timers or UART. When the core is halted, some peripherals > actually work normally (timers) or almost normally(UART), so for example a > timer match interrupt is reported, new chars in the UART are waiting etc. On > STM32 timers (and some peripherals) can be stopped in halt mode (using > DBGMCU registers) and that's the only solution... IMO it's almost impossible > to debug code that heavily uses such interrupts (when the peripherals are > running when the core is halted). Only breakpoints solve this issue > partially.
Then I guess you can mask the INTs to check if this is the case, or error in OpenOCD. If OpenOCD is working correctly (most probably), maybe by masking one by one line you can localize INT that is giving you headache... BR, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
