Re: [Openocd-development] Programming external flash with OpenOCD fails
On Wed, Dec 1, 2010 at 8:58 AM, Star Keeper starkee...@gmx.at wrote: The image I want to flash is not my program code. It is a resource file with image data. As i understand, the load command normally loads a program into RAM and does not program a flash. Is that right, or should the load command notice that the target address is in Flash and start the flash programming? That's right. load will look at the configuration and if the memory range is flash, then the flash is erased and programmed. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Aborted; stm32 with too high clock
On Wed, Dec 1, 2010 at 08:41, Øyvind Harboe oyvind.har...@zylin.com wrote: Can you try with a 32 bit OpenOCD executable? I don't have a 32-bit linux box around. Can someone share a binary? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] git submodule failure behind HTTP-only proxy
Hi, I have a problem updating the git submodules when doing this from behind a HTTP-only proxy. Cloning (git clone http://repo.or.cz/r/openocd.git) works fine. Next step (./bootstrap) is also ok. However, the following step shows that a mixture of http and git protocol is used: git submodule init Submodule 'jimtcl' (http://repo.or.cz/r/jimtcl.git) registered for path jimtcl' Submodule 'tools/git2cl' (git://repo.or.cz/git2cl.git) registered for path 'tools/git2cl' The next step (git submodule update) fails on the git2cl submodule. Cloning into tools/git2cl... fatal: Unable to look up repo.or.cz (port 9418) (Name or service not known) Clone of 'git://repo.or.cz/git2cl.git' into submodule path 'tools/git2cl' failed My workaround is to manually edit .git/config before the update. I replaced this section [submodule tools/git2cl] url = git://repo.or.cz/git2cl.git by [submodule tools/git2cl] url = http://repo.or.cz/r/git2cl.git Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git submodule failure behind HTTP-only proxy
My workaround is to manually edit .git/config before the update. I replaced this section [submodule tools/git2cl] url = git://repo.or.cz/git2cl.git by [submodule tools/git2cl] url = http://repo.or.cz/r/git2cl.git This is not a workaround, it's a solution! :-) The only question is whether we should commit the change. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git submodule failure behind HTTP-only proxy
Personally, I prefer the git protocol if possible. It's much faster and has lower overhead. I think the best idea would be to add .gitmodules to .gitignore and have the bootstrap script modify .gitmodules to point to either git: or http: depending on some user preference. Øyvind Harboe oyvind.har...@zylin.com wrote: My workaround is to manually edit .git/config before the update. I replaced this section [submodule tools/git2cl] url = git://repo.or.cz/git2cl.git by [submodule tools/git2cl] url = http://repo.or.cz/r/git2cl.git This is not a workaround, it's a solution! :-) The only question is whether we should commit the change. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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] git submodule failure behind HTTP-only proxy
Øyvind Harboe wrote: My workaround is to manually edit .git/config before the update. I replaced this section [submodule tools/git2cl] url = git://repo.or.cz/git2cl.git by [submodule tools/git2cl] url = http://repo.or.cz/r/git2cl.git This is not a workaround, it's a solution! :-) The only question is whether we should commit the change. If repo.or.cz is running a recent git then http:// is not much more inefficient than git:// but on the other hand works through proxies, so while the submodules are still there I think it makes sense to commit. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git submodule failure behind HTTP-only proxy
Austin, Alex wrote: Personally, I prefer the git protocol if possible. It's much faster and has lower overhead. This used to be very true. Please see http://progit.org/2010/03/04/smart-http.html //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] iMX51 workaround
On Tue, Nov 30, 2010 at 12:18 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: If iMX51 is broken and the current CortexA8 workaround code for it breaks other CPUs, then I think that the automatic workaround code for iMX51 has to be either fixed or removed. Thoughts? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I agree that if a clean fix cannot be implemented and tested then it should be removed. One option might be to pull out the JTAG ID code along with the rest of the identifying factors to try and make the scenario even more unique, but I do not have a way to verify that it will work on the IMX51. The only thought I have from what I have seen of the code is to call dap_queue_idcode_read and include that value in the table of identifying factors, but I am not sure if that will work on the problem target or if it is alright to do in this section of the code. -Karl ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] iMX51 workaround
Øyvind Harboe wrote: If iMX51 is broken and the current CortexA8 workaround code for it breaks other CPUs, then I think that the automatic workaround code for iMX51 has to be either fixed or removed. Do you know which commit it was added in? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Programming external flash with OpenOCD fails
The load command produces the same error for the external flash region.. I see no difference in the flash commands and the load command. -Ursprüngliche Nachricht- Von: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Gesendet: Mittwoch, 1. Dezember 2010 09:02 An: Star Keeper Cc: openocd-development@lists.berlios.de Betreff: Re: [Openocd-development] Programming external flash with OpenOCD fails On Wed, Dec 1, 2010 at 8:58 AM, Star Keeper starkee...@gmx.at wrote: The image I want to flash is not my program code. It is a resource file with image data. As i understand, the load command normally loads a program into RAM and does not program a flash. Is that right, or should the load command notice that the target address is in Flash and start the flash programming? That's right. load will look at the configuration and if the memory range is flash, then the flash is erased and programmed. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] iMX51 workaround
On Wed, Dec 1, 2010 at 6:04 PM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: If iMX51 is broken and the current CortexA8 workaround code for it breaks other CPUs, then I think that the automatic workaround code for iMX51 has to be either fixed or removed. Do you know which commit it was added in? v0.4.0-570-g0649fb2 Marek did a whole bunch of great work solving other long standing problems. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Lost patches
On 2010-11-30 08:20, Øyvind Harboe wrote: Are there any patches out there that should have been applied but haven't? Are you planning a release? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
On 2010-11-30 06:38, Tomek CEDRO wrote: The SWJ cable that I have use tdi and tdo pins anyway but the buffers are more complex, maybe there is a simple way to make jtag only cable swd aware, i have some other cables so after the base is working we can give a try on that :-) This is also an important issue (; Rowley has done a converter for Amontec JTAGkey, but so far I haven't found much detail about it. It would be very very cool to be able to use old JTAGs with OpenOCD and SWD - with some kind of detachable simple converter. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
On 2010-11-30 17:46, Tomek CEDRO wrote: Freddie, this is free and open source project, so no way to enforce rush from anyone on anyone, the work is in progress. I have managed to include this project somehow with my current tasks so I can put some more time into it, but I had to reschedule it from march too and it collides with some others tasks as well... The delays are unavoidable in a real world, and each second costs money - this is why I try to document it as well I can to spare this time for further implementation in openocd, so you wont have to reseach again :-) Nobody's forcing anything on anyone - I'm merely stating facts. OpenOCD is not normal open-source project, as most users have small knowledge about PC programming (e.g. me), that's why most of us OpenOCD-users can do nothing more than simple requests and bug reports... The fact that I can build OpenOCD myself is a huge success for me ; I'd really like to help with OpenOCD, but someone would need to tell me what to do (; In details like where, what mechanism / algorithm, what it should do. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Lost patches
On Wed, Dec 1, 2010 at 10:25 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-11-30 08:20, Øyvind Harboe wrote: Are there any patches out there that should have been applied but haven't? Are you planning a release? I'm hopeful that we can get the swd stuff from David merged and then we should be able to start the release process. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] add cortex_m3 reset_config ... to stm32.cfg
From 852e118ef27fd3fb0b7d32f9524c89f58d171152 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 1 Dec 2010 22:49:48 +0100
Subject: [PATCH 1/2] add cortex_m3 reset_config ... to stm32.cfg
STM32 fully support NVIC's sysresetreq (which also resets peripherals and
generates SRST pulse), so use it in place of default vectreset (which does
not reset peripherals and does not generate SRST pulse).
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/stm32.cfg |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tcl/target/stm32.cfg b/tcl/target/stm32.cfg
index fa59e35..ad5b50c 100644
--- a/tcl/target/stm32.cfg
+++ b/tcl/target/stm32.cfg
@@ -26,6 +26,9 @@ adapter_khz 1000
adapter_nsrst_delay 100
jtag_ntrst_delay 100
+# STM32 fully support NVIC's sysresetreq (which also resets peripherals and
generates SRST pulse)
+cortex_m3 reset_config sysresetreq
+
#jtag scan chain
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] rename some target scripts to be consistent with the rest
___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] rename some target scripts to be consistent with the rest
From 995335b80223931c2c4b3686c4db563b9119cce1 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 1 Dec 2010 22:55:56 +0100
Subject: [PATCH 2/2] rename some target scripts to be consistent with the rest
Rename Atmel target scripts which had wrong name (at91 missing for ARM7
AT91SAM7..., at missing for AVR ATmega...)
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/at91sam7se512.cfg | 40 +
tcl/target/at91sam7x256.cfg | 50 ++
tcl/target/atmega128.cfg | 40 +
tcl/target/mega128.cfg | 40 -
tcl/target/sam7se512.cfg | 40 -
tcl/target/sam7x256.cfg | 50 --
6 files changed, 130 insertions(+), 130 deletions(-)
create mode 100644 tcl/target/at91sam7se512.cfg
create mode 100644 tcl/target/at91sam7x256.cfg
create mode 100644 tcl/target/atmega128.cfg
delete mode 100644 tcl/target/mega128.cfg
delete mode 100644 tcl/target/sam7se512.cfg
delete mode 100644 tcl/target/sam7x256.cfg
diff --git a/tcl/target/at91sam7se512.cfg b/tcl/target/at91sam7se512.cfg
new file mode 100644
index 000..c48afef
--- /dev/null
+++ b/tcl/target/at91sam7se512.cfg
@@ -0,0 +1,40 @@
+
+# ATMEL sam7se512
+# Example: the Elektor Internet Radio - EIR
+# http://www.ethernut.de/en/hardware/eir/index.html
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME sam7se512
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ # force an error till we get a good number
+ set _CPUTAPID 0x
+}
+
+#use combined on interfaces or targets that can't set TRST/SRST separately
+reset_config srst_only srst_pulls_trst
+
+#jtag scan chain
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+# The target
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
+
+$_TARGETNAME configure -work-area-phys 0x0020 -work-area-size 0x4000
-work-area-backup 0
+
+#flash bank driver base_addr size chip_width bus_width
target_number [target_name banks sectors_per_bank pages_per_sector
page_size num_nvmbits ext_freq_khz]
+set _FLASHNAME $_CHIPNAME.flash
+flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432
+
diff --git a/tcl/target/at91sam7x256.cfg b/tcl/target/at91sam7x256.cfg
new file mode 100644
index 000..dd36458
--- /dev/null
+++ b/tcl/target/at91sam7x256.cfg
@@ -0,0 +1,50 @@
+#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 sam7x256
+}
+
+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 $_CHIPNAME.cpu
+target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
+
+$_TARGETNAME configure -event reset-init {
+ # 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 100
+}
+
+$_TARGETNAME configure -work-area-phys 0x0020 -work-area-size 0x4000
-work-area-backup 0
+
+#flash bank driver base_addr size chip_width bus_width
target_number [target_name banks sectors_per_bank pages_per_sector
page_size num_nvmbits ext_freq_khz]
+set _FLASHNAME $_CHIPNAME.flash
+flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432
diff --git a/tcl/target/atmega128.cfg b/tcl/target/atmega128.cfg
new file mode 100644
index 000..212a267
--- /dev/null
+++ b/tcl/target/atmega128.cfg
@@ -0,0 +1,40 @@
+# for avr
+
+ set _CHIPNAME avr
+ set _ENDIAN little
+
+# jtag speed
+adapter_khz 4500
+
+reset_config srst_only
+adapter_nsrst_delay 100
+
+#jtag scan chain
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x8970203F
+}
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME avr -endian $_ENDIAN -chain-position $_TARGETNAME
+
+#$_TARGETNAME configure
Re: [Openocd-development] Lost patches
On Wed, Dec 1, 2010 at 11:00 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-12-01 22:41, Øyvind Harboe wrote: On Wed, Dec 1, 2010 at 10:25 PM, Freddie Chopinfreddie_cho...@op.pl wrote: On 2010-11-30 08:20, Øyvind Harboe wrote: Are there any patches out there that should have been applied but haven't? Are you planning a release? I'm hopeful that we can get the swd stuff from David merged and then we should be able to start the release process. I'll send 2 simple patches in a moment, and I'd like to bring to threads to your attention: https://lists.berlios.de/pipermail/openocd-development/2010-November/016872.html https://lists.berlios.de/pipermail/openocd-development/2010-November/017068.html You'll have to try to work with the list to come up with a consensus on those patches. One was a tough nut to make it do everything everybody wanted, but the other was on my radar as possible to push over the finish line. I was specifically looking for patches that were ready to go in, but were just lost in the noise somewhere. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] add cortex_m3 reset_config ... to stm32.cfg
Any objections to this one? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] rename some target scripts to be consistent with the rest
Any objections to this patch? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 2:42 PM, Piotr Esden-Tempski wrote: Hi ho, On Nov 30, 2010, at 2:31 PM, Steve Bennett wrote: On 01/12/2010, at 7:44 AM, Piotr Esden-Tempski wrote: On Nov 30, 2010, at 1:04 PM, Piotr Esden-Tempski wrote: On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: 32 vs. 64 bit problem? Wouldn't that be interesting? :) Are there Linux 64 users out there that can try it out? I note that Domen Puncer is having a similar problem. Also looks like 64 bit from the stack trace. Piotr, can you try building 32 bit? Something like: ./configure ... CFLAGS=-arch i386 -O0 -g Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem here. Thanks for pointing that out! I will try to find a 64bit linux machine and see if I get the same error there. (maybe also someone else can take a stab at it?) Ok I just tested on 64bit ubuntu linux machine. And sadly it works there. :( So the only way to trigger the segfault currently is running 64 bit openocd binary on Snow Leopard. :( Are you able to run under valgrind on 64bit linux and mac? Could be the problem is still there but doesn't show up. Also, on mac, do you have an installed version of Jim (e.g. /usr/local/include/jim-config.h)? I wonder if it could be conflicting... Excellent debugging! Here we go. :) I cleaned up truthfully after every build. (stow helps :) ) So dangling jim-config.h was not present. Good. I generated two valgrind outputs, one for the failing Mac OS 64 bit version and the working Linux 64bit version. I was unable to run valgrind on the Mac OS 32bit binary though because valgrind refuses doing that being 64bit itself and me being too lazy to fight with it too much. (I may try to fight with it at a later time but... well) :) So attached you find the two valgrind outputs. So beside the fact that on Mac OS libusb seems to behave bit erratically and on linux Yes. This is a known problem. Jim seems to be having fun leaking memory (but maybe that is just the charm of every interpreter in general :) ) No, that is a real memory leak in Jim. Thanks for finding that one. Will be fixed shortly. what is drawing my attention is buf_set_buf. This function seems to be copying bit by bit data from the jtag buffer to the output as far as I understand. I don't know the implications of it but it is copying data into the buffer created by jtag_build_buffer that is assuming some alignment of memory things and the bit by bit copy code is probably also assuming things. I did not have much time to look into that code but what I found so far is that linux malloc does not assure memory alignment. The Mac OS API assures double word 16byte memory alignment in the darwin malloc returns. I am again not sure what that means to the openocd code but maybe there is something wrong with these assumptions? ... Definitely that needs more investigation. I'm not sure. Could be just that ft2232_read_scan() isn't filling the whole buffer. Although the buffer was allocated with calloc() so it should be initialised to 0. Perhaps someone more knowledgeable could look at that. Possibly defining _DEBUG_JTAG_IO_ would help. Maybe you guys have some new ideas where to poke next. I will continue poking as time permits. But as I can compile using -m32 my efforts may slow down a little. :) If the above isn't the problem, there could be problems around command_unknown() interp-cmdPrivData = c-jim_handler_data; return (*c-jim_handler)(interp, count, start); Setting cmdPrivData explicitly is probably not a good idea. I'm concerned that there is some 32/64 bit alignment issue or truncation happening somewhere in there. Not sure yet. The way openocd interfaces with jim is a bit convoluted. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
On 12/01/2010 10:32 PM, Freddie Chopin wrote: This is also an important issue (; Rowley has done a converter for Amontec JTAGkey, but so far I haven't found much detail about it. It would be very very cool to be able to use old JTAGs with OpenOCD and SWD - with some kind of detachable simple converter. If we can use one output pin that is not used in SWD mode as a direction signal, a simple 74LVC125 or similar should do the job. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Programming external flash with OpenOCD fails
On 11/30/2010 08:36 PM, Starkeeper wrote: Indeed it works without the wokring area! OK. That means at least the flash is working, and the bus setup is probably also OK. OpenOCD tried to download code + data to RAM on the target, and something in that process goes wrong. I don't know the LPC internals, so I can't check if the memory setup really enables working RAM at 0x4000. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
--- On Wed, 12/1/10, Freddie Chopin freddie_cho...@op.pl wrote: This is also an important issue (; Rowley has done a converter for Amontec JTAGkey, THe converter is rather generic, and some OpenOCD folk have its schematic. Rowley's driver might not work except with JTAGkey ... but I'd see no reason a shim driver couldn't eventually get written to work with e.g. Olimex adapters. Sorry I dont have that schematic's URL any more; maybe someone else saved it. I don't think it was intended to be secret. So: before long, a driver for that might make a good project for a brave experimenter. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
