[Openocd-development] Latest JimTCL breaking makefile features
Hi All, I've just pulled to the latest git versions of both OpenOCD and JimTCL, and have found that JimTCL is causing some issues with the OpenOCD makefiles: 1) 'make install' no longer works unless 'make' has been run previously - there is a JimTCL dependency missing which causes 'make install' to fail with the following error: make[3]: *** No rule to make target `../jimtcl/libjim.a', needed by `openocd'. Stop. 2) 'make maintainer-clean' no longer works - this target is declared to be recursive, hence runs make on JimTCL with the same target, which seems to be no longer valid, giving the following error: Making maintainer-clean in jimtcl make[1]: *** No rule to make target `maintainer-clean'. Stop. Regards, Evan Hunter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove "qP" from rtos code?
Hi Andreas, You are right - Looking at it again, the "qP" code looks like I got halfway through implementing it, then found that I should be using qThreadExtraInfo instead. Please feel free to remove it. The only reason I haven't already is that I've not had time. Regards, Evan From: andr...@fritiofson.net [mailto:andr...@fritiofson.net] On Behalf Of Andreas Fritiofson Sent: Thursday, 20 October 2011 9:13 AM To: Jie Zhang Cc: Evan Hunter; Evan Hunter; openocd-development Subject: Re: [Openocd-development] Remove "qP" from rtos code? Sorry for bringing this old thread up (no pun intended). This code got a few minutes of my attention after I browsed through the clang static analysis report someone posted recently. rtos.c was one of the first in the list, and while the bug report probably was a false positive, I noticed some serious problems with this code. To be honest, I can't see how it could work at all. The mode variable is repeatedly bit manipulated in ways that can hardly leave any bits set at all. Further, the reply string is repeatedly written over so the reply will probably be nonsense, or at least not what gdb asked for. If this code actually does something useful, please stop me, otherwise I'll simply purge the qP code from rtos.c. /Andreas On Sat, Aug 27, 2011 at 5:01 PM, Jie Zhang mailto:jzhang...@gmail.com>> wrote: Hi Evan, If qThreadExtraInfo is not implemented, qP will be used. But since qThreadExtraInfo has now been implemented, qP should not be needed any more. GDB added qThreadExtraInfo more than 10 years ago. All GDB releases since 5.0 will not send out qP packet if the stub supports qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP support and only keep qThreadExtraInfo. This will make code clean and reduce maintenance effort. Regards, Jie On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter mailto:e...@ozhiker.com>> wrote: > Backward compatibility is the reason - > When I was testing with GDB+eclipse I found that OpenOCD received "qP" > packets sometimes, and I think I implemented it first, before reading that > same quotation you mentioned. Then when I implemented qThreadExtraInfo, I > figured it was nicer to keep "qP" compatibility too. > > Regards, > > Evan > > > > > Quoting Jie Zhang mailto:jzhang...@gmail.com>>: > >> Hi Evan, >> >> GDB manual says about "qP": >> >>Don't use this packet; use the `qThreadExtraInfo' query instead (see >> below). >> >> Since "qThreadExtraInfo" is already supported in rtos.c, why "qP" is >> still needed? >> >> Regards, >> Jie >> ___ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de<mailto:Openocd-development@lists.berlios.de> >> https://lists.berlios.de/mailman/listinfo/openocd-development >> > > > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de<mailto:Openocd-development@lists.berlios.de> https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Info about RTOS support
The current versions of the Eclipse "C/C++ GDB Hardware Debugging" plugin seem to be implemented poorly, as they do not request the ID of the currently running when a breakpoint is hit. Hence the "focus" is not where it should be. If it is already working for you, you may not need to recompile GDB. I just have a OpenOCD script which is used when connecting GDB, and put the memory clear operation in that, but you may be able to put it in the reset handler. Evan -Original Message- From: Jonathan Dumaresq [mailto:jdumar...@cimeq.qc.ca] Sent: 14 October 2011 23:42 To: e...@ozhiker.com; openocd-development@lists.berlios.de Subject: RE: [Openocd-development] Info about RTOS support Hi Evan, openocd-development-boun...@lists.berlios.de wrote: > Hi Jonathan, > > You should be able to simply add something like the following to your > config file: > > $_TARGETNAME configure -rtos auto Thanx for your help ! > > > It should automatically detect the FreeRTOS instance. It's work. > > Additional notes: > * You will probably need to rebuild GDB with this bug fixed: > http://sourceware.org/bugzilla/show_bug.cgi?id=12648 It's seem to have a strange thing that happen when I put breakpoint. The Gdb stop, but I cannot see where the PC are. All thread are stopped, but the "focus" are not on the breakpoint. Is it a normal thing ? As for the gdb bug, I have not compiled a new one. I only use the one that came with the toolchain. I use the codesourcery one. Do you have this application builded somewhere that I can doownload it ? I'm on windows. > * You may need to use Eclipse Helios rather than Indigo, since Indigo > seems to not display thread names I already use Helios. I have not upgraded my eclipse to Indigo. > * Your OpenOCD startup script should clear memory to avoid confusion > due to old data persisting in RAM after reset: > > # clear RAM so that the rtos awareness does not detect threads > left in memory from previous run mww 0x2000 0x 0x4000 I will put his in my reset init call back ? > > > Regards, > > Evan Hunter Regards Jonathan Dumaresq ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] GDB notification of processor reset
Hi All, I've noticed that if my processor gets reset whilst debugging a program, GDB knows nothing about it. I would have thought GDB should stop, in a similar way as hitting a breakpoint. Is there currently any way of making this happen? I'm using a Cortex-M3 (STM32f1xx) Regards, Evan Hunter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Another FreeRTOS fix
Hi all, My last patch for FreeRTOS was not quite correct - it had an off-by-one error. Attached patch fixes it. Regards, Evan Hunter 0001-Fix-off-by-one-bug-in-FreeRTOS.PATCH Description: 0001-Fix-off-by-one-bug-in-FreeRTOS.PATCH ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove "qP" from rtos code?
Backward compatibility is the reason - When I was testing with GDB+eclipse I found that OpenOCD received "qP" packets sometimes, and I think I implemented it first, before reading that same quotation you mentioned. Then when I implemented qThreadExtraInfo, I figured it was nicer to keep "qP" compatibility too. Regards, Evan Quoting Jie Zhang : Hi Evan, GDB manual says about "qP": Don't use this packet; use the `qThreadExtraInfo' query instead (see below). Since "qThreadExtraInfo" is already supported in rtos.c, why "qP" is still needed? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] threadid_t
I used int64_t for threadid because in the implementations I wrote for FreeRTOS and ThreadX, the threadid is actually the address of the thread control block. Hence if it is running on a 64 bit processor (currently unlikely) it would need a 64 bit address. Regards, Evan Quoting Jie Zhang : Hi Evan, I'm wondering why threadid_t is int64_t. Is there any known RTOS needs int64_t for its thread id? Can it be long? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic RTOS Detection
The code will not affect those who are not using a supported operating system. I have used the automatic thread awareness code with no problems in the following cases: * No RTOS - STM32 * FreeRTOS - STM32 * ThreadX - STM32 I agree the memory state issue is still a potential problem which would need resolving Evan Quoting Michel Catudal : Le 23/08/2011 03:47, Evan Hunter a écrit : 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... Evan It is a mistake. It could be available but disabled by defaults. There may be many people who use an RTOS but a lot more not using any and not planning to ever use any except some small version. Openocd should not make any assumption on how ram is used. To do that is opening a can of worms that cannot be close. It OpenOCD would be implemented like that I would have to make a fork of it. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic RTOS Detection
I think that this is highlighting a more general problem in OpenOCD: If GDB requests memory access, OpenOCD cannot tell if that memory access is allowable. I have run into this on Cortex-M3 devices, where the call stack always ends with a value 0xfffX which causes GDB to request memory read at this location, which does not exist. It is handled gracefully due to the ARM debug memory access port, but should really not happen in the first place... Evan -Original Message- Message: 6 Date: Tue, 23 Aug 2011 14:33:55 +0200 From: Michael Schwingen To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Automatic RTOS Detection Message-ID: <4e539e33.3080...@discworld.dascon.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 08/23/2011 02:10 PM, Evan Hunter wrote: > 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. > However, if there *is* no memory at those locations after reset, this scheme will not work when debugging the memory initialization code, so there needs to be some way to disable the RTOS support. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic RTOS Detection
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:rincew...@discworld.dascon.de] Sent: 23 August 2011 19:59 To: openocd-development@lists.berlios.de 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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic RTOS Detection
I missed answering some parts of your email... Making an option to turn it off should be simple, but is not currently implemented - I agree this should be done. The standard GDB thread commands can be employed to use it. There are no special commands required. The thread awareness is allows visibility of threads, stacks and locals for each thread, in the same way that native debugging does. If you use eclipse, or similar GUI front end, then the commands for retrieving threads and stacks are all automated, requiring only the "-rtos auto" config command. Evan -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Tuesday, 23 August 2011 5:35 PM To: Evan Hunter Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Automatic RTOS Detection If OpenOCD goes sniffing around at memory locations that can mess up e.g. debugging before memory controllers are set up and such. I could be convinced to have it enabled by default, if we had an option to turn it off. From a marketing point of view, having it enabled by default if it almost always works is great! I don't know how this feature works though... What does the user have to do? How does OpenOCD know whether the user is running FreeRTOS, ThreadX or eCos? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic RTOS Detection
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... Evan -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Tuesday, 23 August 2011 5:35 PM To: Evan Hunter Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Automatic RTOS Detection If OpenOCD goes sniffing around at memory locations that can mess up e.g. debugging before memory controllers are set up and such. I could be convinced to have it enabled by default, if we had an option to turn it off. From a marketing point of view, having it enabled by default if it almost always works is great! I don't know how this feature works though... What does the user have to do? How does OpenOCD know whether the user is running FreeRTOS, ThreadX or eCos? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic RTOS Detection
To enable RTOS awareness for everyone by default... My main reasoning, was that many users may not know that OpenOCD now has RTOS awareness, so it would be nice if it appeared by default when a supported RTOS was detected, rather than the user having to specifically enable it. I can't think of any cases where it would be a bad thing to be able to see thread states... Evan -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Tuesday, 23 August 2011 3:05 PM To: Evan Hunter Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Automatic RTOS Detection Why change the target scripts? Perhaps a config option like: openocd -c "rtos auto" -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FreeRTOS bug fixes
Hi All, Attached are two patches that fix bugs that I've found in FreeRTOS thread awareness. Regards, Evan Hunter Broadcom 0001-Fix-FreeRTOS-thread-list-parsing.patch Description: 0001-Fix-FreeRTOS-thread-list-parsing.patch 0002-Add-suspended-task-list-to-FreeRTOS-support.patch Description: 0002-Add-suspended-task-list-to-FreeRTOS-support.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Automatic RTOS Detection
Hi All, I would like propose that the TCL scripts for Cortex-M3 systems be updated to turn on automatic RTOS detection. What does everyone think? The effects should be benign if no known RTOS is detected... It would simply involve adding "-rtos auto" to the end of the target configure command in each case. Regards, Evan Hunter Broadcom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Provisional eCos RTOS support
Hi Alan,
I might be able to help:
Could you provide a list of what order you give GDB/OpenOCD commands and which
GDB-Remote commands/responses you see?
If you haven't already, I suggest putting packet prints into gdb_put_packet()
and gdb_input_inner().
Attached is a trace from my system with FreeRTOS.
The way I did it in the RTOS's was that if the current thread was set to 0 or 1
then it returned the current running context (i.e. the true register values).
This seems to avoid the problem you're having.
Some notes regarding RTOS awareness:
* You may need to fix the GDB bug described in
http://sourceware.org/bugzilla/show_bug.cgi?id=12648
* Generally you will want to make your OpenOCD script blank the device
memory so that the RTOS awareness does not read old, invalid thread information
Regards,
Evan Hunter
Date: Tue, 24 May 2011 21:59:55 +0100
From: Alan Bowman
mailto:alan.michael.bow...@gmail.com>>
To:
openocd-development@lists.berlios.de<mailto:openocd-development@lists.berlios.de>
Subject: [Openocd-development] Provisional eCos RTOS support
Message-ID:
mailto:banlktinhpe7tfzax78cuk1w_2z0_3yk...@mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"
I have been trying to add eCos/Cortex-M3 RTOS support to OpenOCD, and
have some code that seems to go some way toward doing the right thing.
The first patch adds that support - it contains a new file (based
heavily on the existing ThreadX/FreeRTOS model) to parse the thread
list. It's not the most efficient - it iterates over a linked list
twice - once to count the entries and once to parse out the
information. I couldn't see an explicit thread count variable to
parse, and I wanted to keep the code as similar to previous to
minimise my chances of making mistakes. I have also added a different
register-stacking structure in another file.
With that first patch in place, I found GDB would display the thread
list with "info threads" but would then become unstable (as described
in a previous email). I found that when GDB requested the current
thread ("qC") OpenOCD always replied with a generic response ("QC0").
I altered this to try to report the actual current thread, as in the
second patch. The first time GDB runs up, the instability still
occurs, since the request is sent before OpenOCD has parsed the thread
data. Stopping GDB and restarting it then seems to work OK, since a
current thread value is retained in OpenOCD's rtos data structure from
the last session. This seems like the wrong behaviour, but is
coincidentally sufficient to prevent GDB from complaining. I'd be
interested to hear if anyone has seen similar behaviour with other
RTOSs.
Testing for these patches has been performed using top-of-trunk eCos
running in a ROM startup configuration from a board like an
STM3210E-EVAL (but only using internal RAM). I've been using the
thread test programs that are part of the kernel test suite as test
applications.
I'm not sure how to take this further - I'm not sufficiently familiar
with GDB to diagnose the problem I'm seeing with the current-thread
reporting, but I want to put eCos support in front of others to get
some feedback.
Alan
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Add-eCos-Cortex-RTOS-support.patch
Type: application/octet-stream
Size: 19262 bytes
Desc: not available
URL:
<https://lists.berlios.de/pipermail/openocd-development/attachments/20110524/2396f62b/attachment.obj>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-Report-actual-current-thread.patch
Type: application/octet-stream
Size: 950 bytes
Desc: not available
URL:
<https://lists.berlios.de/pipermail/openocd-development/attachments/20110524/2396f62b/attachment-0001.obj>
--
req : qSupported
reply:
PacketSize=3fff;qXfer:memory-map:read+;qXfer:features:read-;QStartNoAckMode+
req : QStartNoAckMode
reply: OK
req : Hg0
reply: OK
req : ?
reply: S02
req : Hc-1
reply: OK
req : qC
reply: QC0
req : qAttached
reply: 1
req : qOffsets
reply: Text=0;Data=0;Bss=0
req : g
reply:
a5a5a5a5a5a5a5a50100a5a5a5a5a5a5a5a5a5a5a5a5c8460020a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5700a002031010008000
00
0002001Z
req : qXfer:memory-map:read::0,fff
reply: l
0x800
req : m8000130,4
reply: 00f072b8
req : qSymbol::
reply: qSymbol:5f74785f7468726561645f63757272656e745f707472
req : qSymbol::5f74785f7468726561645f63757272656e745f707472
reply: qSymbol:5f74785f7468726561645f637265617465645f707472
req : qSymbol
[Openocd-development] Verify checksum command patch and FT2232 channels patch
Hi all, Attached is a patch to add a new command 'verify_image_checksum' which does the same thing as 'verify_image' except that it doesn't find and print the differences. I've found this quite useful to run before downloading an image to check if the download is needed - if the jtag is running at high speed, on my STM32 it generally takes about 1 second to verify, saving 30 seconds to download - it also saves wearing out the flash memory. Also attached is an attempt at making the FT2232 jtag driver try other channels - currently it seems that if CHANNEL_ANY is selected, then only CHANNEL_A is tried. There may be a better way of doing this - my patch may not catch errors as well as the previous code. Regards, Evan Hunter 0001-Add-verify_image_checksum-command.patch Description: 0001-Add-verify_image_checksum-command.patch 0003-try-other-ft2232-channels.patch Description: 0003-try-other-ft2232-channels.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Error in RTOS code?
Hi Alan, Yes - this is a bug - probably a cut&paste error. It looks like, as you say, that there are two errors cancelling out. The target_read_buffer() function should reference the address variable. If you need an explanation of any parts of the code, let me know. You will probably find that eCos stacks register in the same order that FreeRTOS and ThreadX do on the Cortex-M3 platform. If that is the case, all you need to do is to implement the reading of the eCos thread list(s). Regards, Evan Hunter Quoting Alan Bowman : I'm looking through the new RTOS/thread code, with a view to adding eCos/Cortex-M3 support (if time and hardware allow) and I'm a bit confused by a section in src/rtos/rtos.c. In rtos_generic_stack_read():534, address is modified by the size of the stacked register set (having been set to the value of the stack_ptr). However, it is never used from that point on. Since this is a section of code that appears to be used by FreeRTOS/ThreadX I assume that it works, or they both have their stack growth direction set incorrectly and the two errors cancel out. Can anyone clarify? I think that line 536 should use address, rather than stack_ptr as the lookup address, but this would seem to break the existing examples. Cheers Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Wait-For-Interrupt instruction on STM32
Hi, I have an issue regarding the WFI instruction on a STM32. On the STM32, a particular bit must be set in order to maintain debug access during sleep (WFI). Imagine for a second a useless program where the first instruction is a WFI. Currently I'm finding that OpenOCD cannot handle such a program. (nor any other containing WFI) I think what is happening is that OpenOCD issues a reset, then releases reset, and by the time it tries to access memory addresses, the program has already started running and is sleeping in the WFI instruction. What I think should happen is that OpenOCD should control the startup out of reset, and ensure that the bit in the DBGMCU_CR register gets set before the program starts running. Any thoughts on how this can be achieved? Regards, Evan Hunter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error
Thanks Michel, I hadn’t had time to investigate it. Evan -Original Message- From: Michel JAOUEN [mailto:michel.jao...@stericsson.com] Sent: Tuesday, 19 April 2011 5:59 PM To: Evan Hunter; Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: RE: [Openocd-development] RTOS Thread awareness patch : amd64 compilation error Hello, I noticed a compilation error on rtos in linux 64 bits. Here is an attached patch. Best Regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch
Ah - those are in gdb_server.c Yes, you could have checks of target->rtos in the gdb_server file wherever an rtos function is called, however I think you'll find that already happens within the rtos functions themselves. I have no preference as to where the check occurs. Evan -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Tuesday, 12 April 2011 3:20 PM To: Evan Hunter Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] RTOS Thread awareness patch On Tue, Apr 12, 2011 at 5:59 AM, Evan Hunter wrote: > I'm not sure what you mean - when there is no "-rtos" parameter, the > only modified code in target.c that will be run is the initialization of > the rtos variables: I thought some extra packet types were handled differently as well? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch
I'm not sure what you mean - when there is no "-rtos" parameter, the only modified code in target.c that will be run is the initialization of the rtos variables: target->rtos = NULL; target->rtos_auto_detect = false; Evan -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Monday, 11 April 2011 11:06 PM To: Evan Hunter Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] RTOS Thread awareness patch In target.c, I'm wondering if we should modify the code to execute the same code path and have support for no new packages, unless the target->rtos is initialized. This would mean no change in behavior unless -rtos has been specified and we could merge it sooner rather than later. Thoughts? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RTOS Thread awareness patch
Hi Øyvind, The scanf format "%llx" does not work in MinGW. Perhaps some system specific macros are needed such as in the attached Evan -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Monday, 11 April 2011 11:03 PM To: Evan Hunter Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] RTOS Thread awareness patch Hi Evan, I got warnings/errors when building, so I've made some attempts at correcting these warnings/errors. How does this look? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer combined_diffs.patch Description: combined_diffs.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RTOS awareness for OpenOCD
Hi All, I have developed an extension to OpenOCD which allows it to be aware of an RTOS and pass thread information to GDB. It currently works for FreeRTOS and ThreadX on a Cortex-M3 but still has some work to get it cleaned up and fully reliable, but I am wondering what the procedure for integrating a fairly large change like this. The main changes are to /src/server/gdb_server/gdb_server.c, however the changes open the door for needing many source files for representing various RTOS threading implementations, so would probably require a new directory /src/rtos or similar. Basically the changes implement the qSymbol command which allows an OpenOCD then to look up the address of the RTOS task list. The task IDs are then passed to GDB via the qfThreadInfo and qsThreadInfo commands. GDB then requests extra information about each task, so the task Name/Status are obtained from the target. GDB also requests the register values, so the "g" command has been modified, so that it looks up the thread stack pointer, reads the registers pushed onto it, and passes them in place of the actual registers. I've implemented the RTOS specific code in a way that will not require copying of structures from non-open-licensed header files. This has been done by just having a list of byte offsets for each required location. I still need to figure out how to handle interrupts, as I'd like them to appear as separate threads, but currently they will obscure the currently running thread. Regards, Evan Hunter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
