Hello Gary :-)
On Tue, Aug 23, 2011 at 2:24 AM, Gary Carlson
gcarl...@carlson-minot.com wrote:
I have zero prior experience with the FT2232 so I took a very brief scan of
its driver code. I get the feeling that this type of device allows fairly
low-level access to interface port pins. If
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
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
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.
On Tue, Aug 23, 2011 at 9:47 AM, Evan Hunter ehun...@broadcom.com 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
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
Then perhaps we only need to clearly state in the manual the the GDB command
to turn off threads?
--
Ø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/
___
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
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.
Disable threads using gdb command to do so before connecting?
--
Øyvind Harboe - Can Zylin Consulting help on
On 08/23/2011 12:24 PM, Øyvind Harboe wrote:
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.
Disable threads using gdb command to do so before connecting?
If there is such a command, that is OK with me.
I got the impression it had yet to be implemented.
That's what I though too :-) I don't know what that gdb command
is though...
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87
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
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
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.
That's necessary but not sufficient.
There needs to be a way that the user can easily discover
Hi Tomek,
I think the solution with high-level interfaces is to allow them to do their
bitstream magic directly if they have that capability and for low-level
interfaces turn to libswd or other future libraries for other transports. I
have doubts about the feasibility of trying to make most
Hello Gary :-)
On Tue, Aug 23, 2011 at 3:43 PM, Gary Carlson
gcarl...@carlson-minot.com wrote:
I think the solution with high-level interfaces is to allow them to do their
bitstream magic directly if they have that capability and for low-level
interfaces turn to libswd or other future
In one sentence, as my preference for future extendability I have
chosen approach that involves modular design with external submodules
(just like in object programming) rather than extending one big
structure (i.e. command queue) like it was done before. This should
allow adding new
Hi,
this one could go on the bug fix release
Best Regards,
J.
On 21:22 Mon 22 Aug , Evan Hunter wrote:
Hi All,
Attached are two patches that fix bugs that I've found in FreeRTOS thread
awareness.
Regards,
Evan Hunter
On Mon, Aug 22, 2011 at 9:10 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 19:35 Tue 09 Aug , Jean-Christophe PLAGNIOL-VILLARD wrote:
tested in buildroot
any comments?
Spelling error:
+ LDFLAGS=$LFFLAGS $LIBUSB_LDFLAGS
I'm pretty sure I've seen some hard
Do we need a bugfix release?
When is the next release?
If someone needs a bugfix badly, then there is always git...
--
Ø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/
Hi,
I'm bringing up the TMS570 usb stick devkit (part# TMDX570LS20SUSB) with
OpenOCD.
I've gotten the target configuration working and I'd like to contribute the
target and board files, since it had a few hoops to jump through (ICEPICK,
no SRST, etc.).
I'm still trying to get the flash driver
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
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
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
Hi,
In OpenOCD, all gdb packet handling functions look like:
gdb_xxx_packet(connection, target, packet, packet_size);
I'm wondering if we can remove target from the argument list and just
calculate it from connection in each handling function. The patch is
attached.
I like this patch since I
I'm OK with this.
Perhaps make a tiny static fn for:
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40
26 matches
Mail list logo
