On Oct 31, 2008, at 10:52 PM, Rick Altherr wrote:
On Oct 31, 2008, at 8:55 PM, Rick Altherr wrote:
On Oct 31, 2008, at 2:35 AM, Øyvind Harboe wrote:
The attached patch will address *some* of the problems you have
found.
If you can help with testing and get this committed, perhaps we can
On Oct 31, 2008, at 8:55 PM, Rick Altherr wrote:
On Oct 31, 2008, at 2:35 AM, Øyvind Harboe wrote:
The attached patch will address *some* of the problems you have
found.
If you can help with testing and get this committed, perhaps we can
see more clearly what's going on once the first coup
On Oct 31, 2008, at 2:35 AM, Øyvind Harboe wrote:
The attached patch will address *some* of the problems you have
found.
If you can help with testing and get this committed, perhaps we can
see more clearly what's going on once the first couple of bugs
are fixed.
The attached patch improves e
On Oct 31, 2008, at 11:52 AM, Steve Franks wrote:
It would help to know what revision of the SVN repository you
checked out.
Either way, the first error is that you tried to call "reset_run"
which
isn't a valid command. You want "reset run". Since that seems to be
originating from lpc2xxx
> It would help to know what revision of the SVN repository you checked out.
> Either way, the first error is that you tried to call "reset_run" which
> isn't a valid command. You want "reset run". Since that seems to be
> originating from lpc2xxx_armusbocd.cfg, your target config isn't getting
On Oct 31, 2008, at 11:41 AM, Steve Franks wrote:
On Fri, Oct 31, 2008 at 11:26 AM, Rick Altherr <[EMAIL PROTECTED]>
wrote:
On Oct 31, 2008, at 11:13 AM, Steve Franks wrote:
I've jut upgraded openocd, in hopes of finally pulling off a working
setup.
Some of the commands have dissappeared,
On Fri, Oct 31, 2008 at 11:26 AM, Rick Altherr <[EMAIL PROTECTED]> wrote:
>
> On Oct 31, 2008, at 11:13 AM, Steve Franks wrote:
>
>> I've jut upgraded openocd, in hopes of finally pulling off a working
>> setup.
>>
>> Some of the commands have dissappeared, notably,
>>
>> #run_and_halt_time 0 30
>>
On Oct 31, 2008, at 11:13 AM, Steve Franks wrote:
I've jut upgraded openocd, in hopes of finally pulling off a working
setup.
Some of the commands have dissappeared, notably,
#run_and_halt_time 0 30
#soft_reset_halt
#poll
Do I need these? Does anyone have a current file for programmin
I've jut upgraded openocd, in hopes of finally pulling off a working setup.
Some of the commands have dissappeared, notably,
#run_and_halt_time 0 30
#soft_reset_halt
#poll
Do I need these? Does anyone have a current file for programming an
.elf into a lpc2138 with no reset lines connected?
On Oct 31, 2008, at 10:33 AM, Steve Franks wrote:
On Fri, Oct 31, 2008 at 10:10 AM, Steve Franks
<[EMAIL PROTECTED]> wrote:
(#1)
I seem to have a reoccurring problem getting oocd to build on
freebsd,
because we keep our includes in /usr/local/include instead of
/usr/include. Six months a
On Fri, Oct 31, 2008 at 10:10 AM, Steve Franks <[EMAIL PROTECTED]> wrote:
> (#1)
>
> I seem to have a reoccurring problem getting oocd to build on freebsd,
> because we keep our includes in /usr/local/include instead of
> /usr/include. Six months ago, configure
> --includedir=/usr/local/include wo
(#1)
I seem to have a reoccurring problem getting oocd to build on freebsd,
because we keep our includes in /usr/local/include instead of
/usr/include. Six months ago, configure
--includedir=/usr/local/include worked like a charm, but now it
doesn't. If I manually add -I$(includedir) to INCLUDES
I was debugging a problem today where changing the pc
before a step failed. The problem was that the arm_simulate()
would use the value of pc *before* I changed it.
Some caching problem or other going on...
This problem smells like the xscale problem reported earlier
today and the luminary flash
On Oct 31, 2008, at 2:35 AM, Øyvind Harboe wrote:
The attached patch will address *some* of the problems you have
found.
If you can help with testing and get this committed, perhaps we can
see more clearly what's going on once the first couple of bugs
are fixed.
The attached patch improves e
On Oct 30, 2008, at 11:57 PM, Øyvind Harboe wrote:
On Fri, Oct 31, 2008 at 6:57 AM, Rick Altherr <[EMAIL PROTECTED]>
wrote:
On Oct 30, 2008, at 1:06 AM, Øyvind Harboe wrote:
On Thu, Oct 30, 2008 at 5:39 AM, Rick Altherr <[EMAIL PROTECTED]>
wrote:
On Oct 28, 2008, at 1:12 PM, Øyvind Harb
Committed.
Added telnet_async command to enable/disable asynchronous
messages.
By default they are disabled, which speeds up debugging while
telnet is open.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
### Eclipse Workspace Patch 1
> So async telnet messages enable/disalbe option then?
>
> Off by default?
That's my vote. Having them on slows down debugging a lot.
> The C code is of course the ultimate in flexibility, which is why open
> source is such fun.
>
> I hate systems with lots of incomprehensible and undocumented
> I like to have as many configuration options as is necessary and no
> more.
I agree in principle, but that's a difficult thing to nail down because
what's necessary for one may not be necessary for another.
> I hate configuration options that are there just because the problem of
> how to solv
> 3. add an option(yuk!) of sorts. Perhaps remove asynchronous messages
> by default and make it possible to enable them? Who's going to find
> this option anyway?
I don't think adding a 'verbose' option to turn something like this on is
terrible by any means.
You get this information inside of GD
On Fri, Oct 31, 2008 at 1:43 PM, Chris Zimman <[EMAIL PROTECTED]> wrote:
>> So async telnet messages enable/disalbe option then?
>>
>> Off by default?
>
> That's my vote. Having them on slows down debugging a lot.
OK.
>> The C code is of course the ultimate in flexibility, which is why open
>> s
On Fri, Oct 31, 2008 at 1:38 PM, Chris Zimman <[EMAIL PROTECTED]> wrote:
>> 3. add an option(yuk!) of sorts. Perhaps remove asynchronous messages
>> by default and make it possible to enable them? Who's going to find
>> this option anyway?
>
> I don't think adding a 'verbose' option to turn somethi
On Fri, Oct 31, 2008 at 1:06 PM, Federico Spadini <[EMAIL PROTECTED]> wrote:
> Hi Guys,
>
>
>
> I've recently built OpenOCD SVN version 1112 under Ubuntu Linux 8.04
> on AMD64 with the proper FTDI libraries. The target board is an iMote2
I'd like the imote2.cfg added to the target library. How is
The attached patch will address *some* of the problems you have
found.
If you can help with testing and get this committed, perhaps we can
see more clearly what's going on once the first couple of bugs
are fixed.
The attached patch improves error handling.
Testing is needed for each point below
I've been poking at this for a few days but my understanding of JTAG
is limited so I'm not getting much further. It seems that when I use
OpenOCD to flash an lm3s6965 it will fail under certain
circumstances. I don't have any other Cortex-M3 targets to test, but
I believe the bug is in th
Single stepping in GDB while the telnet window is open
doesn't work terribly well.
There are oodles of these messages appearing when stepping.
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x6013 pc: 0x0203c5dc
Obivously that's not helpful.
25 matches
Mail list logo
