Re: [Openocd-development] STM32-COMSTICK JTAG port?
Hello, 2009/7/23 Michel Catudal michelcatu...@gmail.com: Hitex may very well have several versions for their USB debugging. There is an interest in getting something faster than the ftdi device. From what Leon posted, his device may not be an ftdi but some microprocessor. In fact, yes there is an STM32F103 in front of the STM32F107, close to the USB A connector. I assume the STM32F103 is the Debug Interface to the STM32F107. The on-CD schematics are not complete. This might not be easy to get going in open-source fashion... Regards, -- Leon ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Benchmark data for various JTAG debuggers
On Thu, Jul 23, 2009 at 7:28 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Thu, Jul 23, 2009 at 6:21 PM, Spencer Olivers...@spen-soft.co.uk wrote: Yesterday I tried flashing the STM3210E-Eval using OpenOCD 0.2.0 under Windows and it seems the V3 J-Link works well and the speed is not bad (similar to What Freddie got for the FTD2xx version). I probably have not learned all the tricks to speed up the download. I will try more tests later. This is what I get (flash download) with either v3 or v7 J-Link under Windows with OpenOCD 0.2.0. (For V7 J-Link: jtag_khz=1200) wrote 524288 byte from file demo.hex in 36.143002s (14.165952 kb/s) (For V7 J-Link: jtag_khz=1000) wrote 524288 byte from file demo.hex in 37.673000s (13.590635 kb/s) (For V3 J-Link, jtag_khz=1000) wrote 524288 byte from file demo.hex in 33.115002s (15.461271 kb/s) It is strange that V7 (ADI mIDAS-Link) is slower than V3 (IAR). Are there any tricks to speed up this? It seems that ARM7/9 has options like fast_memory_access. - Hide quoted text - -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Bug: segfault when gdb-end and gdb-detach are defined and gdb killed
Hi developers,
I've found a bug in src/server/gdb_server.c:2005, function
gdb_log_callback(). A pointer is used without checking if it's still valid.
This is 100% when using GDB to debug a remote target:
1. start openocd to listen for incoming gdb connection
2. setup gdb so that it connects to openocd and let it continue its
execution if the target is halted;
3. from another console kill the GDB process.
4. openocd will segfault in the line above.
Tested with version 0.2 but I verified that no commit touched that part
after the official release.
Attaching configuration file. Note that I've added both gdb-end and
gdb-detach events; if I remove gdb-end (which in my case it's not what
I'm looking for, btw :) Openocd shuts down cleanly.
Feel free to contact me if you need further information.
Best regards.
--
Ing. Luca Ottaviano - lottavi...@develer.com
Develer S.r.l. - http://www.develer.com/
.hardware . software .innovation
Tel.: +39 055 3986627 - ext.: 218
# Change the default telnet port...
telnet_port
# Port for TCL connection.
tcl_port
# GDB connects here
gdb_port
gdb_memory_map enable
interface ft2232
ft2232_device_desc Amontec JTAGkey
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only srst_pulls_trst
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME sam7
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x3f0f0f0f
}
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
$_TARGETNAME configure -event reset-start {
# disable watchdog
mww 0xfd44 0x8000
# enable user reset
mww 0xfd08 0xa501
# CKGR_MOR : enable the main oscillator
mww 0xfc20 0x0601
sleep 10
# CKGR_PLLR: 96.1097 MHz
mww 0xfc2c 0x00481c0e
sleep 10
# PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
mww 0xfc30 0x0007
sleep 10
# MC_FMR: flash mode (FWS=1,FMCN=60)
mww 0xff60 0x003c0100
sleep 10
# reset PC
reg pc
}
$_TARGETNAME configure -event gdb-end { echo **EVENT: gdb-end }
$_TARGETNAME configure -event gdb-detach { echo **EVENT: gdb-detach }
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x0020
-work-area-size 0x4000 -work-area-backup 0
#flash bank driver base size chip_width bus_width
flash bank at91sam7 0 0 0 0 0
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/2] thumb2 disassembly for Load halfword
Both committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/2] thumb2 disassembly for Load halfword
I noticed there are a few checks for (rt == 0xf) even though that case
is handled with an early return at the top of the function.
Maybe those checks should just go?
/Andreas
Index: src/target/arm_disassembler.c
===
--- src/target/arm_disassembler.c (revision 2561)
+++ src/target/arm_disassembler.c (working copy)
@@ -3523,8 +3523,6 @@
if ((opcode (1 23)) == 0) {
if (rn == 0xf) {
ldrh_literal:
- if (rt == 0xf)
- return ERROR_INVALID_ARGUMENTS;
immed = opcode 0xfff;
address = thumb_alignpc4(address);
if (opcode (1 23))
@@ -3535,8 +3533,6 @@
sign, rt, address);
return ERROR_OK;
}
- if (rt == 0xf)
- return ERROR_INVALID_ARGUMENTS;
if (op2 == 0) {
int rm = opcode 0xf;
@@ -3574,12 +3570,11 @@
} else {
if (rn == 0xf)
goto ldrh_literal;
- if (rt != 0x0f) {
- immed = opcode 0xfff;
- sprintf(cp, LDR%sH.W\tr%d, [r%d, #%d]\t; %#6.6x,
- sign, rt, rn, immed, immed);
- return ERROR_OK;
- }
+
+ immed = opcode 0xfff;
+ sprintf(cp, LDR%sH.W\tr%d, [r%d, #%d]\t; %#6.6x,
+ sign, rt, rn, immed, immed);
+ return ERROR_OK;
}
return ERROR_INVALID_ARGUMENTS;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Benchmark data for various JTAG debuggers
On Thu, Jul 23, 2009 at 8:22 PM, Xiaofan Chenxiaof...@gmail.com wrote: This is what I get (flash download) with either v3 or v7 J-Link under Windows with OpenOCD 0.2.0. (For V7 J-Link: jtag_khz=1200) wrote 524288 byte from file demo.hex in 36.143002s (14.165952 kb/s) (For V7 J-Link: jtag_khz=1000) wrote 524288 byte from file demo.hex in 37.673000s (13.590635 kb/s) (For V3 J-Link, jtag_khz=1000) wrote 524288 byte from file demo.hex in 33.115002s (15.461271 kb/s) It is strange that V7 (ADI mIDAS-Link) is slower than V3 (IAR). Are there any tricks to speed up this? It seems that ARM7/9 has options like fast_memory_access. Under Linux, the speed is even lower, this is especially true for the V7. (For V7 J-Link: jtag_khz=1200) wrote 524288 byte from file demo.hex in 58.072418s (8.816578 kb/s) (For V3 J-Link, jtag_khz=1200) wrote 524288 byte from file demo.hex in 39.224007s (13.053231 kb/s) (For V3 J-Link, jtag_khz=1000) wrote 524288 byte from file demo.hex in 39.188969s (13.064902 kb/s) -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/2] thumb2 disassembly for Load halfword
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
