Re: [Openocd-development] jlink issues
> svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and > stm32 target. > Connecting using r1192 is ok, just a little slow. > > The strange thing is if i then connect using r1943 it will work !! > Replug the jlink and it will fail with r1943, run r1192 then all is ok > again. > > I have attached logs to see if it inspires anyone, other than i am trying to > delve into the issue. > > Cheers > Spen > > I have seen the same behavior. 1938 works fine with older j-link hardware (v3/v4). 1188 works with newer but is more than a little slow. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TMS470 Scripts
I updated to 1933 today and gave my j-links another try loading code to a STM32. I tried a v3 v4 and v6 jlink. The v4 jlink worked reliably, v3 worked after trying a few times and power cycling everything. v6 won't work at all. I attached the console output of all three jlink sessions. On Wed, May 27, 2009 at 6:06 PM, Peter Denison wrote: > On Wed, 27 May 2009, Xiaofan Chen wrote: > >> Thanks a lot for the help. I could not connect the TMS470R1A256 IAR >> Starter Kit properly to J-Link with the script. I have not used your patch >> yet as it seems more for the debugging part. I want to connect and then >> reset/halt first. >> >> >> mc...@ubuntu904:~/Desktop/build/openocd/tms470$ openocd -f tms470r1a256.cfg >> Open On-Chip Debugger 0.2.0-in-development (2009-05-25-21:15) svn:1910 >> >> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS >> >> $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ >> Error: J-Link command EMU_CMD_VERSION failed (-110) >> >> Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a >> Error: J-Link command EMU_CMD_VERSION failed (-110) >> >> Info : J-Link ARM V6 compiled Apr 1 2009 11:56:10 >> Info : JLink caps 0x19ff7bbf >> Info : JLink hw version 6 >> Info : JLink max mem block 8376 >> Info : Vref = 3.132 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 >> >> Info : J-Link JTAG Interface ready >> Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive >> packet not sent! (6118). Workaround: increase "set remotetimeout" in >> GDB >> Error: jlink_usb_message failed with result=1) >> Error: jlink_tap_execute, wrong result -107 (expected 1) > > I get this repeated result as well, with a Yellow V6 J-Link, and a > USR8200 (IXP422) target board: > > --8< > Open On-Chip Debugger 0.2.0-in-development (2009-05-27-19:22) svn:1932M > > BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ > RCLK - adaptive > Error: J-Link command EMU_CMD_VERSION failed (-110) > > Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a > Error: J-Link command EMU_CMD_VERSION failed (-110) > > Info : J-Link ARM V6 compiled Mar 3 2008 18:04:42 > Info : JLink caps 0x1f7fbf > Info : JLink hw version 6 > Info : JLink max mem block 9992 > Info : Vref = 3.313 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1 > > Info : J-Link JTAG Interface ready > Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet > not sent! (6211). Workaround: increase "set remotetimeout" in GDB > Error: jlink_usb_message failed with result=1) > Error: jlink_tap_execute, wrong result -107 (expected 1) > 8<-- > > The offending lines that cause it to break were added in jlink.c by Oyvind > in r1498. However, according to the docs (RM08001-02, dated June 30, > 2008 at www.segger.com), they should be correct. Once you've read the TDO > lines out, read the next byte out, and if it's 0, it's OK, if not, it's an > error. Sadly, the docs don't go on to explain what an error code of 1 > means. > > Mine is consistently reading out a 1 instead of a 0. > > As an aside, the new 'jlink hw jtag' command is a good idea, but the > hardware version read from the adapter always overrides any command line > value you've put in. > > I'm seriously considering ditching the J-Link, and going back to trying to > get the USBprog to be a fully featured JTAG adapter. It's more work, but > at least both ends are open source. (Twice as many communities to interact > with - yay ;) > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > (54)$ sudo /usr/local/gnu-arm/bin/openocd -f ../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f flashAll.script -c "reset run" -c "shutdown" Open On-Chip Debugger 0.2.0-in-development (2009-05-27-16:57) svn:1933 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ 500 kHz Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Info : JLink hw version 3 Info : Vref = 3.279 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 255 Info : J-Link JTAG Interface ready Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3) Info : JTAG Tap/device matched Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (Manufacturer: 0x020, Part: 0x6414, Version: 0x0) Info : JTAG Tap/device matched Info : device id = 0x10016414 Info : flash size = 256kbytes stm32x mass erase complete Info : Padding image section 0 with 0 bytes Error: timed out while waiting for target halted Error: error executing stm32x flash write algorithm Error: flash writing failed with e
Re: [Openocd-development] svn 1881 with jlink and STM32
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 wrote:
>> On Saturday 23 May 2009, Zach Welch wrote:
>> >
>> > > Considering that USB bulk transfers are "best effort" and might easily
>> > > be delayed by concurrent activity to a USB disk or webcam ... a single
>> > > second seems absurdly short. Even if the device were guaranteed to be
>> > > able to respond that quickly.
>> >
>> > Right, but that does not mean we should simply throw the program into a
>> > blocking call with a longer timeout. I would rather see the device make
>> > a try using a _shorter_ timeout and allow for other processing to occur
>> > in between retries.
>>
>> "Retry"?
>
> Well, I am thinking of the J-Link code in particular, which I suppose is
> more of a "continuation" condition.
>
>> I'd rather see the event loops structured better, so that each activity
>> gets its own thread. That would move from those error-prone presumptions
>> that manually timesliced event loops can scale.
>
> I like the idea of threads, but that opens a new dimension of problems
> for embedded systems (though none supported... today). It would be nice
> to be able to run OpenOCD in a single thread.
>
>> I see messages about needing to increase some GDB timeout/interval. But
>> that's foolishness, since I'm not even working with GDB when they start
>> spamming me. The core problem has nothing to do with GDB, and everything
>> to do with a weak concurrency model.
>
> I agree. This is what I meant by retries. If we're working on the
> single thread model, no event/action can be allowed to take more than
> MAX_TIME_SLICE, or you see those sorts of problems. I thought that
> libusb worked in non-blocking mode, but perhaps I was wrong
>
>> Too bad that can't be fixed before the next release. ;)
>
> Yeah. These are Big Changes.
>
> Cheers,
>
> Zach
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1881)
+++ src/jtag/jlink.c (working copy)
@@ -951,9 +951,18 @@
/* Read data from USB into in_buffer. */
static int jlink_usb_read(jlink_jtag_t *jlink_jtag, int expected_size)
{
- int result = usb_bulk_read_ex(jlink_jtag->usb_handle, JLINK_READ_ENDPOINT,
- (char *)usb_in_buffer, expected_size, JLINK_USB_TIMEOUT);
+ int result;
+ if(expected_size > JLINK_IN_BUFFER_SIZE)
+ {
+ LOG_ERROR("jlink_jtag_read illegal length=%d (max=%d)",
+ expected_size, JLINK_IN_BUFFER_SIZE);
+ return -1;
+ }
+
+ result = usb_bulk_read_ex(jlink_jtag->usb_handle, JLINK_READ_ENDPOINT,
+ (char *)usb_in_buffer, expected_size, JLINK_USB_TIMEOUT);
+
DEBUG_JTAG_IO("jlink_usb_read, result = %d", result);
#ifdef _DEBUG_USB_COMMS_
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
Something strikes me as pretty broken here. Maybe I am seeing ghosts.
I put in a few prints to see what was going on, then got confused and
ran from the debugger. This is what I found:
static int jlink_get_version_info(void)
{
int result;
int len;
u32 jlink_caps, jlink_max_size;
/* query hardware version */
jlink_simple_command(EMU_CMD_VERSION);
result = jlink_usb_read(jlink_jtag_handle, 2);
if (2 != result)
{
///* Sometimes this fails, that doesn't seem to matter
LOG_ERROR("J-Link command EMU_CMD_VERSION failed
(%d)\n", result);
return ERROR_JTAG_DEVICE_ERROR;
}
///* most of the time it works and we get to here
///* Problem is that what is read is "J-" the first two bytes of
the jlink identifier string
len = buf_get_u32(usb_in_buffer, 0, 16);
///* len now holds 11594, which is what buf_get_u32 returns when
it is fed "J-"
result = jlink_usb_read(jlink_jtag_handle, len);
///* jlink_usb_read doesn't check the length of the buffer before reading
///* so it wipes out a bunch of variables including jlink_jtag_handle
if (result != len)
{
LOG_ERROR("J-Link command EMU_CMD_VERSION read failed
(%d)\n", result);
return ERROR_JTAG_DEVICE_ERROR;
}
The crazy thing is that sometimes this works. Often enough to be
usable actually. I added a check to jlink_usb_read and it makes it
fail every time. I attached the patch as I think it is the right
thing to do anyways. If you increase JLINK_IN_BUFFER_SIZE to
something big enough, it will keep it functional.
I don't have any experience with low level jtag interfacing, what is
this code trying to do? Should something other than "J-" be returned
after EMU_CMD_VERSION?
Wish I had more time to debug this tonight, but if I don't get home
for memorial day weekend the GF is not going to be too happy :-)
Dylan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
Try this again to the whole list.
Here is the trace. I'm taking a quick look at it right now. I am
guessing that having jlink_jtag_handle = 0 is the problem, just trying
to figure out how that happened.
Dylan
(gdb) run -f ../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f
flashAll.script -c "reset run" -c "shutdown"
Starting program: /scratch/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f
flashAll.script -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (-110)
Program received signal SIGSEGV, Segmentation fault.
0x00a84e85 in jlink_usb_write (jlink_jtag=0x0, out_length=1) at jlink.c:918
/scratch/openocd/src/jtag/jlink.c:918:23443:beg:0xa84e85
(gdb) bt
#0 0x00a84e85 in jlink_usb_write (jlink_jtag=0x0, out_length=1) at jlink.c:918
#1 0x00a84f2f in jlink_simple_command (command=1 '\001') at jlink.c:509
#2 0x00a85dbe in jlink_get_version_info () at jlink.c:549
#3 0x00a860f5 in jlink_init () at jlink.c:324
#4 0x00a7f188 in jtag_interface_init (cmd_ctx=0x8830008) at jtag.c:2370
#5 0x00a78cb3 in handle_init_command (cmd_ctx=0x8830008,
cmd=0x883e228 "init", args=0x8843344, argc=0) at openocd.c:133
#6 0x00b1e89a in run_command (context=0x8830008, c=0x883e548,
words=0x8843340, num_words=1) at command.c:399
#7 0x00b1ebe2 in script_command (interp=0x8830020, argc=1, argv=0xbfc3f8e0)
at command.c:126
#8 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x88430a0)
at jim.c:8708
#9 0x00b13d51 in Jim_EvalCoreCommand (interp=0x8830020, argc=3,
argv=0xbfc3f9a0) at jim.c:10846
#10 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x8843268)
at jim.c:8708
#11 0x00b13962 in Jim_CatchCoreCommand (interp=0x8830020, argc=2,
argv=0xbfc3fa60) at jim.c:11413
#12 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x883fc68)
at jim.c:8708
#13 0x00b17e9f in Jim_EvalExpression (interp=0x8830020, exprObjPtr=0x8844298,
exprResultPtrPtr=0xbfc3fbc4) at jim.c:6927
---Type to continue, or q to quit---
#14 0x00b18c13 in Jim_GetBoolFromExpr (interp=0x8830020, exprObjPtr=0x8844298,
boolPtr=0xbfc3fc08) at jim.c:7210
#15 0x00b18d4b in Jim_IfCoreCommand (interp=0x8830020, argc=5, argv=0xbfc3fc70)
at jim.c:10297
#16 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x883e9f0)
at jim.c:8708
#17 0x00b15294 in JimCallProcedure (interp=0x8830020, cmd=0x883eb98, argc=0,
argv=0xbfc3fd70) at jim.c:8857
#18 0x00b134a7 in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x883e970)
at jim.c:8714
#19 0x00b14f0f in Jim_Eval_Named (interp=0x8830020, script=0x883e5b0 "init",
filename=0xb41eeb "command.c", lineno=453) at jim.c:8901
#20 0x00b1e7c6 in command_run_line (context=0x8830008, line=0x883e5b0 "init")
at command.c:453
#21 0x00b1d029 in parse_config_file (cmd_ctx=0x8830008) at configuration.c:118
#22 0x00a78bc8 in openocd_main (argc=13, argv=0xbfc40034) at openocd.c:268
#23 0x080484b2 in main (argc=Cannot access memory at address 0x1
) at main.c:39
(gdb) list
913 }
914
915 static inline int usb_bulk_write_ex(usb_dev_handle *dev, int ep,
916 char *bytes, int size, int timeout)
917 {
918 return usb_bulk_with_retries(&wrap_usb_bulk_write,
919 dev, ep, bytes, size, timeout);
920 }
921
922 static inline int usb_bulk_read_ex(usb_dev_handle *dev, int ep,
(gdb) p wrap_usb_bulk_write
$1 = {int (usb_dev_handle *, int, char *, int,
int)} 0xa851f0
(gdb) p dev
No symbol "dev" in current context.
(gdb) p &wrap_usb_bulk_write
$2 = (int (*)(usb_dev_handle *, int, char *, int,
int)) 0xa851f0
(gdb) up
#1 0x00a84f2f in jlink_simple_command (command=1 '\001') at jlink.c:509
/scratch/openocd/src/jtag/jlink.c:509:13195:beg:0xa84f2f
(gdb) list
504 int result;
505
506 DEBUG_JTAG_IO("0x%02x", command);
507
508 usb_out_buffer[0] = command;
509 result = jlink_usb_write(jlink_jtag_handle, 1);
510
511 if (result != 1)
512 {
513 LOG_ERROR("J-Link command 0x%02x failed (%d)",
command, result);
(gdb) p jlink_jtag_handle
$3 = (jlink_jtag_t *) 0x0
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn 1881 with jlink and STM32
I am just updated to svn 1881 to use with my STM32 and jlink(yellow
v6.0). I had been using 1183, which worked every time, but was
unbearably slow. Revision 1881 is lightning fast compared with the
old revision. I am however seeing a few issues.
It takes 5 or six tries to get my program to download into flash. I
either get a segmentation fault at startup or an error while writing
the code to flash. I have attached examples of both problems below
along with my configuration file. I am away this weekend but would be
able to get a debug build running to try some things out next week.
Great work on the speed up!
$ sudo /usr/local/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f
flashAll.script -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Error: J-Link command EMU_CMD_VERSION failed (-110)
Info : J-Link ARM V6 compiled Aug 28 2007 19:22:02
Info : JLink caps 0x77fbf
Info : JLink max mem block 9992
Info : Vref = 3.306 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3041). Workaround: increase "set remotetimeout" in
GDB
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer:
0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (Manufacturer:
0x020, Part: 0x6414, Version: 0x0)
Info : JTAG Tap/device matched
Warn : no telnet port specified, using default port
Warn : no gdb port specified, using default port
Warn : no tcl port specified, using default port
Info : device id = 0x10016414
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
wrote 6844 byte from file ../BootLoader/source/bl.elf in 0.670785s
(9.963839 kb/s)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (1025). Workaround: increase "set remotetimeout" in
GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (9037). Workaround: increase "set remotetimeout" in
GDB
Error: timed out while waiting for target halted
Error: error executing stm32x flash write algorithm
Error: flash writing failed with error code: 0xfc7a
Error: error writing to flash at address 0x0800 at offset 0x2000 (-902)
$ sudo /usr/local/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f
flashAll.script -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (-110)
Segmentation fault
$ cat ../GNUTools/openOCD/newLPM.cfg
# script for stm32
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME stm32
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
interface jlink
# jtag speed
jtag_khz 500
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst
#jtag scan chain
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# See STM Document RM0008
# Section 26.6.3
set _CPUTAPID 0x3ba00477
}
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID
if { [info exists BSTAPID ] } {
set _BSTAPID $BSTAPID
} else {
# See STM Document RM0008
# Section 26.6.2
# Low density devices, Rev A
set _BSTAPID1 0x06412041
# Medium density devices, Rev A
set _BSTAPID2 0x06410041
# Medium density devices, Rev B and Rev Z
set _BSTAPID3 0x16410041
# High density devices, Rev A
set _BSTAPID4 0x06414041
}
jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1
-expected-id $_BSTAPID1 -expected-id $_BSTAPID2 -expected-id
$_BSTAPID3 -expected-id $_BSTAPID4
set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000
-work-area-size 49152 -work-area-backup 0
flash bank stm32x 0 0 0 0 0
gdb_memory_map enable
gdb_flash_program enable
# For more information about the configuration files, take a look at:
# openocd.texi
$
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex target_write_memory() performance/STM32 flash programming
I am pretty sure that there is a problem with the Jlink driver here as well. This is my config: # script for stm32 # use jlink interface jlink # jtag speed jtag_khz 500 jtag_nsrst_delay 100 jtag_ntrst_delay 100 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag_device 4 0x1 0xf 0xe jtag_device 5 0x1 0x1 0x1e #target #target arm7tdmi target cortex_m3 little 0 0 working_area 0 0x2000 49152 nobackup #flash bank str7x 0 0 flash bank stm32x 0 0 0 0 0 gdb_memory_map enable gdb_flash_program enable # For more information about the configuration files, take a look at: # openocd.texi 2009/2/24 SimonQian : > Hi, >> I use a JLink to flash my STM32 and I would love to be able to program >> at the speeds you are seeing! I have been meaning to look at why this >> is so slow for a while but haven't been able to find any time. I hope >> to be able to get some of the new instrumentation changes in a give it >> a try this week. >> wrote 232380 byte from file lpm.bin in 262.544495s (0.864362 kb/s) > > It's abnormal for JLink to run at this speed. > Is JLink configured OK? Does it run at 500kHz speed? > > And I make Versaloon to process raw JTAG data(tdi, tms) using DMA, but it's > NOT that slow. > For STM32, at about 8kB/s for flash programming. > But my driver is based on Versaloon driver. > Is it possible that there is problem with JLink driver? > > 2009-02-25 > > Best Regards, Simon Qian > > SimonQian(simonq...@simonqian.com) www.SimonQian.com > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex target_write_memory() performance /STM32 flash programming
I use a JLink to flash my STM32 and I would love to be able to program at the speeds you are seeing! I have been meaning to look at why this is so slow for a while but haven't been able to find any time. I hope to be able to get some of the new instrumentation changes in a give it a try this week. wrote 232380 byte from file lpm.bin in 262.544495s (0.864362 kb/s) Dylan On Tue, Feb 24, 2009 at 5:04 AM, Rob Brown wrote: > Øyvind Harboe wrote: >> On Tue, Feb 24, 2009 at 9:30 AM, SimonQian wrote: >>> My adaptor is Versaloon(USB2.0 FullSpeed), it's more slower. >>> jtag_khz 565 >>> flash write_image >>> C:/Projects/FreeRTOS/Demo/CORTEX_STM32Fxxx_Eclipse/RTOSDemo/RTOSDemo.bin >>> 0x0800 bin >>> wrote 27464 byte from file >>> C:/Projects/FreeRTOS/Demo/CORTEX_STM32Fxxx_Eclipse/RTOSDemo/RTOSDemo.bin in >>> 3.375000s (7.946759 kb/s) >>> >>> Does it because that CM3 can only support a slow JTAG frequency? >> >> It would be helpful to get some performances numbers for non-STM32 >> Cortex part... >> >> I haven't dived into the details, but I'll be really surprised if >> performance can't be >> improved significantly by ironing out a few bumps in OpenOCD. >> > > I've got a Luminary LM3S811 eval board, with a CPU and FT2232. > Haven't run it up in a while, and can't remember the first thing > about it, but I'll send something to it in the morning > (just downloading the driver CD again, to get some demo code...) > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A few issues with STM32
are you running from RAM or FLASH? On Mon, Dec 29, 2008 at 3:05 PM, Michel Catudal wrote: > I have a few issues with debugging a STM32-SK board (using eclipse with > the latest Zylin plugin) > > I have modified the IAR application so it would work with my arm-elf-gcc > compiler. I use the latest SVN code and have no issue yet with > it. My gcc is version 4.4.0 and gdb 6.8. Eclipse is the latest (3.4.1) > installed as a user. The one that comes with Fedora 9 is too buggy. > I have my own eclipse plugin for C projects derived from the gnuarm plugin. > > Everything seems to work fine except that I don't see my LCD display. If > I power down and back up it works fine. > The tracing appears to show that the code is doing exactly what it is > supposed to do. It reads an ADC port and displayed the data on the LCD. > If I halt and resume from within a telnet session everything is cool. > The same sequence doesn't bring my LCD if I have gdb running in > the background. Even when gdb is out of the picture (session terminated) > I cannot get the LCD back on. I can trace without a problem and > there doesn't appear to have any issue. I can press on the reset button > all I want with no change whatsoever. > > I would disconnect the jtag connector, press on reset and the LCD still > won't come on. Cycling the power will fix it. > > > > Also I get this most of the time when debugging but not always > > SWJ-DP STICKY ERROR > dcb_dhcsr 0x30003, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0xe000edf8 > SWJ-DP STICKY ERROR > dcb_dhcsr 0x30003, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0xe000edf8 > Block read error address 0xfff8, count 0x1 > SWJ-DP STICKY ERROR > dcb_dhcsr 0x30003, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0xe000edf8 > SWJ-DP STICKY ERROR > dcb_dhcsr 0x30003, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0xe000edf8 > SWJ-DP STICKY ERROR > dcb_dhcsr 0x30003, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0xe000edf8 > > > > Michel > > -- > Tired of Microsoft's rebootive multitasking? > then it's time to upgrade to Linux. > http://home.comcast.net/~mcatudal > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
