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 of the queue) via the
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
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-P2148
On Sun, May 24, 2009 at 4:08 PM, Michael Fischer fische...@t-online.de 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
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 of the
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 xiaof...@gmail.com wrote:
On Sun, May 24, 2009 at 4:42 PM, Xiaofan Chen xiaof...@gmail.com 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.
On Sun, May 24, 2009 at 4:42 PM, Xiaofan Chen xiaof...@gmail.com 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.
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.
First,
On Sun, May 24, 2009 at 5:04 PM, Magnus Lundin lun...@mlu.mine.nu 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
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.
In
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
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
On Sun, May 24, 2009 at 7:03 PM, Michael Fischer fische...@t-online.de 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
On Sun, May 24, 2009 at 8:55 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sun, May 24, 2009 at 7:03 PM, Michael Fischer fische...@t-online.de
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
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
Hello Xiaofan,
Saturday, May 23, 2009, 2:17:33 PM, you wrote:
XC On Tue, May 19, 2009 at 8:26 AM, Igor Skochinsky skochin...@mail.ru 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
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 z...@superlucidity.net wrote:
On Sat, 2009-05-23 at 21:06
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
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
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
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 insertion(+), 1
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 usage.
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. openocd/jtag/jlink.h
b) do not rename src, e.g. #include jtag/jlink.h
- something needs to be done; the library work is only
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:
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
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 to
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
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
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 for the
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 what you mean.
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 using
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 would clarify.
On Sun, May 24, 2009 at 11:10 PM, Michael Fischer fische...@t-online.de 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
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
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
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
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. The
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 don't
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
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.
- AVR32-specific
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_code)
Does
On Mon, May 25, 2009 at 9:06 AM, David Brownell davi...@pacbell.net 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.
2009/5/25 Michel Catudal michelcatu...@gmail.com:
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
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,
2009/5/25 SimonQian simonq...@simonqian.com:
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
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
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 interloper.
That
=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 know
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
The traditional
2009/5/25 SimonQian simonq...@simonqian.com:
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.
--
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 equivalents to
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. ;)
___
On Mon, May 25, 2009 at 12:46 PM, David Brownell davi...@pacbell.net 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
2009/5/25 Michel Catudal michelcatu...@gmail.com:
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
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
61 matches
Mail list logo
