I’m using the GNU toolchain: gcc, gdb and friends. When I start the ARM7 demo application (compiled in RAM) with gdb or insight, step executing don’t work. I think that this is due to the interrupt driven scheduler and the ARM EmbeddedICE debug mode that disable interrupts. How can I debug a FreeRTOS task whith gdb???

Some debugging methods cope better than others.  I have encountered problems with other ports whereby stepping the compiler temorarily enables interrupts, even when you have them disabled in your application – causing big problems.  I am not familiar with the EmbeddedICE, but have not had a problem with the tools I use – parallel port wiggler, and a Keil USB device.  The wiggler seems to work well with GDB. One way around your problem might be to run using the cooperative scheduler (set portUSE_PREEMPTION to 0 in portmacro.h).  This way if your debugger is causing problems with the interrupts then at least context switches won’t occur between debug steps!  Debugging with the cooperative scheduler tends to be much simpler – but is of coarse not always suitable.  You can go back to preemptive once you have finished debugging. Depending on the size of your application, another option might to be to use the Keil simulator.  This is an excellent tool and works well with GCC built applications.  It is limited to 16K unless you buy the full version however. You say that step execution doesn’t work – what exactly happens?  If you stop on a break point then step the code, does it just start executing again instead of just executing one instruction?  If this is the case then I think I have read somewhere else about this problem.