I often use openOCD and GDB/Insight to attach to a running target that I
don't want to halt, or even cannot halt it during my debugging session.
I just want to take to see the call stack and program counter when it
crashes or when it reaches a special code line.
It's not a good idea to force
On 02.05.2011 21:57, Jie Zhang wrote:The advantage of this approach is
(amongst many other things) that
attaching to the target does *nothing*. Via monitor commands, you can
easily manipulate the target, e.g. issuing a monitor halt.
I would say that this is confusing for a new user, like me,
On 02.05.2011 22:44, Jie Zhang wrote:
On Mon, May 2, 2011 at 3:52 PM, Michael Trensch mtren...@googlemail.com
wrote:
I often use openOCD and GDB/Insight to attach to a running target that I
don't want to halt, or even cannot halt it during my debugging session.
I just want to take to see
On 02.05.2011 23:07, Peter Stuge wrote:
I think most of the scripts show how to work with openOCD but you
will need to override some functions to make them fit your needs.
It's a huge usability deficiency. :\
I don't think so. The provided scripts work out of the box and are working.
But I
Hiho,
I recently submitted a patch for the netX chips and now I remarked that
one of the included interfaces may vary depending of the revision of
this Board.
It is only the variable ft2232_device_desc which now includes an
additional space.
I've got two boards at work and they have a different
Hi Øyvind,
On 02.01.2011 20:29, Øyvind Harboe wrote:
Hiho,
I was just trying to port the netX scripts to the new target script
structure with the setup_target proc. I remarked that the script
changes seem to be fitted to real embedded processors with all
peripherals on the die. But this
Hiho,
I was just trying to port the netX scripts to the new target script
structure with the setup_target proc. I remarked that the script
changes seem to be fitted to real embedded processors with all
peripherals on the die. But this chip does not own an internal flash
memory and the flash / ram
On 20.12.2010 15:58, Kenan Özdemir wrote:
Hi,
I already turned off the optimization, and there is no return in my main.
my code looks like this:
**
Any function will return if it reaches the end of scope, with or without
return. The only difference is a compiler warning if a return
to correctly develop using git
and how to create/post patches. ;)
Regards,
Michael
From 58d613ea138f1dbcb70c8f438557769e49516e81 Mon Sep 17 00:00:00 2001
From: Michael Trensch mtren...@googlemail.com
Date: Thu, 16 Dec 2010 15:33:16 +0100
Subject: [PATCH] Add support for Hilscher netX controllers
On 16.12.2010 16:05, Peter Stuge wrote:
Øyvind Harboe wrote:
Any objections?
No. Keep in mind to create patches with -M -C when renaming or
copying a file in a commit. Maybe some surgery would be good to make
sure that the file rename is a rename in the repo. OTOH maybe it
doesn't matter.
On 16.12.2010 16:39, Peter Stuge wrote:
Hm. Did you actually rename the file, or copy/paste into a new file?
Maybe the line endings got switched around; git usually has
unix-style line endings for all files, and can do automatic
conversion on checkout if desired. Once that starts getting used
On 16.12.2010 16:58, Peter Stuge wrote:
Michael Trensch wrote:
Probably it was an error to keep two branches and merge them by hand.
I've made the changes in a temporary test environment and tried to merge
the stuff.
1. cloned openocd's GIT repo
2. git mv tcl/target/netx500.cfg tcl/target
Hi together,
I made some config scripts for the Hilscher netX chips and several
evaluation boards. I am currently preparing to get them added and now I
have some questions how they should look like, as I am currently having
a large script for each board / JTAG combination, containing all options
13 matches
Mail list logo
