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 state of SRST.
Index: src/jtag/tcl.c
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
On Tuesday 22 September 2009, michal smulski wrote: On Tue, 2009-09-22 at 17:59 -0700, David Brownell wrote: On Tuesday 22 September 2009, michal smulski wrote: The offending code is called from this function: static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, int* try_more) And the actual function call is here: status = FT_OpenEx(openex_string, openex_flags, ftdih); I'm not quite following here. First, what's wrong? In what way does that offend, what's the failure mechanism? The problem is that this functions asserts SRST (and TRST but not quitr right). This resets the CPU. openocd does immediate scan and it fails because the CPU is not ready. Hmm ... I had been hoping that JTAG adapters would initialize themselves to both SRST and TRST *inactive* but it seems we can't rely on that in this case because the FT2232 chip itself isn't cooperating. Maybe we need something like a call to jtag_add_reset(0, 0); very early in interface setup? Plus something to flush it, I guess. If the JTAG adapter itself is going to glitch those signals, we can't help that; but we can at least make sure that we have a clean init state on our end, even if the adapter sent the board out to lala-land for a while. Second, does this happen with libftdi too, or does that behave properly? I tried libftdi but it has different problems. I gave up on it because I had to power-cycle CPU after running openocd in order to get to talk to CPU. So I actually don't know what it does. Annoying. ftd2xx is a closed source library. However, openocd should not rely on any libraries to properly reset a chip since these libraries do not know what is a 'proper reset.' Openocd knows how it should reset the chip from *.tcl scripts. So I propose to add a reset after ft2232_init (or any other generic libs such as libftdi*) and before the first JTAG scan to properly reset devices on the scan chain. Again, I don't follow. What are you saying the init sequence should be? Which chip(s) should get reset when, and why? Are you referring to one of the chips on the target board? Or maybe the FT2232 chip? See my previous email to Øyvind. Where -- to summarize ruthlessly -- you said that not only is the FT2232 annoyingly imposing an SRST on you, but you also need an extra delay to recover from that. Right? I am talking about SRST/TRST reset as defined by reset_config command. This is only defined for reset init/halt/run but not for initial scan of the JTAG chain. Actually that jtag_init() code will call the same jtag_init_reset() that starts the reset halt sequence, *IF* the init_inner() fails. Now, there are some problems in that init_inner() doesn't much like to fail. Maybe it should be less accepting... at least on the initial invocation. Correct me if I'm wrong (and please consult the jtag/core.c init code to clarify): (a) your init_inner() call sees chaos but (b) doesn't fail, so (c) you're not getting that cautious call to have jtag_init_inner() do SRST at OpenOCD startup through that jtag_init() call, and thus (d) you're doing it yourself ... ... but if (b') it *DID* fail so (c') that got called as the code wants to be done, then (d') it looks like it'd work OK without needing the manual workaround? What OpenOCD tries to do today is first validate the scan chain defined to it using only TRST to ensure the TAPs are in a known state, one which exposes their IDCODE registers (if any) ... and if that works, it starts up without any SRST assertion, which is IMO the correct default behavior. If that fails, then jtag_init() will retry after a hard SRST assertion. Kind of unavoidable; maybe worth logging, that's kind of harsh. I don't to see a running board needlessly get reset just because OpenOCD got started. - Dave I do not see this behavior on a scope. The only thing I see is SRST/TRST asserted by ftd2xx library. openocd does not seem to touch those signals until you issue reset halt or similar. In fact, openocd hangs right after initial scan (if SRST is connected to CPU reset) because the CPU returns garbage. Where I've most recently seen that failure is if the JTAG clock rate is set very wrong. ;) And come to think of it, I think it can't have been going down the SRST path then either, despite what the code says to do when init_inner() loses. - Dave ___ 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
David Brownell wrote: Where -- to summarize ruthlessly -- you said that not only is the FT2232 annoyingly imposing an SRST on you, but you also need an extra delay to recover from that. Right? 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. cu Michael ___ 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
On Wednesday 23 September 2009, Michael Schwingen wrote: David Brownell wrote: Where -- to summarize ruthlessly -- you said that not only is the FT2232 annoyingly imposing an SRST on you, but you also need an extra delay to recover from that. Right? 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. Hmm ... FT2232 *does* have special 0x88 and 0x89 commands to block on ACBUS1 (GPIOH1) levels. And at least one adapter design I'm looking at hooks nSRST up to that, as an input (you can tell by, among other things, looking at how the level shifters are wired). So for such adapters (which I suspect aren' that common) it might be possible to add some special casing to handle that case. - Dave ___ 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
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
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
On Tuesday 22 September 2009, michal smulski wrote: The offending code is called from this function: static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, int* try_more) And the actual function call is here: status = FT_OpenEx(openex_string, openex_flags, ftdih); I'm not quite following here. First, what's wrong? In what way does that offend, what's the failure mechanism? Second, does this happen with libftdi too, or does that behave properly? ftd2xx is a closed source library. However, openocd should not rely on any libraries to properly reset a chip since these libraries do not know what is a 'proper reset.' Openocd knows how it should reset the chip from *.tcl scripts. So I propose to add a reset after ft2232_init (or any other generic libs such as libftdi*) and before the first JTAG scan to properly reset devices on the scan chain. Again, I don't follow. What are you saying the init sequence should be? Which chip(s) should get reset when, and why? Are you referring to one of the chips on the target board? Or maybe the FT2232 chip? What OpenOCD tries to do today is first validate the scan chain defined to it using only TRST to ensure the TAPs are in a known state, one which exposes their IDCODE registers (if any) ... and if that works, it starts up without any SRST assertion, which is IMO the correct default behavior. If that fails, then jtag_init() will retry after a hard SRST assertion. Kind of unavoidable; maybe worth logging, that's kind of harsh. I don't to see a running board needlessly get reset just because OpenOCD got started. - Dave ___ 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
Have you tried firing up openocd in the debugger? CFLAGS=-O0 -g configure ... insight --args openocd args Hook up scope and set a breakpoint in main(), start debugging... -- Øyvind Harboe ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html 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] JTAG controllers disabled while SRST is asserted
I've made a quick stab at implementing two new commands
(less documentation/help):
jtag_nsrst_assert_width
jtag_tsrst_assert_width
The implementation is a bit crude in that it assures a *minimum*
time that srst/trst are asserted.
More sophisticated methods are of course possible, but perhaps
this is obscure enough that we shouldn't try anything more clever...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 2726)
+++ src/jtag/jtag.h (working copy)
@@ -289,6 +289,12 @@
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);
+
/// @returns The current state of TRST.
int jtag_get_trst(void);
/// @returns The current state of SRST.
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,8 @@
/* 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 */
typedef struct jtag_event_callback_s
{
@@ -662,7 +664,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 +700,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)
@@ -1462,3 +1470,21 @@
{
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;
+}
Index: src/jtag/tcl.c
===
--- src/jtag/tcl.c (revision 2726)
+++ src/jtag/tcl.c (working copy)
@@ -61,6 +61,8 @@
static int handle_reset_config_command(struct command_context_s *cmd_ctx, char
*cmd, char **args, int argc);
static int handle_jtag_nsrst_delay_command(struct command_context_s *cmd_ctx,
char *cmd, char **args, int argc);
static int handle_jtag_ntrst_delay_command(struct command_context_s *cmd_ctx,
char *cmd, char **args, int argc);
+static int handle_jtag_nsrst_assert_width_command(struct command_context_s
*cmd_ctx, char *cmd, char **args, int argc);
+static int handle_jtag_ntrst_assert_width_command(struct command_context_s
*cmd_ctx, char *cmd, char **args, int argc);
static int handle_scan_chain_command(struct command_context_s *cmd_ctx, char
*cmd, char **args, int argc);
@@ -618,6 +620,10 @@
COMMAND_ANY, jtag_nsrst_delay ms - delay after deasserting
srst in ms);
register_command(cmd_ctx, NULL, jtag_ntrst_delay,
handle_jtag_ntrst_delay_command,
COMMAND_ANY, jtag_ntrst_delay ms - delay after deasserting
trst in ms);
+ register_command(cmd_ctx, NULL, jtag_nsrst_assert_width,
handle_jtag_nsrst_assert_width_command,
+ COMMAND_ANY, jtag_nsrst_assert_width ms - delay after
deasserting srst in ms);
+ register_command(cmd_ctx, NULL, jtag_ntrst_assert_width,
handle_jtag_ntrst_assert_width_command,
+ COMMAND_ANY, jtag_ntrst_assert_width ms - delay after
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
Neither of these methods apply to the initial jtag scan. At least not on
olimex dongle that I use.
I added this to my config
$_TARGETNAME configure -event reset-assert-post {
puts Assering reset
sleep 1
}
This does not get executed on the inital jtag scan:
Info : Disabled memory write burst mode.
Info : device: 4 2232C
Info : deviceID: 364511235
Info : SerialNumber: FTPUDDCF A
Info : Description: Olimex OpenOCD JTAG A
Info : clock speed 100 kHz
Info : JTAG tap: c100.dsp tap/device found: 0x27b3645b (mfg: 0x22d,
part: 0x7b36, ver: 0x2)
Info : JTAG tap: c100.cpu tap/device found: 0x27b3645b (mfg: 0x22d,
part: 0x7b36, ver: 0x2)
Info : found ARM1136
I want the reset delays to apply before this message
The same applies to jtag_nsrst_delay
(it does gets execute with 'reset halt/etc' commands but it is too late
as the jtag controller got confused by errors from ARM processor.)
I wonder is this different on different JTAG controllers? Does your JTAG
controller implements various delays correctly? What it would take to
correct this?
type help delay. You can control the delay after deasserting srst
/ trst.
Add sleep N to target's reset-assert-post event for a target and you
can lengthen the srst/trst pulse. There isn't a way to control the
width of those pulses individually though.
___
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
On Mon, Sep 14, 2009 at 10:08 PM, Johannes Stezenbach j...@sig21.net wrote: On Mon, Sep 14, 2009 at 08:35:32PM +0200, Øyvind Harboe wrote: On Mon, Sep 14, 2009 at 7:42 PM, David Brownell davi...@pacbell.net wrote: On Monday 14 September 2009, Ųyvind Harboe wrote: I suspect there are JTAG controllers that do not communicate when SRST is asserted, but do not pull TRST. srst_pulls_trst will kinda work on these devices i.MX27(??). The first thought that strikes me here is to split out srst_pulls_trst into two flags: pulls trst and no JTAG communication during srst What code do we have which wants JTAG chitchat during SRST? I thought arm7/9 did this, but I was wrong. I'm wondering if XScale needs this. Turns out after some more testing that i.MX27 does appear to pull trst during srst. I thought the desired reset procedure at least on ARM9 is: - pull SRST and TRST (TRST not only resets the TAP but also EmbeddedICE) - release TRST - program EmbeddedICE to break on reset vector - release SRST To optionally program arm7/9 if srst does not gate the JTAG clock is a possible improvement, but I'm not sure why it would be better to program EmbeddedICE to break on reset vector while srst is asserted. What would that achieve as oposed to first programming the break on reset and afterwards asserting/deasserting srst? There are SoCs where SRST gates the ARM core clock, thus you cannot program EmbeddedICE while SRST is asserted; then you need: - pull SRST and TRST - release SRST and TRST - program EmbeddedICE to break on reset vector - pull SRST again - release SRST The three last steps are indeed followed by OpenOCD. Additionally if srst pulls trst -- Ø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] JTAG controllers disabled while SRST is asserted
TODO updated. -- Ø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
[Openocd-development] JTAG controllers disabled while SRST is asserted
I suspect there are JTAG controllers that do not communicate when SRST is asserted, but do not pull TRST. srst_pulls_trst will kinda work on these devices i.MX27(??). The first thought that strikes me here is to split out srst_pulls_trst into two flags: pulls trst and no JTAG communication during srst -- Ø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] JTAG controllers disabled while SRST is asserted
On Monday 14 September 2009, Øyvind Harboe wrote: I suspect there are JTAG controllers that do not communicate when SRST is asserted, but do not pull TRST. srst_pulls_trst will kinda work on these devices i.MX27(??). The first thought that strikes me here is to split out srst_pulls_trst into two flags: pulls trst and no JTAG communication during srst What code do we have which wants JTAG chitchat during SRST? Or is the issue just that we haven't been able to grow such code because of that issue? Just adding a new flag ought to suffice... ___ 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
On Mon, Sep 14, 2009 at 7:42 PM, David Brownell davi...@pacbell.net wrote: On Monday 14 September 2009, Ųyvind Harboe wrote: I suspect there are JTAG controllers that do not communicate when SRST is asserted, but do not pull TRST. srst_pulls_trst will kinda work on these devices i.MX27(??). The first thought that strikes me here is to split out srst_pulls_trst into two flags: pulls trst and no JTAG communication during srst What code do we have which wants JTAG chitchat during SRST? I thought arm7/9 did this, but I was wrong. I'm wondering if XScale needs this. Turns out after some more testing that i.MX27 does appear to pull trst during srst. Or is the issue just that we haven't been able to grow such code because of that issue? Just adding a new flag ought to suffice... It's on my watch list, but the case I thought I had (i.MX27) turned out to be something else. -- Ø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] JTAG controllers disabled while SRST is asserted
On Monday 14 September 2009, Øyvind Harboe wrote: I thought arm7/9 did this, but I was wrong. I'm wondering if XScale needs this. PXA 25x should; not that it works now ... ___ 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
On Mon, 14 Sep 2009, David Brownell wrote: What code do we have which wants JTAG chitchat during SRST? Have a look at sheevaplug_init in tcl/board/sheevaplug.cfg. Nicolas ___ 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
On Mon, Sep 14, 2009 at 08:35:32PM +0200, Øyvind Harboe wrote: On Mon, Sep 14, 2009 at 7:42 PM, David Brownell davi...@pacbell.net wrote: On Monday 14 September 2009, Ųyvind Harboe wrote: I suspect there are JTAG controllers that do not communicate when SRST is asserted, but do not pull TRST. srst_pulls_trst will kinda work on these devices i.MX27(??). The first thought that strikes me here is to split out srst_pulls_trst into two flags: pulls trst and no JTAG communication during srst What code do we have which wants JTAG chitchat during SRST? I thought arm7/9 did this, but I was wrong. I'm wondering if XScale needs this. Turns out after some more testing that i.MX27 does appear to pull trst during srst. I thought the desired reset procedure at least on ARM9 is: - pull SRST and TRST (TRST not only resets the TAP but also EmbeddedICE) - release TRST - program EmbeddedICE to break on reset vector - release SRST There are SoCs where SRST gates the ARM core clock, thus you cannot program EmbeddedICE while SRST is asserted; then you need: - pull SRST and TRST - release SRST and TRST - program EmbeddedICE to break on reset vector - pull SRST again - release SRST Johannes ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
