On Monday 21 September 2009, Øyvind Harboe wrote:
> Could he be repairing a bug in the driver where the
> driver does not track the JTAG state correctly after
> a srst that pulls trst?
Could be; I hope he reports what's up ... :)
___
Openocd-development
On Tue, Sep 22, 2009 at 12:03 AM, David Brownell wrote:
> On Monday 21 September 2009, Rolf Meeser wrote:
>> I've added a call to jtag_add_tlr(), and that solved it for me.
>> All relevant EmbeddedICE registers are now reprogrammed.
>
> Did you try for example just adding a bunch of TCK cycles,
>
Have you tried firing up openocd in the debugger?
CFLAGS="-O0 -g" configure ...
insight --args openocd args
Hook up scope and set a breakpoint in main(), start debugging...
--
Øyvind Harboe
ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html
Embedded software and hardware consulting servic
On Monday 21 September 2009, Freddie Chopin wrote:
> > + puts "WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG"
> > +}
>
> I also thought about that, but... in here such line does not print any
> output in the console... It doesn't get printed even with "-d 3", so I
> have no idea
On Monday 21 September 2009, Johnny Halfmoon wrote:
> Okay. Like this then:
Merged with some cleanups, including the one noted by Rolf.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/o
Duane Ellis pisze:
> 2) Only thing I can think of is this.. type of a change
>But that is a minor thing, I hate hidden default values.
>They are MAGIC - that always mess me up, been burned one too many
> many times.
>
> +# check for RESET_CONFIG - if not defined set the default: trst_and
Freddie Chopin wrote:
> Here is the patch that adds the lpc2xxx_internals.tcl file and
> modifies all lpc2xxx (ARM7) files to use that.
1) Looks good, I agree the "reset" issue can be resolved later.
2) Only thing I can think of is this.. type of a change
But that is a minor thing, I hate hi
I checked out r2726 and applied the patch. It works great during 'reset
halt/init/run/etc' but again does not do anything for initial JTAG scan.
I hooked up scope to the srst and trst to see how the jtag controller
drives those signals.
For the initial reset (before first JTAG scan) I get about 1
On Monday 21 September 2009, Rolf Meeser wrote:
> I've added a call to jtag_add_tlr(), and that solved it for me.
> All relevant EmbeddedICE registers are now reprogrammed.
Did you try for example just adding a bunch of TCK cycles,
via runtest? Or maybe just reading a register? (There's
code els
On Monday 21 September 2009, Johnny Halfmoon wrote:
>
> David Brownell wrote:
> > On Sunday 20 September 2009, Johnny Halfmoon wrote:
> >> + if ((retval = flash_check_sector_parameters(cmd_ctx,
> >> first, last, p->num_sectors)) !
> >
> > I had in mind more like
> >
> > uint32
Here is the patch that adds the lpc2xxx_internals.tcl file and modifies
all lpc2xxx (ARM7) files to use that.
4\/3!!
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg (revision 2744)
+++ tcl/target/lpc2103.cfg (
Hi Johnny,
it should be
> +if ( first > last ) {
not
> +if ( first >= last ) {
With first=last you can erase a single sector.
Regards,
Rolf
--- Johnny Halfmoon schrieb am Mo, 21.9.2009:
> Von: Johnny Halfmoon
> Betreff: Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as las
David Brownell wrote:
> On Sunday 20 September 2009, Johnny Halfmoon wrote:
>> + if ((retval = flash_check_sector_parameters(cmd_ctx, first,
>> last, p->num_sectors)) !
>
> I had in mind more like
>
> uint32_t value;
Okay. Like this then:
= = = = = = = = = = = =
doc/
Hi,
Im using LPC2364 with modified sample target/lpc2378.cfg with
interface/jtagkey2.cfg and with modification reset_config none (I dont have
connected reset to JTAG). My GDB flash init is:
target remote localhost:
monitor soft_reset_halt
monitor gdb_breakpoint_override hard
d
b main
c
And
I'm wondering if it would be a good idea to modify the handling
of GDB halted/running state as follows:
- do nothing upon attaching GDB to OpenOCD. This gives
the GDB init script more freedom w.r.t. what should happen
when connecting to the target.
- if the target is running and GDB is halted, the
Øyvind Harboe pisze:
> When it's ready it should be committed, but I think this is one
> thing that either is ready by the time we cut 0.3 or not, we don't
> push out 0.3 for these changes.
For me, the main cfg files layout is ready, I can make a patch even
today. I'm just waiting for the opinion
Rolf Meeser pisze:
> I had problems with the "reset init" on LPC2478, too. I didn't analyze it
> deeply, but I noticed this problem:
>
> OpenOCD reported that it couldn't halt the target. With debug on, I got the
> impression that the EmbeddedICE had been programmed for a break before the
> fin
On Mon, Sep 21, 2009 at 7:04 PM, Freddie Chopin wrote:
> Øyvind Harboe pisze:
>>
>> Does anyone have a bunch of stuff that will be completed in the near
>> future?
>
> How about that new LPC2xxx cfg files layout?
>
> With a bit of investigation the "reset init" should be working, or that can
> be
David Brownell pisze:
> Normally a "reset halt" should have caused MAM and PLL to
> enter their just-after-hard-reset hardware default states ...
>
> Are you saying those hardware default states cause problems?
> If so, that seems buggy. I'm not sure where the issue would
> lie, but it's hard to
Just recording this in case other folk see it and wonder
what's going on ... or have suggestions about how to handle
such things better:
Environment:
ft2232d based JTAG adapter
OpenOCD 0.3-dev
arm926, running Linux
*NO BOOT LOADER ACCESSIBLE* (booted via OpenOCD)
Hello,
My company is developing a JTAG debugger for internal use. We expect to start
using it within a week or so, though there are other capability requests that
would make use of the FT4232H advantageous.
Can we rely on the ft4232h today, or should we place a pair of ft2232Ls and a
USB hub fo
On Saturday 19 September 2009, Freddie Chopin wrote:
> 1. When there is "soft_reset_halt" in the script:
>
> v1 fails - target not halted
> v1 (without load) - works
> v2 fails - target not halted
> v2 (without load) - works
>
> But: When I want to load I have to do:
>
> monitor reset halt
> loa
On Saturday 19 September 2009, Freddie Chopin wrote:
> I don't know how should the GDB initialization commands look like:
>
> monitor reset init
> load
> (let's call that "v1")
That should work. If it doesn't, there's a bug lurking somewhere.
> or maybe:
>
> monitor reset halt
> monitor reset
On Monday 21 September 2009, Øyvind Harboe wrote:
> 0.3 anyone?
>
> There's lots of good progress since 0.2.
>
> Does anyone have a bunch of stuff that will be completed in the near future?
Yeah, I was going to comment on this ...
I'm chasing down stuff to make sure that new JTAG event behaves
Hi,
I had problems with the "reset init" on LPC2478, too. I didn't analyze it
deeply, but I noticed this problem:
OpenOCD reported that it couldn't halt the target. With debug on, I got the
impression that the EmbeddedICE had been programmed for a break before the
final SRST/TRST happened. The
On Monday 21 September 2009, Petri Pirttinen wrote:
> > - JTAG_FREQ - CRYSTAL_FREQ / 8 works for me all the times, but
> > CRYSTAL_FREQ / 6 - not (in the .tcl file I divide by 8 now)
>
> Agreed. Divided by 8 seems to be a more stable option in here as well.
div/6 is *ABSOLUTE BEST CASE* that mor
On Monday 21 September 2009, Petri Pirttinen wrote:
> What is the purpose of reset-init event? In my opinion it is where we
> want to get things back to the beginning.
A "reset halt" is intended to reset and cause a halt before
execution of the first post-reset instruction. That's "back
to the b
Øyvind Harboe pisze:
> Does anyone have a bunch of stuff that will be completed in the near future?
How about that new LPC2xxx cfg files layout?
With a bit of investigation the "reset init" should be working, or that
can be left for future, as now this script is not fully functional either...
4
0.3 anyone?
There's lots of good progress since 0.2.
Does anyone have a bunch of stuff that will be completed in the near future?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development maili
> What is the purpose of reset-init event?
"reset init" puts a target that is reset into the halted state,
into a state where gdb load, flash programming, etc. will work.
I.e. that the target is ready to be debugged or programmed.
the reset-init event is the most straightforward way to implemen
>>> Why are you doing a soft_reset_halt?
>> Why not?
>>
>> If this command is forbidden / wrong / whatever - remove it. If it's not,
>> why do you care if I use it? Without that command it does not work. Or maybe
>> I just don't understand the meaning of "reset init"? For me that is "do a
>> reset,
> BTW I have also attached a reset-init script that not only does a
> soft_reset_halt and vector table remap, but also disables MAM and PLL
> after reset - without that two steps I experienced really crazy
> behaviour in a very simple and correct code while debugging.
This is a little bit same
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe
> Sent: maandag 21 september 2009 11:28
> To: Jiří Kubias
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-developm
I've heard this concern many times, but I guess at the end of the
day experienced embedded engineers have an edge
Embedded development *is* quite involved... Also tools are
quite rough around the edges because any particular MCU
has a very narrow audience.
There are *literally* 1 differen
Hi,
because I'm particularly newbie in Linux debugging, I have another view than
you. Im trying to run jtag + openocd + gdb + something (Eclipse) to run, and
there is several another problems than openocd which needs to be solved.
Jtag + openocd + gdb runs perfectly (if you find your jtag and chip
To Laurent Gauch: Did you received my private email?
Jiri Kubias
2009/9/17 Laurent Gauch
> Hi Jir(í Kubias,
>
> Good to know you resolved your problem using GDB / OpenOCD / Amontec
> JTAGkey-2 for your lpc2378 board.
> Also, thank you for giving the how you have resolved the issue. It is nice
>
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe
> Sent: zondag 20 september 2009 19:53
> To: openocd-development@lists.berlios.de
> Subject: [Openocd-development] A few thoughts on
Rolf,
Yes - I'm running without defining a working area. Unfortunately, I
seem to be getting the sort of write speeds normally reserved for
paper tape and acoustic couplers. (which is why I called for help on
this list!)
I was hoping that block write and/or fastdata would help me out.
I can
Attached is the board config I've written for the CSB732, including
basic clocking and SDRAM initialization.
Single stepping and burst writing work correctly. I haven't tried flashing.
Regards,
Ethan
# The Cogent CSB732 board has a single i.MX35 chip
source [find target/imx35.cfg]
# Determine
Hi Stephan,
Thanks!
I just saw that you are using a MIPS processor. The cfi_spansion_write_block()
function supports ARM targets only. Currently this executes ARM opcodes on your
machine, so you can be lucky that it returned at all :-)
There is no checking the architecture yet.
I believe your
40 matches
Mail list logo