From: Olivier S. <oli...@gm...> - 2012-12-05 21:51:17
|
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, <ope...@li... > wrote: > Send OpenOCD-devel mailing list submissions to > ope...@li... > > 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 > ope...@li... > > You can reach the person managing the list at > ope...@li... > > 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 <fre...@op...> > Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not > 0x01 > To: ope...@li... > Message-ID: <50B...@op...> > 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 <wm...@al...> > Subject: Re: [OpenOCD-devel] debugging pandaboard + flyswatter2 + > mpsse > To: Andreas Fritiofson <and...@gm...> > Cc: OpenOCD <ope...@li...> > Message-ID: > < > CAG...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > On Mon, Dec 3, 2012 at 4:25 PM, Andreas Fritiofson < > and...@gm...> wrote: > > > > > > > > > On Mon, Dec 3, 2012 at 6:08 PM, Bill Traynor <wm...@al...> > wrote: > > > >> On Sat, Nov 17, 2012 at 4:35 PM, Andreas Fritiofson < > >> and...@gm...> 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 <and...@gm...> > Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not > 0x01 > To: Freddie Chopin <fre...@op...> > Cc: OpenOCD ML <ope...@li...> > Message-ID: > <CAKGHftdAJ2Gx=N9KTM=tUGoassN4tpU-yTma8Uf18= > 5Yh...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue, Dec 4, 2012 at 11:49 PM, Freddie Chopin <fre...@op... > >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 <fre...@op...> > Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not > 0x01 > To: Andreas Fritiofson <and...@gm...> > Cc: OpenOCD ML <ope...@li...> > Message-ID: <50B...@op...> > 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 <arn...@go...> > Subject: Re: [OpenOCD-devel] sam3.cpu: IR capture error; saw 0x0f not > 0x01 > To: "ope...@li..." > <ope...@li...> > Message-ID: <101...@go...> > 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 <fre...@op...>: > > > 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 > > Ope...@li... > > 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openocd-devel > > > End of OpenOCD-devel Digest, Vol 14, Issue 4 > ******************************************** > |