Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
Merged. I would still like to see a more robust general solution to this problem, but identifying it is a very good start... -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.html Øyvind Harboe 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] stm32x: allow flash probe on a running target
I've updated the documentation on the gdb-attach event to provide an alternate way to solve this issue. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.html Øyvind Harboe 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] Getting OpenOCD working on DM355 without SRST
Hi, Could you please let us know if you have selected ICE Pick or ARM debug mode from the EMU0 and EMU1 ? note: ICE Pick Mode may have an issue booting from Reset ! For ARM Mode please configure your jumper for EMU0 = '0' and EMU1 = '0' (pulldown 2.2k or smaller). note : you could still route the SRST (ARM RESET signal) from the Amontec JTAGkey-Tiny to the ARM_RSTn signal on your DM355 board. (eg. on pin 15 of the TI SAMTEC 20-pin header). If you want to use the RTCK (adaptive return clock ) signal, you could update your ICE to an Amontec JTAGkey-2 dongle. This will help accelerate your debug and help to have a stable debug. That's just some comments. Maybe they could help, maybe not. Regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Hi folks, I am trying to get OpenOCD 0.4.0 (built from git) working with an Amontek JTAGKey-Tiny. I am using a home-made adapter to TI 14-pin JTAG header which has TRST but no SRST, on our board which features Texas DM355 and one other chip in the scan chain (which I don't care much about). For info we have been using the Ronetix PEEDI JTAG programmer through the same connector successfully on this board and other copies, so the design and connector are known to work. I used OpenOCD a little a couple of years ago and it's clearly come on a long way - I'm keen to play with the NAND flash support. I have copied dm355evm.cfg and customised with a couple of lines like: jtag newtap penta tap -irlen 5 -expected-id 0x04040009 # paranoia / trying to make stuff work: jtag_rclk 100 reset_config trst_only separate I can talk to the board a little, but I think I need to configure OpenOCD with a software reset or something to replace the missing SRST? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
On Tue, Apr 20, 2010 at 2:22 AM, JY Koh wrote: > Hi All, > > > > I have a STM32F103ZE custom board. > > I have been using OpenOCD with Amontec JTAGkey2 for debugging. > > It works fine when I use internal SRAM (64K) as workspace. > > In order to run a little big program I add external SRAM (1M bytes) on FSMC > (CS1) > > So I’d like to use this external SRAM as workspace. > > What should I change in target configuration ? > > I change workspace from 0x200 to 0x600. It doesn’t work. > > Please let me know if there are something to change. > > > > Regards, > > JY Koh > OpenOCD won't set up the FSMC for you so you have to do that somewhere, preferrably in the reset init handler. But I'm not convinced that there are any benefits over having it in internal SRAM. What is the problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
On Tue, Apr 20, 2010 at 9:08 AM, Øyvind Harboe wrote: > I've updated the documentation on the gdb-attach event to > provide an alternate way to solve this issue. > Great! And there's the target event list that I was briefly searching for. Good to know there is one. Freddie, have you checked if the patch resolves your problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting OpenOCD working on DM355 without SRST
Hi Laurent, thanks for the reply. Laurent Gauch wrote: > Could you please let us know if you have selected ICE Pick or ARM > debug mode from the EMU0 and EMU1 ? > note: ICE Pick Mode may have an issue booting from Reset ! > > For ARM Mode please configure your jumper for EMU0 = '0' and EMU1 = > '0' (pulldown 2.2k or smaller). EMU0 and EMU1 are routed to the JTAG header but no other pulls or jumpers on this board, so just the internal DM355 pullup - they will both be "1". The OpenOCD script seems to be enabling the other TAPs via the ICE though.. Not sure what you mean by ICE Pick Mode having issues booting from reset? > note : you could still route the SRST (ARM RESET signal) from the > Amontec JTAGkey-Tiny to the ARM_RSTn signal on your DM355 board. (eg. > on pin 15 of the TI SAMTEC 20-pin header). I might have to try that later. This is a custom board without the 20-pin header, I can get at RESET on a test point or something if I have to. At the moment I am looking into triggering a watchdog reset with a reset-assert handler.. Be good if I can avoid soldering. > If you want to use the RTCK (adaptive return clock ) signal, you could > update your ICE to an Amontec JTAGkey-2 dongle. This will help > accelerate your debug and help to have a stable debug. If I can get this stuff working we may order a few :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 请不要再给我发这些邮件了
___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 不要再发这些邮件了
___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 不要再发这些邮件了
2010/4/20 lg w Go here and then unsubscribe. https://lists.berlios.de/mailman/listinfo/openocd-development (In Chinese) 如果你要退订电子邮件列表，请到以上网站。 -- 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] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
Hi Andreas Thanks a lot. My board has Ethernet and LCD interface so that my program is too big to be accommodated into internal SRAM. For this reason, I added external SRAM (1M Bytes) and I'd like to run my program here. JY Koh -Original Message- From: andr...@fritiofson.net [mailto:andr...@fritiofson.net] On Behalf Of Andreas Fritiofson Sent: Tuesday, April 20, 2010 4:28 PM To: ko...@uni-inc.co.kr Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] I'd like to change the workspace from 0x200 to 0x600 of stm32.cfg On Tue, Apr 20, 2010 at 2:22 AM, JY Koh wrote: > Hi All, > > > > I have a STM32F103ZE custom board. > > I have been using OpenOCD with Amontec JTAGkey2 for debugging. > > It works fine when I use internal SRAM (64K) as workspace. > > In order to run a little big program I add external SRAM (1M bytes) on FSMC > (CS1) > > So I'd like to use this external SRAM as workspace. > > What should I change in target configuration ? > > I change workspace from 0x200 to 0x600. It doesn't work. > > Please let me know if there are something to change. > > > > Regards, > > JY Koh > OpenOCD won't set up the FSMC for you so you have to do that somewhere, preferrably in the reset init handler. But I'm not convinced that there are any benefits over having it in internal SRAM. What is the problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question regarding watchpoints with address mask
>> (xscale debug hardware only supports hardware breakpoints on a single >> address). > >That's not what the XScale Core Developer's Manual says: I was referring to instruction breakpoints, not data breakpoints (aka watchpoints). Indeed, my patch for watchpoint / data breakpoint masks (aka watchpoint length) uses the feature you cite. Sorry, I should have been more explicit in my remark. Too many overloaded terms. Thanks, Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
On Tue, Apr 20, 2010 at 1:10 PM, JY Koh wrote: > Hi Andreas > > Thanks a lot. > > My board has Ethernet and LCD interface so that my program is too big to be > accommodated into internal SRAM. > For this reason, I added external SRAM (1M Bytes) and I'd like to run my > program here. > The working area (which I suspect you are talking about when you say workspace) has nothing to do with where your program runs from. It is an area for OpenOCD's internal use, for example for downloading flash algorithms for execution on the target and as buffer space for data during flashing. Best leave it at its default location. If you want to load and debug your program running from external SRAM, simply tell the linker to place your code there. You still have to set up the FSMC in the reset init handler for GDB to be able to load the executable into external memory. Another solution is to run (and debug) your program from internal flash. The hardware breakpoints are often sufficient, and the STM32 is notoriously slow at executing code from external memory. Besides, you still have to make the code fit in flash if you want it to run without the debugger. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] load_image
Here is updated patch.
Michal
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 5273d5d..cfba79f 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5671,10 +5671,20 @@ separately.
@end deffn
@anchor{load_image}
-...@deffn Command {load_image} filename address [...@option{bin}|@option{ihex}|@option{elf}]
-Load image from file @var{filename} to target memory at @var{address}.
+...@deffn Command {load_image} filename address [...@option{bin}|@option{ihex}|@option{elf}] @option{min_addr} @option{max_length}]
+Load image from file @var{filename} to target memory offset by @var{address} from its load address.
The file format may optionally be specified
-(@option{bin}, @option{ihex}, or @option{elf})
+(@option{bin}, @option{ihex}, or @option{elf}).
+In addition the following arguments may be specifed:
+...@var{min_addr} - ignore data below @var{min_addr} (this is w.r.t. to the target's load address + @var{address})
+...@var{max_length} - maximum number of bytes to load.
+...@example
+proc load_image_bin @{fname foffset address length @} @{
+# Load data from fname filename at foffset offset to
+# target at address. Load at most length bytes.
+load_image $fname [expr $address - $foffset] bin $address $length
+...@}
+...@end example
@end deffn
@deffn Command {test_image} filename [address [...@option{bin}|@option{ihex}|@option{elf}]]
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] load_image
On Tue, Apr 20, 2010 at 8:46 PM, michal smulski wrote: > Here is updated patch. Merged. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.html Øyvind Harboe 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] I'd like to change the workspace from 0x2000000 to 0x6000000 of stm32.cfg
Hi Andreas, I got what you mean. I'll try and update you. Thanks. -Original Message- From: andr...@fritiofson.net [mailto:andr...@fritiofson.net] On Behalf Of Andreas Fritiofson Sent: Wednesday, April 21, 2010 3:43 AM To: ko...@uni-inc.co.kr Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] I'd like to change the workspace from 0x200 to 0x600 of stm32.cfg On Tue, Apr 20, 2010 at 1:10 PM, JY Koh wrote: > Hi Andreas > > Thanks a lot. > > My board has Ethernet and LCD interface so that my program is too big to be > accommodated into internal SRAM. > For this reason, I added external SRAM (1M Bytes) and I'd like to run my > program here. > The working area (which I suspect you are talking about when you say workspace) has nothing to do with where your program runs from. It is an area for OpenOCD's internal use, for example for downloading flash algorithms for execution on the target and as buffer space for data during flashing. Best leave it at its default location. If you want to load and debug your program running from external SRAM, simply tell the linker to place your code there. You still have to set up the FSMC in the reset init handler for GDB to be able to load the executable into external memory. Another solution is to run (and debug) your program from internal flash. The hardware breakpoints are often sufficient, and the STM32 is notoriously slow at executing code from external memory. Besides, you still have to make the code fit in flash if you want it to run without the debugger. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting OpenOCD working on DM355 without SRST
Jon Povey wrote:
> At the moment I am looking into triggering a watchdog reset with a
> reset-assert handler.. Be good if I can avoid soldering.
I am not having too much joy with this approach so far, maybe I don't know
enough about ARM processor states. I had this trigger a reset once, but not
reproduced since. My routine is below if anyone is interested.
The DM355 datasheet suggests there is an IcePick command to do the same reset
as the watchdog; from sprufb3 10.3.3:
"To initiate max reset, the WDT expires (indicating a runaway condition) or the
ARM emulator initiates a max reset command via the IcePick emulation module."
This suggests that I might be able to give the IcePick a command to reset the
SoC?
Googling around I don't find too much information about the IcePick; there is
this page on TI's wiki: http://processors.wiki.ti.com/index.php/ICEPICK
I noted the interesting comment by a "db" - David Brownell?
If anyone has information about using the IcePick to reset the DM355 I'd be
very interested.
My work-in-progress watchdog reset:
$_TARGETNAME configure -event reset-assert { vidbox_reset }
proc vidbox_reset {} {
puts "vidbox_reset called"
halt
wait_halt
# disable mmu?
# reset via watchdog timer
set wdt_base 0x01C21C00
set tgcr [expr $wdt_base + 0x24]
set wdtcr [expr $wdt_base + 0x28]
#TGCR.TIMMODE = 2h, TIM12RS = 1, TIM34RS = 1
mww $tgcr 0xB
#WDTCR.WDEN = 1
#WDKEY = A5C6, DA7E, (trigger watchdog reset)
mww $wdtcr 0xA5C64000
mww $wdtcr 0xDA7E4000
mww $wdtcr 0x4000
}
--
Jon Povey
jon.po...@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719
.
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged. If you
have received this electronic mail transmission in error, please delete it from
your system without copying or forwarding it, and notify the sender of the
error by reply email so that the sender's address records can be corrected. The
views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Libftdi or JTAGKey-Tiny hang?
In the course of my fooling around lately it seems I am able to wedge something, libftdi or the JTAGKey-Tiny, I got it into a state where OpenOCD would only produce this on startup, even after power cycling the target: Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. Leaving the target powered I replugged the JTAGKey-Tiny and on next start of OpenOCD it found things: Info : RCLK (adaptive clock speed) not supported - fallback to 100 kHz Info : JTAG tap: penta.tap tap/device found: 0x04040009 (mfg: 0x004, part: 0x4040, ver: 0x0) Info : JTAG tap: dm355.jrc tap/device found: 0x0b73b02f (mfg: 0x017, part: 0xb73b, ver: 0x0) Info : JTAG tap: dm355.etb enabled Info : JTAG tap: dm355.arm enabled Info : Embedded ICE version 6 Info : dm355.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.3 Note: I am running OpenOCD on Linux inside VirtualBox hosted on Windows, using VirtualBox's USB capture features. If this is of interest to anyone please let me know if there is something you'd like me to try / information to capture next time. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting OpenOCD working on DM355 without SRST
Jon Povey wrote: > If anyone has information about using the IcePick to reset the DM355 > I'd be very interested. Oh, I just found this: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg12916.html Which suggests that TI won't give out the information needed to use the IcePick, and I am maybe on the best possible track with my WDT based reset attempt. Will keep struggling and post back here and on the TI Davinci wiki if I get something usable. Will also ask our TI FAE for the IcePick info.. But not hold my breath. Thanks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Libftdi or JTAGKey-Tiny hang?
On Wed, Apr 21, 2010 at 11:28 AM, Jon Povey wrote: > Note: I am running OpenOCD on Linux inside VirtualBox hosted on Windows, > using VirtualBox's USB capture features. > > If this is of interest to anyone please let me know if there is something > you'd like me to try / information to capture next time. > Too many unknowns. OpenOCD can work under Windows. And I am sure VirtualBox's USB implementation is not the best (the same for VMware, all of the USB implementation seems to be problematic by nature of emulation). So just try out OpenOCD under Windows with libftdi and see if that helps. If yes, you can blame the VM. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
