The way I do this on the STM32 is to use TCL script JTAG to zero the memory before allowing GDB to attach.
This is necessary since a previous run of the system can leave valid contents in the RTOS variables, which are indistinguishable from real RTOS data. With the memory zeroed, the system behaves as expected with a single thread of execution showing in the boot-up code, then multiple threads once the system has started. Perhaps there's a better way of doing this, but I haven't yet thought of one. Evan -----Original Message----- From: Michael Schwingen [mailto:[email protected]] Sent: 23 August 2011 19:59 To: [email protected] Subject: Re: [Openocd-development] Automatic RTOS Detection On 08/23/2011 09:47 AM, Evan Hunter wrote: > The way it has been designed means that no memory locations are touched until symbol locations are provided by GDB. The symbols names which are available tell the system which RTOS is in use. > > On most platforms OpenOCD would have initialised the memory system by the time GDB attaches. However, you are correct, on some platforms the memory controller may have to be enabled in the software. Hence, I would suggest only enabling the feature for Cortex-M3 devices or just STM32 devices to start with, since it has only been implemented/tested for these so far... > What if I have a system with an RTOS and want to debug the startup code using GDB? In that case, memory is *not* yet initialized, yet the symbol table would enable RTOS support. If we have a separate bootloader, this is no issue, but if the target application is a single image containing startup code, RTOS and applicationn, it will be. cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
