Hello Zach,
it looks that the 1893 solve the problem here with the SAM7.
Only a short test with the SAM7 and LPC2294. I have compare
the jtag.c and ft2232.c against my 1888+patch version. Both
files are equal. Therefore I suppose that the 1893 is working
like the 1888+patch here. In the moment no
Hello David,
>I was running with the ft2232 and jtag patches ('92, '93),
>and they didn't seem to resolve that issue.
Which issue didn't seem to resolve?
In which case you have problems, with which targets?
Regards,
Michael
-Ursprungliche Nachricht-
Von: David Brownell [mailto:davi...
Hello Xiaofan,
>I have not tried to use flashing so far. So today I tried to learn how to
>flash the LPC2148 on board of the Olimex LPC-P2148.
>
>I tried to halt the target and then use
>"flash write_image isoc_io_sample.hex 0x0 ihex" but this does
>not seem to work.
Here I have a Olimex LPC-P21
On Sun, May 24, 2009 at 4:08 PM, Michael Fischer wrote:
> Here I have a Olimex LPC-P2148 board too, tested with a FT2232
> device under windows, with the r1893.
>
> For testing, I have a short hex file, called test_rom.hex
>
> 1) flash write_image test_rom.hex 0x0
> 2) dump_image dump.bin 0x0 364
Dick Hollenbeck skrev:
> Zach,
>
> I think this patch is fundamentally wrong and is a disaster the moment
> it is applied.
>
> The queue sits between the jtag api and the drivers. The api calls
> track "future" state according to the most recent api call submitted
> (and put onto the back end o
Hi
This looks like a reset problem, not a write to flash problem. This is
the type of problems we are trying fix with the latest jtag/jlink/ft2232
patches.
What is the target configuration.
Best regards
Magnus
Xiaofan Chen skrev:
> Relative long email.
>
> I have not tried to use flashing so
On Sun, May 24, 2009 at 5:02 PM, Xiaofan Chen wrote:
> On Sun, May 24, 2009 at 4:42 PM, Xiaofan Chen wrote:
>> I am using the following simple script and J-Link V3.
>> I will try yours as well.
>>
>
> With your script (replace with JLink) it seems to be ok. Thanks.
> Occasionally there are some t
On Sun, May 24, 2009 at 4:42 PM, Xiaofan Chen wrote:
> I am using the following simple script and J-Link V3.
> I will try yours as well.
>
With your script (replace with JLink) it seems to be ok. Thanks.
Occasionally there are some timeout though.
mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3/
Dirk Behme skrev:
> Zach Welch wrote:
>
>> On Fri, 2009-05-22 at 10:57 +0200, Øyvind Harboe wrote:
>>
>>> Trying again...
>>>
>>> My editor is screwing things up with whitespace, hence all those irrelevant
>>> changes...
>>>
>> The second attempt was no better. Here it is done right
On Sun, May 24, 2009 at 5:04 PM, Magnus Lundin wrote:
> Hi
>
> This looks like a reset problem, not a write to flash problem. This is the
> type of problems we are trying fix with the latest jtag/jlink/ft2232
> patches.
>
> What is the target configuration.
>
Here it is.
source [find target/lpc2
Hello Xiaofan,
>With your script, I can flash the files and I can halt the target.
>However the flashing is apparently not correct as it does not
>work. Using lpc21isp it works.
first of all I think it is a checksum problem which control a
valid user code. Take a look in the LPC2148 user manual.
Hello list,
now I could reproduce the problem here with the original
Olimex BLINK example. It will not work, the problem is the
checksum.
The startup code looks like:
_vectors: ldr PC, Reset_Addr
ldr PC, Undef_Addr
ldr PC, SWI_Addr
Hello List,
I have added the options calc_checksum to the flash driver
of the LPC2148 target. This was forgotten here. All other
LPC targets use this option.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.
Sorry I take back my earlier comment. I didn't check tap_set_state()
and only assumed that it wraps cmd_queue_cur_state. But it doesn't and
I just checked the patch on arm11 and it breaks arm11.
When arm11 queries cmd_queue_cur_state it wants to know in what state
the previously queue command left
On Sun, May 24, 2009 at 7:03 PM, Michael Fischer wrote:
> Attached is the main.hex file which should work with the lpc2148 without
> the calc_checksum key. LED1 and LED2 are flashing.
Yes this works well with my V3 Black Jlink. The two LEDs are flashing now.
I updated to the latest SVN with your
On Sun, May 24, 2009 at 8:55 PM, Xiaofan Chen wrote:
> On Sun, May 24, 2009 at 7:03 PM, Michael Fischer
> wrote:
>
>> Attached is the main.hex file which should work with the lpc2148 without
>> the calc_checksum key. LED1 and LED2 are flashing.
>
> Yes this works well with my V3 Black Jlink. The
Hello Xiaofan,
I have tesed to flash the program here. I could flash it
with my ft2232 device. I do not check the functionality
of the program itself, LED1 was flashing.
>2) And it seems to have reset/halt problem.
This is correct, I could not get in contact with OpenOCD.
And I could not get in c
Hello Xiaofan,
Saturday, May 23, 2009, 2:17:33 PM, you wrote:
XC> On Tue, May 19, 2009 at 8:26 AM, Igor Skochinsky wrote:
>> What I mean is I could write up a list of missing/underdocumented
>> commands and describe their input/output parameters. I don't have a
>> J-Link so I don't really need t
I´ll try out the trunk when I get back into the office. Here is the
patch that I forgot to attach. I think regardless of whether the
trunk works this patch is a good idea just to be safe.
On Sun, May 24, 2009 at 12:29 AM, Zach Welch wrote:
> On Sat, 2009-05-23 at 21:06 -0700, David Brownell w
Fix a bug that joined us at the last minute, when an efficient
alloca() call got swapped out for a more portable malloc().
Also log one error, to give a clue in case it appears "in the wild".
---
src/flash/davinci_nand.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Fix a bug t
The "Illegal mode for command" diagnostic is deeply useless.
Say "Command '%s' only runs during configuration stage" instead,
letting users know what the real issue is.
---
src/helper/command.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The "Illegal mode for command" diagnostic is d
Make startup for the various server ports be quiet, unless
debugging is active: don't emit needless scarey messages.
Update the relevant documentation and its references:
- For these port commands ... cover the default values;
convert to @deffn syntax; include their use outside of
the conf
Doc (mostly) update for jtag_khz:
- switch to @deffn syntax
- add entry for "jtag_rclk"
- move deprecated "jtag_speed" into collection of deprecated calls
And for ft2232, don't be the only adapter to *log* an error if RTCK
is requested; it's already reported properly, like any other nonfatal
c
On Sunday 24 May 2009, David Brownell wrote:
> - move deprecated "jtag_speed" into collection of deprecated calls
Also, I think all those deprecated calls should be issuing runtime
warnings, nudging scripts to get rid of their usage. Without such
nag messages, it won't be practical to get rid of
On Sun, 2009-05-24 at 13:38 -0700, David Brownell wrote:
> Fix a bug that joined us at the last minute, when an efficient
> alloca() call got swapped out for a more portable malloc().
>
> Also log one error, to give a clue in case it appears "in the wild".
> ---
> src/flash/davinci_nand.c |6
On Sun, 2009-05-24 at 13:45 -0700, David Brownell wrote:
> The "Illegal mode for command" diagnostic is deeply useless.
> Say "Command '%s' only runs during configuration stage" instead,
> letting users know what the real issue is.
> ---
> src/helper/command.c |2 +-
> 1 file changed, 1 insert
On Sun, 2009-05-24 at 13:49 -0700, David Brownell wrote:
> On Sunday 24 May 2009, David Brownell wrote:
> > - move deprecated "jtag_speed" into collection of deprecated calls
>
> Also, I think all those deprecated calls should be issuing runtime
> warnings, nudging scripts to get rid of their usa
On Saturday 23 May 2009, Zach Welch wrote:
> 1) library header file rework:
> a) rename src/ as openocd/ (preferred)
> - this will allow public #include, e.g.
> b) do not rename src, e.g. #include
> - something needs to be done; the library work is only half-complete
> - i have a pat
On Sun, 2009-05-24 at 13:46 -0700, David Brownell wrote:
> Make startup for the various server ports be quiet, unless
> debugging is active: don't emit needless scarey messages.
> Update the relevant documentation and its references:
>
> - For these port commands ... cover the default values;
>
On Saturday 23 May 2009, Zach Welch wrote:
> 2) move board, target, and interface Jim script directories to src/tcl/
> - this will move the whole directories intact, parallel to tcl/chip.
> - more structure can be added, if we see fit; this is a small step.
> -
> http://www.mail-archive.com/
On Sun, 2009-05-24 at 13:47 -0700, David Brownell wrote:
> Doc (mostly) update for jtag_khz:
> - switch to @deffn syntax
> - add entry for "jtag_rclk"
> - move deprecated "jtag_speed" into collection of deprecated calls
>
> And for ft2232, don't be the only adapter to *log* an error if RTCK
>
On Saturday 23 May 2009, Zach Welch wrote:
> 5) commit testing tools
> - one-step smoke tests! I probably need another week for this.
> - all in-tree with no new dependencies (maybe a Perl module or two)
> -
> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04030.html
W
On Sunday 24 May 2009, Zach Welch wrote:
>
> > Also, I think all those deprecated calls should be issuing runtime
> > warnings, nudging scripts to get rid of their usage. Without such
> > nag messages, it won't be practical to get rid of those commands.
>
> I agree. Care to submit another patch
On Saturday 23 May 2009, Zach Welch wrote:
> - others?
Areas where I'd like to see continued improvement during
the remainder of this cycle:
- Less server message spam. Servers should only log
messages when something's *seriously* wrong, and
should not rely on stdout except maybe during
On Sun, 2009-05-24 at 14:06 -0700, David Brownell wrote:
> On Saturday 23 May 2009, Zach Welch wrote:
> > 1) library header file rework:
> > a) rename src/ as openocd/ (preferred)
> > - this will allow public #include, e.g.
> > b) do not rename src, e.g. #include
> > - something needs
DAVID>
> Ways other folk can help with the doc+code audits
> are to pick a section of the texi and convert it to
> use the @deffn presentation style ... then crosscheck
> against the code.
>
Can you expand on this, explain a little bit more what you mean.
I think, @deffn -is a "texi" type docu
On Sun, 2009-05-24 at 17:51 -0400, Duane Ellis wrote:
> DAVID>
> > Ways other folk can help with the doc+code audits
> > are to pick a section of the texi and convert it to
> > use the @deffn presentation style ... then crosscheck
> > against the code.
> >
>
> Can you expand on this, explain a
On Sunday 24 May 2009, Zach Welch wrote:
> > I'd suggest instead creating a
> > new include/ area to hold only files which will be getting
> > commitment for such public usage.
>
> This is common and I suppose that I should have listed it (to be fair),
> but I am not a particular fan
On Sunday 24 May 2009, Duane Ellis wrote:
> DAVID>
> > Ways other folk can help with the doc+code audits
> > are to pick a section of the texi and convert it to
> > use the @deffn presentation style ... then crosscheck
> > against the code.
>
> Can you expand on this, explain a little bit more wha
On Sunday 24 May 2009, Zach Welch wrote:
> The OpenOCD User Guide: (aka The Guide)
"Someone" needs to change the name of the document then;
it's now "Open On-Chip Debugger (OpenOCD)". Agreed that
calling it a "User's Guide" would clarify.
> - should start to focus on _using_ OpenOCD
> - written
On Sun, 2009-05-24 at 15:28 -0700, David Brownell wrote:
> On Sunday 24 May 2009, Zach Welch wrote:
> > The OpenOCD User Guide: (aka The Guide)
>
> "Someone" needs to change the name of the document then;
> it's now "Open On-Chip Debugger (OpenOCD)". Agreed that
> calling it a "User's Guide" wou
On Sun, May 24, 2009 at 11:10 PM, Michael Fischer wrote:
> Hello Xiaofan,
>
> I have tesed to flash the program here. I could flash it
> with my ft2232 device. I do not check the functionality
> of the program itself, LED1 was flashing.
In my test, LED 1 is also flashing. The USB virtual
com port
zach> [previous things]
david>
Well, yes ... what eventually goes into /usr/include should
be strongly limited to the interfaces. How anything gets
implemented inside the library is nobody's busienss except
for the library maintainers'. They should be able change
how they do things easily. But
On Wednesday 20 May 2009, Tiago Maluta wrote:
> I'd like to know if OpenOCD support AVR32 (AP7000) processors?
Not yet. I'd partition that work in two parts:
- "Nexus" [3] framework, which could support more than
just the AVR32 chips.
- AVR32-specific support. Probably not just the AP7 de
On Sun, 2009-05-24 at 15:24 -0700, David Brownell wrote:
> On Sunday 24 May 2009, Zach Welch wrote:
> > >I'd suggest instead creating a
> > > new include/ area to hold only files which will be getting
> > > commitment for such public usage.
> >
> > This is common and I suppose that I s
On Sunday 24 May 2009, Duane Ellis wrote:
>
> Really, we need to think *STRONGLY* about *NOT* creating "libopenocd" -
> I believe creating "libopenocd" will be a nightmare (ie: the
> implementation details in concrete)
>
> I believe that a public *SOCKET* interface with a *TEXT* based protocol
Why not deprecate/change, all "u32" to "uint32_t" - wholesale?
Likewise for others.
Any reason not to? I mean "stdint.h" does exist, or a "reasonable equal"
can be made via "types.h".
-Duane.
___
Openocd-development mailing list
Openocd-development@li
On Sun, 2009-05-24 at 20:53 -0400, Duane Ellis wrote:
> zach> [previous things]
> david>
> > Well, yes ... what eventually goes into /usr/include should
> > be strongly limited to the interfaces. How anything gets
> > implemented inside the library is nobody's busienss except
> > for the library m
On Sun, 2009-05-24 at 21:12 -0400, Duane Ellis wrote:
> Why not deprecate/change, all "u32" to "uint32_t" - wholesale?
> Likewise for others.
+1 from me. Got a patch? I could even take care of this at some point,
as it should be an entirely sed-able operation.
> Any reason not to? I mean "stdin
> That is the other question: stdint.h is a C99 header, yes? It might be
> better to unconditionally included it, defining our short types from it.
> What do you think?
We already do, it is included by 'types.h'.
I am saying that *IF* for some bizzaro reason, some platform does not
have it we
On Sun, May 24, 2009 at 5:32 PM, Xiaofan Chen wrote:
> The script from Michael seems to be better and I can halt the target.
> But the flashing problem is still there. Michael is helping me on this.
> He is thinking that the hex file is without a checksum and there are
> some problems with the sta
On Sun, May 24, 2009 at 7:03 PM, Michael Fischer wrote:
> Now I take a look in the openocd manual and found the following
> information:
>
> 13.2.2.1 lpc2000 options
> flash bank lpc2000 0 0[calc
> checksum]
>
> ...and the optional keyword calc checksum, telling the
> driver to calculate a v
On Sun, 2009-05-24 at 21:40 -0400, Duane Ellis wrote:
> > That is the other question: stdint.h is a C99 header, yes? It might be
> > better to unconditionally included it, defining our short types from it.
> > What do you think?
>
> We already do, it is included by 'types.h'.
Conditionally. Th
I have a observation/question
When "run algorithm" occurs - what/where - etc are interrupts disabled?
For instance:
Looking at for instance the armv7 code to "blank check" a flash.
No where does that code *disable* interrupts
(grep for "erase_check_code")
Does something do that? I do
On May 24, 2009, at 6:40 PM, Duane Ellis wrote:
That is the other question: stdint.h is a C99 header, yes? It might
be
better to unconditionally included it, defining our short types
from it.
What do you think?
We already do, it is included by 'types.h'.
I am saying that *IF* for some bi
David Brownell a écrit :
> On Wednesday 20 May 2009, Tiago Maluta wrote:
>
>> I'd like to know if OpenOCD support AVR32 (AP7000) processors?
>>
>
> Not yet. I'd partition that work in two parts:
>
> - "Nexus" [3] framework, which could support more than
>just the AVR32 chips.
>
> - A
A MIPS question for those who know. Is there a usefull debug module in
the NEC V850? I would think that it would have at least the standard
MIPS module.
Am I wrong to think that? According to NEC and IAR the only way to debug
is to use the minicube.
Michel
--
Tired of Microsoft's rebootive mult
Duane Ellis wrote:
> I have a observation/question
>
> When "run algorithm" occurs - what/where - etc are interrupts disabled?
>
> For instance:
>
> Looking at for instance the armv7 code to "blank check" a flash.
>No where does that code *disable* interrupts
>
> (grep for "erase_check_co
On Mon, May 25, 2009 at 9:06 AM, David Brownell wrote:
> The simplest way to update the flash on that board would
> be to use the U-Boot that's already installed there. If
> you brick the board, the next simplest solution is to use
> one of Atmel's JTAG adapters with their tools. I don't
> know
2009/5/25 Michel Catudal :
> David Brownell a écrit :
>> - AVR32-specific support. Probably not just the AP7 devices,
>> but also the UC3 flavors (since those seem to be getting
>> the engineering work nowadays).
>>
> I would agree with that. From what I have read the AVR32 is likely to
> c
On Sun, 2009-05-24 at 21:12 -0400, Duane Ellis wrote:
> Why not deprecate/change, all "u32" to "uint32_t" - wholesale?
In looking into this deeper, I just found that we lack i32 (or similar),
which would be required for a case in replacements.h. That said, the
attached patch replaces my earlier o
I can test for AVR32 support.
My company is handling with some projects on AVR32.
My versaloon can also support AVR32 debug and program
under IAR EWAVR32 or AVR32Studio according to the open
protocol from atmel.
The open source version and product version of versaloon
doesn't support AVR32, bec
2009/5/25 SimonQian :
> I can test for AVR32 support.
> My company is handling with some projects on AVR32.
>
> My versaloon can also support AVR32 debug and program
> under IAR EWAVR32 or AVR32Studio according to the open
> protocol from atmel.
By emulating JTAGICE mkII ?
> The open source versi
> There are many 16/32bit MCUs which will benefit from OpenOCD if
> they are supported. Most popular non-ARM ones I can think of are Renesas
> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
I have developped JTAG support for MSP430 in versaloon, as I know, JTAG
chain of MSP430 isn't stand
On Sunday 24 May 2009, Zach Welch wrote:
> - add iN equivalents to intN_t types; i32 is used by replacements.h
The traditional sibling of a "u32" (unsigned) is an "s32" (signed).
I don't know where "i32" came from, it's an interloper.
___
Openocd-devel
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
> On Sunday 24 May 2009, Zach Welch wrote:
> > - add iN equivalents to intN_t types; i32 is used by replacements.h
>
> The traditional sibling of a "u32" (unsigned) is an "s32" (signed).
>
> I don't know where "i32" came from, it's an inter
For supporting AVR32 debugging under IAR EWAVR32 and
AVR32Studio, you MUST emulate JTAGICE mkII.
Does USBprog support AVR32 debugging?
2009-05-25
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
发件人： Xiaofan Chen
发送时间： 2009-05-25 11:36:35
收件人： SimonQi
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to intN_t types; i32 is used by replacements.h
The traditional sibling of a "u32" (unsigned) is an "s32" (signed).
I don't k
On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
> =On May 24, 2009, at 9:04 PM, Zach Welch wrote:
>
> > On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
> >> On Sunday 24 May 2009, Zach Welch wrote:
> >>> - add iN equivalents to intN_t types; i32 is used by replacements.h
> >>
> >>
2009/5/25 SimonQian :
> For supporting AVR32 debugging under IAR EWAVR32 and
> AVR32Studio, you MUST emulate JTAGICE mkII.
I see. Thanks.
> Does USBprog support AVR32 debugging?
>
I do not think so. From the website, it does not
even program AVR32 properly as of now.
--
Xiaofan http://mcuee.bl
On Sunday 24 May 2009, SimonQian wrote:
> I have developped JTAG support for MSP430 in versaloon, as I know, JTAG
> chain of MSP430 isn't standard JTAG. So I don't think it possible to support
> MSP430 in OpenOCD.
Could you summarize how msp430 is non-standard?
I know that msp430 -- as well as
On Sun, 2009-05-24 at 21:37 -0700, Zach Welch wrote:
> On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
> > =On May 24, 2009, at 9:04 PM, Zach Welch wrote:
> >
> > > On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
> > >> On Sunday 24 May 2009, Zach Welch wrote:
> > >>> - add iN equi
On Sunday 24 May 2009, Zach Welch wrote:
> 1) It's shorter/faster to type.
Which is why I like u32/s32 (and friends) mysself.
The {u,}int{8,16,32,64}_t names are committee design.
They look and smell long, like an elephant. ;)
___
Openocd-developmen
On Mon, May 25, 2009 at 12:46 PM, David Brownell wrote:
> On Sunday 24 May 2009, SimonQian wrote:
>> I have developped JTAG support for MSP430 in versaloon, as I know, JTAG
>> chain of MSP430 isn't standard JTAG. So I don't think it possible to support
>> MSP430 in OpenOCD.
>
> Could you summarize
2009/5/25 Michel Catudal :
>
> A MIPS question for those who know. Is there a usefull debug module in
> the NEC V850? I would think that it would have at least the standard
> MIPS module.
> Am I wrong to think that? According to NEC and IAR the only way to debug
> is to use the minicube.
>
I do no
On May 24, 2009, at 9:37 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to intN_t types; i32 i
Duane Ellis wrote:
> I have a observation/question
>
> When "run algorithm" occurs - what/where - etc are interrupts disabled?
>
>
int arm7_9_debug_entry(target_t *target)
Look for buf_set_u32(dbg_ctrl->value, EICE_DBG_CONTROL_INTDIS, ...
and the debug_execution flag.
> For instance:
>
> Lo
77 matches
Mail list logo
