Re: [Openocd-development] [patch/rfc 2/3] update ICEpick support on DaVinci
David Brownell wrote:
> Update the DaVinci target configs so they have JTAG post-reset
> event handlers which:
>
> - run the 100 JTAG clocks ICEpick wants
> - ensure the ARM (and ETB) taps are enabled
> ---
> The OMAP3 post-reset handlers should probably do something
> similar, doing the (updated) omap3_dbginit stuff so that it
> no longer needs to be done by hand.
Most probably, I miss the obvious ;)
But in omap3530.cfg doing something like
jtag configure $_CHIPNAME.jrc -event post-reset \
"runtest 100; omap3_dbginit"
obviously fails due to 'reset' command in omap3_dbginit with
Runtime error, file "lib/openocd//target/omap3530.cfg", line 0:
'reset' can not be invoked recursively
with omap3_dbginit being:
proc omap3_dbginit { } {
poll off
reset
sleep 100
jtag tapenable omap3530.dap
targets
# General Cortex A8 debug initialisation
cortex_a8 dbginit
# Enable DBGU singal for OMAP353x
omap3.cpu mww 0x5401d030 0x2000
poll on
}
Seems that we need some clever order of reset/omap3_dbginit/-event
post-reset I don't see at the moment :(
Best regards
Dirk
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc 1/3] reset cleanup, and reorder JTAG event reports
David Brownell wrote: > Reorder the two JTAG reset events (C/internal, Tcl/external) so > they can be used properly to enable TAPs with ICEpick. Make them > kick in the same way on *both* paths (TCK/TMS or TRST). > > Tweak TCL reset script ... mostly improving comments about what > the steps do, but also call [target names] only once. > > Plus some minor cleanups (whitespace, strings, better messaging > during debug) to reset-related code. > --- > I think only that first change could be controversial; if nobody > comes up with a reason it could cause trouble, I'll commit this > later today. Looking at r2754, this patch (1/3) is applied, while 2/3 and 3/3 are still pending? Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
This patch (it includes Øyvind's previous patch) fixes my problems with
reset. By default it will do nothing so it should not affect anybody.
I added [optional] reset before running jtag_init_inner().
Is there a chance to commit this to svn tree?
--Michal
On Thu, 2009-09-24 at 00:28 +0200, Michael Schwingen wrote:
> David Brownell wrote:
> >> A board may stretch SRST, so you *have* to be able to wait a
> >> (user-defined) amount of time after SRESET assertion/deassertion before
> >> talking to anything in the chain. This is also true if the SRESET
> >> assertion is not caused by OpenOCD directly.
> >>
> >
> > Understood. This is part of why some JTAG adapters provide
> > inputs for SRST, not just outputs. It'd be nice if the
> > FT2232 ones provided a "USB interrupt" to give hosts an
> > asynch (more or less) notification that it was asserted.
> >
> This won't help if the FTDI library asserts SRST when calling the init
> function. At that point, the interrupts are probably not yet set up
> correctly.
>
> If the library does assert SRST during init without being told to do
> that, then OpenOCD needs to know about that and at least apply the
> configured delays so that the chain is in working order.
>
> cu
> Michael
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
Index: src/jtag/zy1000/zy1000.c
===
--- src/jtag/zy1000/zy1000.c(revision 2726)
+++ src/jtag/zy1000/zy1000.c(working copy)
@@ -657,9 +657,6 @@
-extern int jtag_nsrst_delay;
-extern int jtag_ntrst_delay;
-
int interface_jtag_add_reset(int req_trst, int req_srst)
{
zy1000_reset(req_trst, req_srst);
Index: src/jtag/core.c
===
--- src/jtag/core.c (revision 2726)
+++ src/jtag/core.c (working copy)
@@ -93,6 +93,9 @@
/* how long the OpenOCD should wait before attempting JTAG communication after
reset lines deasserted (in ms) */
static int jtag_nsrst_delay = 0; /* default to no nSRST delay */
static int jtag_ntrst_delay = 0; /* default to no nTRST delay */
+static int jtag_nsrst_assert_width = 0; /* width of assertion */
+static int jtag_ntrst_assert_width = 0; /* width of assertion */
+static bool jtag_reset_on_init = false; /* reset JTAG on init */
typedef struct jtag_event_callback_s
{
@@ -662,7 +665,11 @@
if (jtag_srst != new_srst) {
jtag_srst = new_srst;
if (jtag_srst)
+ {
LOG_DEBUG("SRST line asserted");
+ if (jtag_nsrst_assert_width)
+ jtag_add_sleep(jtag_nsrst_assert_width * 1000);
+ }
else {
LOG_DEBUG("SRST line released");
if (jtag_nsrst_delay)
@@ -694,6 +701,8 @@
LOG_DEBUG("TRST line asserted");
tap_set_state(TAP_RESET);
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
+ if (jtag_ntrst_assert_width)
+ jtag_add_sleep(jtag_ntrst_assert_width * 1000);
} else {
LOG_DEBUG("TRST line released");
if (jtag_ntrst_delay)
@@ -1296,6 +1305,10 @@
int retval;
if ((retval = jtag_interface_init(cmd_ctx)) != ERROR_OK)
return retval;
+
+ if (jtag_reset_on_init)
+ return jtag_init_reset(cmd_ctx);
+
if (jtag_init_inner(cmd_ctx) == ERROR_OK)
{
return ERROR_OK;
@@ -1462,3 +1475,30 @@
{
return jtag_ntrst_delay;
}
+
+
+void jtag_set_nsrst_assert_width(unsigned delay)
+{
+ jtag_nsrst_assert_width = delay;
+}
+unsigned jtag_get_nsrst_assert_width(void)
+{
+ return jtag_nsrst_assert_width;
+}
+void jtag_set_ntrst_assert_width(unsigned delay)
+{
+ jtag_ntrst_assert_width = delay;
+}
+unsigned jtag_get_ntrst_assert_width(void)
+{
+ return jtag_ntrst_assert_width;
+}
+
+void jtag_set_reset_on_init(bool state)
+{
+ jtag_reset_on_init = state;
+}
+bool jtag_get_reset_on_init(void)
+{
+ return jtag_reset_on_init;
+}
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 2726)
+++ src/jtag/jtag.h (working copy)
@@ -289,6 +289,15 @@
void jtag_set_ntrst_delay(unsigned delay);
unsigned jtag_get_ntrst_delay(void);
+void jtag_set_nsrst_assert_width(unsigned delay);
+unsigned jtag_get_nsrst_assert_width(void);
+
+void jtag_set_ntrst_assert_width(unsigned delay);
+unsigned jtag_get_ntrst_assert_width(void);
+
+void jtag_set_reset_on_init(bool state);
+bool jtag_get_reset_on_init(void);
+
/// @returns The current state of TRST.
int jtag_get_trst(void);
/// @returns The current
[Openocd-development] works on amd64 but not i386
I have been having fun with various combinations of openocd, amontec jtagkey and olimex usb-tiny and pxa270 and chianed and unchained JTAG interfaces. We have one JTAG port to xilinx xcr3256 (coolrunner II CPLD) and one to pxa270. I have a large table of what does and doesn't work which is all very nice, but I suspect won't generally be of much interest here because it all related to r1613 because that was the last version on which xsvf or svf playing into CPLDs worked. I intend to work through svn revisions, keeping the 1613-vontage xsvf code to see how far forward one can go until that dies due to changes elsewhere. David Bisset is also working with latest code to see if he can get it going again on xscale - it seems that nor programing only works in simple-minded mode - as soon as you try to use the debug-handler code in the xscale to program NOR at a useful speed it fails. Anyway. The issue we have is that we are stuck with r1613 for the time being and we can make that work with an amontec jtagkey in chained-JTAG setup quite well (it segfaults every odd run and works just fine every even run - which is about as good as it gets IME :-) However this turned out (when we tried to deploy it to production) to only be true on amd64 machines. On i386 machines boundary scan always fails. This is a bit of a pain (we've gone to buy another amd64 box for now as openocd-fixing time has run out). It works the same (every other time) on amd64 debian testing and stable boxes, with both libftdi 0.13 and 0.16. It doesn't work just the same with libftdi 0.13 and 0.16 on debian stable i386 machines. So, if anyone has any bright ideas for fixing the underlying xsvf problem so we can move to newer code or why it should be different on i386. Is anyone else using OpenOCD to program coolrunner CPLDs? I suspect not otherwise there should be more grumbling that it's been broken for quite some time. all our config files are available at http://balloonboard.org/cgi-bin/viewcvs.cgi/balloon/trunk/utils/openocd/ The case I am talking about above is: openocd -s utils/openocd -f balloon3-amontec.cfg -f loadloon.cfg -f shutdown.cfg Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] target configuration files for Toshiba TX09 familiy
Hi,
here are the configurations files for Toshiba TX09 familiy of MCUs
TMPA910 and TMPA900 and their Starter Kits TOPAS910 and TOPASA900
Best regards
Michael
diff -urN openocd-0.2.0_ORIG/tcl/board/topas910.cfg
openocd-0.2.0/tcl/board/topas910.cfg
--- openocd-0.2.0_ORIG/tcl/board/topas910.cfg1970-01-01
01:00:00.0
+0100
+++ openocd-0.2.0/tcl/board/topas910.cfg2009-09-23 14:41:20.0
+0200
@@ -0,0 +1,118 @@
+##
+# Target:Toshiba TOPAS910 -- TMPA910 Starterkit
+#
+##
+
+# We add to the minimal configuration.
+source [find target/tmpa910.cfg]
+
+##
+# Target configuration
+##
+
+#$_TARGETNAME configure -event gdb-attach { reset init }
+$_TARGETNAME configure -event reset-init { topas910_init }
+
+proc topas910_init { } {
+# Init PLL
+# my settings
+mww 0xf005000c 0x0007
+mww 0xf0050010 0x0065
+mww 0xf005000c 0x00a7
+sleep 10
+mdw 0xf0050008
+mww 0xf0050008 0x0002
+mww 0xf0050004 0x
+# NEW: set CLKCR5
+mww 0xf0050054 0x0040
+#
+sleep 10
+# Init SDRAM
+# _PMCDRV = 0x0071;
+# //
+# // Initialize SDRAM timing paramater
+# //
+# _DMC_CAS_LATENCY = 0x0006;
+# _DMC_T_DQSS = 0x;
+# _DMC_T_MRD = 0x0002;
+# _DMC_T_RAS = 0x0007;
+#
+# _DMC_T_RC= 0x000A;
+# _DMC_T_RCD = 0x0013;
+#
+# _DMC_T_RFC = 0x010A;
+#
+# _DMC_T_RP= 0x0013;
+# _DMC_T_RRD = 0x0002;
+# _DMC_T_WR= 0x0002;
+# _DMC_T_WTR = 0x0001;
+# _DMC_T_XP= 0x000A;
+# _DMC_T_XSR = 0x000B;
+# _DMC_T_ESR = 0x0014;
+#
+# //
+# // Configure SDRAM type parameter
+# _DMC_MEMORY_CFG = 0x8011;
+# _DMC_USER_CONFIG = 0x0011;
+# // 32 bit memory interface
+#
+#
+# _DMC_REFRESH_PRD = 0x0A60;
+# _DMC_CHIP_0_CFG = 0x000140FC;
+#
+# _DMC_DIRECT_CMD = 0x000C;
+# _DMC_DIRECT_CMD = 0x;
+#
+# _DMC_DIRECT_CMD = 0x0004;
+# _DMC_DIRECT_CMD = 0x0004;
+# _DMC_DIRECT_CMD = 0x00080031;
+# //
+# // Finally start SDRAM
+# //
+# _DMC_MEMC_CMD= MEMC_CMD_GO;
+# */
+
+mww 0xf0020260 0x0071
+mww 0xf4300014 0x0006
+mww 0xf4300018 0x
+mww 0xf430001C 0x0002
+mww 0xf4300020 0x0007
+mww 0xf4300024 0x000A
+mww 0xf4300028 0x0013
+mww 0xf430002C 0x010A
+mww 0xf4300030 0x0013
+mww 0xf4300034 0x0002
+mww 0xf4300038 0x0002
+mww 0xf430003C 0x0001
+mww 0xf4300040 0x000A
+mww 0xf4300044 0x000B
+mww 0xf4300048 0x0014
+mww 0xf43C 0x8011
+mww 0xf4300304 0x0011
+mww 0xf4300010 0x0A60
+mww 0xf4300200 0x000140FC
+mww 0xf438 0x000C
+mww 0xf438 0x
+mww 0xf438 0x0004
+mww 0xf438 0x0004
+mww 0xf438 0x00080031
+mww 0xf434 0x
+
+sleep 10
+#jtag_speed 1
+
+# remap off in case of IROM boot
+mww 0xf004 0x0001
+
+}
+
+# comment the following out if usinf J-Link, it soes not support DCC
+arm7_9 dcc_downloads enable # Enable faster DCC downloads
+
+
+#
+# Flash configuration
+#
+
+#flash bank cfi
+flash bank cfi 0x2000 0x200 2 2 0
diff -urN openocd-0.2.0_ORIG/tcl/board/topasa900.cfg
openocd-0.2.0/tcl/board/topasa900.cfg
--- openocd-0.2.0_ORIG/tcl/board/topasa900.cfg1970-01-01
01:00:00.0
+0100
+++ openocd-0.2.0/tcl/board/topasa900.cfg2009-09-23 14:41:10.0
+0200
@@ -0,0 +1,125 @@
+# Thanks to Pieter Conradie for this script!
+# Target:Toshiba TOPAS900 -- TMPA900 Starterkit
+##
+
+# We add to the minimal configuration.
+source [find target/tmpa900.cfg]
+
+##
+# Target configuration
+##
+
+#$_TARGETNAME configure -event gdb-attach { reset init }
+$_TARGETNAME configure -event reset-init { topasa900_init }
+
+proc topasa900_init { } {
+# Init PLL
+# my settings
+mww 0xf005000c 0x0007
+mww 0xf0050010 0x0065
+mww 0xf005000c 0x00a7
+sleep 10
+mdw 0xf0050008
+mww 0xf0050008 0x0002
+mww 0xf0050004 0x
+# NEW: set CLKCR5
+mww 0xf0050054 0x0040
+#
+# bplan settings
+#mww 0xf0050004 0x
+#mww 0xf005000c 0x00a7
+#sleep 10
+#mdw 0xf0050008
+#mww 0xf0050008 0x0002
+#mww 0xf0050010 0x0065
+#mww 0xf0050054 0x0040
+sleep 10
+# Init SDRAM
+# _PMCDRV = 0x0071;
+# //
+# // Initialize SDRAM timing paramater
+# //
+# _DMC_CAS_LATENCY = 0x0006;
+# _DMC_T_DQ
