What does your config script for openocd look like for the sam3x?
Using the Sam3X and Jlink, my sam3x.cfg looks like this:
source [find interface/jlink.cfg]
telnet_port 4444
gdb_port 2331
reset_config srst_only
source [find board/atmel_sam3x_ek.cfg]
$_TARGETNAME configure -event gdb-flash-erase-start {
halt
}
$_TARGETNAME configure -event gdb-attach {
halt
}
Regards
Olivier Schonken
On Wed, Dec 5, 2012 at 9:16 PM, <[email protected]
> wrote:
> Send OpenOCD-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenOCD-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: sam3.cpu: IR capture error; saw 0x0f not 0x01 (Freddie Chopin)
> 2. Re: debugging pandaboard + flyswatter2 + mpsse (Bill Traynor)
> 3. Re: sam3.cpu: IR capture error; saw 0x0f not 0x01
> (Andreas Fritiofson)
> 4. Re: sam3.cpu: IR capture error; saw 0x0f not 0x01 (Freddie Chopin)
> 5. Re: sam3.cpu: IR capture error; saw 0x0f not 0x01 (Arnd Begemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 04 Dec 2012 23:49:51 +0100
> From: Freddie Chopin <[email protected]>
> Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not
> 0x01
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> W dniu 2012-12-04 23:27, Andreas Fritiofson pisze:
> > Is the gating required for this chip family? That makes it harder to
> > connect under reset to avoid the previous.
>
> It's the default option...
>
> > Try with hard srst.
>
> If SRST is enabled (and it is), this setting makes no difference, as H/W
> always takes precedence.
>
> 4\/3!!
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 4 Dec 2012 19:43:06 -0500
> From: Bill Traynor <[email protected]>
> Subject: Re: [OpenOCD-devel] debugging pandaboard + flyswatter2 +
> mpsse
> To: Andreas Fritiofson <[email protected]>
> Cc: OpenOCD <[email protected]>
> Message-ID:
> <
> cagfzjq6vhv5hbqbwmc9ipa21gc8cycptzk0oylccc7p2s3f...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Mon, Dec 3, 2012 at 4:25 PM, Andreas Fritiofson <
> [email protected]> wrote:
>
> >
> >
> >
> > On Mon, Dec 3, 2012 at 6:08 PM, Bill Traynor <[email protected]>
> wrote:
> >
> >> On Sat, Nov 17, 2012 at 4:35 PM, Andreas Fritiofson <
> >> [email protected]> wrote:
> >>
> >>> Hi!
> >>>
> >>> I don't have a Pandaboard and I don't see the problem even if I try to
> >>> perform similar operations. It may be related to RCLK (which I can't
> test
> >>> with) so if you could try switching that off. Please also post a log
> with
> >>> --enable-verbose-jtag-io passed to configure. It will be rather big, so
> >>> it's good that it seems to hang early.
> >>
> >>
> >> Thanks for the tip. I've attached the startup debug log after
> >> recompiling with --enable-verbose-jtag-io.
> >>
> >
> > So, did you test without RCLK? Everything in the log points to some
> > problem with RCLK. It's entirely possible that the ftdi driver has some
> > problem with RCLK, since my testing with that has been very limited. On
> the
> > other hand RCLK support is just a matter of flipping a switch in the
> mpsse
> > engine so there's not much that can go wrong there. If you try with the
> old
> > ft2232 driver and you still have problems, I'd say you have an issue with
> > your target, adapter and/or wiring. If, on the other hand, the old driver
> > works, we'll have to do a bit more debugging.
> >
> > Yes. Working with Peter, we were able to connect to a Beagleboard by
> commenting out the adapter_khz is commented out in
> board/ti_beagleboard.cfg and target/omap3530.cfg and then explicitly set
> low to 10khz. So it would appear something is amiss with rtck and the new
> ftdi driver.
>
> I'll continue to test as I have free time.
>
> /Andreas
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 5 Dec 2012 08:44:24 +0100
> From: Andreas Fritiofson <[email protected]>
> Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not
> 0x01
> To: Freddie Chopin <[email protected]>
> Cc: OpenOCD ML <[email protected]>
> Message-ID:
> <CAKGHftdAJ2Gx=N9KTM=tUGoassN4tpU-yTma8Uf18=
> [email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Dec 4, 2012 at 11:49 PM, Freddie Chopin <[email protected]
> >wrote:
>
> > W dniu 2012-12-04 23:27, Andreas Fritiofson pisze:
> > > Is the gating required for this chip family? That makes it harder to
> > > connect under reset to avoid the previous.
> >
> > It's the default option..
> >
>
> Then he should try setting srst_nogate.
>
>
> > > Try with hard srst.
> >
> > If SRST is enabled (and it is), this setting makes no difference, as H/W
> > always takes precedence.
> >
>
> You may be right, but then it sounds like a misfeature. Why shouldn't a
> target specific behavior override the generic mechanism?
>
> Anyway, if that's the case, he really needs to verify his reset wiring. Or
> try with srst disabled...
>
> /Andreas
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Wed, 05 Dec 2012 09:07:23 +0100
> From: Freddie Chopin <[email protected]>
> Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not
> 0x01
> To: Andreas Fritiofson <[email protected]>
> Cc: OpenOCD ML <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> W dniu 2012-12-05 08:44, Andreas Fritiofson pisze:
> > You may be right, but then it sounds like a misfeature. Why shouldn't a
> > target specific behavior override the generic mechanism?
>
> It was like this when this cortex-m3 option was introduced, but
> fortunately it was changed, because then all targets used soft resets
> even if h/w reset was available, and that last one is always better
> (especially for targets where sysrstreq is not working and vectreset
> doesn't reset peripherals - like LPC17xx where you have to explicitly
> state the core clock to flash it). If user specifies that there is a
> reset than this reset should be used. cortex-m3 soft reset is defined in
> cortex-m3 target configs and there's really no point in editing this
> every time you change something...
>
> You'll probably be able to easily find the discussion about that thing
> back then - I think it all goes down to not-very-lucky design of OpenOCD
> where everything is imperative, while it would be better if it would
> work like that:
> - interface specifies what it supports (what reset signals it has)
> - target/board specifies what it supports (what resets are supported,
> what lines are routed and how, ...)
> - OpenOCD chooses the best possible combination (interface has 2 resets
> but target has only 1? use "srst_only" then)
> - user can optionally override that
>
> With current design (almost) no interface and no target config specifies
> resets as this wouldn't work as expected - users always have to specify
> them by hand and usability suffers... No one will change the fact that
> the most "user friendly" software is the one that doesn't need much
> configuration and OpenOCD is not among such programs.
>
> 4\/3!!
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 5 Dec 2012 20:16:13 +0100
> From: Arnd Begemann <[email protected]>
> Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not
> 0x01
> To: "[email protected]"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> I program a simple program on the board SAM3X-EK Board by using the build
> in SAM-BA boot program.
> No i could connect to the Cortex M3 JTAG tab. But the device is not
> controllable.
> :
>
>
> Open On-Chip Debugger 0.7.0-dev-00095-g27ad96e (2012-12-04-20:08)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.sourceforge.net/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> srst_only separate srst_gates_jtag srst_open_drain
> adapter speed: 500 kHz
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> cortex_m3 reset_config sysresetreq
> srst_only separate srst_gates_jtag srst_open_drain
> cortex_m3 reset_config sysresetreq
> Info : clock speed 500 kHz
> Info : JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
> 0xba00, ver: 0x4)
> Error: sam3.cpu: IR capture error; saw 0x0f not 0x01
> Warn : Bypassing JTAG setup events due to errors
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x23000041, MEM_AP_TAR 0xd8c00000
> Polling target failed, GDB will be halted. Polling again in 100ms
> Polling target failed, GDB will be halted. Polling again in 300ms
> Polling target failed, GDB will be halted. Polling again in 700ms
> Polling target failed, GDB will be halted. Polling again in 1500ms
> Polling target failed, GDB will be halted. Polling again in 3100ms
>
>
> Regard, Arnd
>
> Am 05.12.2012 um 09:07 schrieb Freddie Chopin <[email protected]>:
>
> > W dniu 2012-12-05 08:44, Andreas Fritiofson pisze:
> >> You may be right, but then it sounds like a misfeature. Why shouldn't a
> >> target specific behavior override the generic mechanism?
> >
> > It was like this when this cortex-m3 option was introduced, but
> > fortunately it was changed, because then all targets used soft resets
> > even if h/w reset was available, and that last one is always better
> > (especially for targets where sysrstreq is not working and vectreset
> > doesn't reset peripherals - like LPC17xx where you have to explicitly
> > state the core clock to flash it). If user specifies that there is a
> > reset than this reset should be used. cortex-m3 soft reset is defined in
> > cortex-m3 target configs and there's really no point in editing this
> > every time you change something...
> >
> > You'll probably be able to easily find the discussion about that thing
> > back then - I think it all goes down to not-very-lucky design of OpenOCD
> > where everything is imperative, while it would be better if it would
> > work like that:
> > - interface specifies what it supports (what reset signals it has)
> > - target/board specifies what it supports (what resets are supported,
> > what lines are routed and how, ...)
> > - OpenOCD chooses the best possible combination (interface has 2 resets
> > but target has only 1? use "srst_only" then)
> > - user can optionally override that
> >
> > With current design (almost) no interface and no target config specifies
> > resets as this wouldn't work as expected - users always have to specify
> > them by hand and usability suffers... No one will change the fact that
> > the most "user friendly" software is the one that doesn't need much
> > configuration and OpenOCD is not among such programs.
> >
> > 4\/3!!
> >
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > OpenOCD-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
> ------------------------------
>
> _______________________________________________
> OpenOCD-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
>
> End of OpenOCD-devel Digest, Vol 14, Issue 4
> ********************************************
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
