Re: [Openocd-development] new lpc2xxx cfg files layout
Rolf Meeser pisze: > How would you write a board file for a board with two LPC2103 in the > chain? A simple source [find target/lpc2103.cfg] source [find > target/lpc2103.cfg] wouldn't work because it would try to declare two > targets with the same name (lpc2103.cpu). > > Previously it was possible to write: set CHIPNAME chip1 source [find > target/lpc2103.cfg] set CHIPNAME chip2 source [find > target/lpc2103.cfg] It gave you two targets chip1.cpu and chip2.cpu. You should not source lpc2103.cfg twice, but lpc2xxx_internals.tcl twice - with all necessary defines. A little more text unfortunately. > Regarding the clock speed: What you call CRYSTAL_FREQ is the > frequency that is in use when you do the flash programming. In order > to be able to maximize the download speed, I want to enable the PLL > in the "reset init" script. This operating frequency isn't really > related to the crystal frequency, and I think the name CRYSTAL_FREQ > is misleading. Many people in the past had problems with flash > programming because they specified the crystal frequency where they > should have used the real CCLK! > > This clock frequency is something that the user should specify in a > board file. Do you suggest renaming CRYSTAL_FREQ to (for example) CCLK_FREQ or some other changes? > The reset init script must be available to the user, because he needs > it to add the PLL initialization. Where would I enable the PLL when a > default reset init script is already defined in the target script? From what I have noticed all LPC2xxx have exactly the same PLL configuration scheme, so that's more like target related in my opinion. The PLL setup code will work (when written right) on all LPC2xxx chips. The only concen is the difference between the chips with / without internal RC. > The working area should start at 0x4200. This makes sure that > there is no conflict with possible temporary storage of IAP code (has > been a problem in the past, although the 0x4000--0x41FF area > should have been used by ISP code only). A strict requirement is to > not touch the upper 32 bytes of the internal SRAM. This RAM area is > definitely used by the IAP routines internally! Sounds reasonable, but in my experience I haven't noticed any problems with using exactly whole RAM. > There are devices with external memory bus. A user might want to use > an external RAM for the working area instead of the internal SRAM. > Therefore I think the working area declaration is board specific and > doesn't belong to the target declaration. The start of working area can be made "overridable" with default being 0x4000. > What do you think about modifying the LPC2000 flash driver to adapt > itself to the various devices? It can read the part id and > auto-configure itself. You could keep the FLASH_SIZE and RAM_SIZE > variables to override any automatic detection. I feel it would make > life a lot easier! I've noticed that ideas of auto-whatever are not liked here <: For me that's cool, but beyond my knowledge. With every modification that is suggested the script is becoming more and more complex. At the beginning (in my original idea) all that was required was the chip name. Then the part config files need all the details. Now there is a need for another level of abstraction with wrapper script to configure the clock. You propose individual reset-init scripts and individual work area placement... To be honest, I'm loosing the faith in this whole idea, because the complex is becoming more complex, not simple... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Hi Freddie,
I didn't find the time yet to write a few comments. But here they are:
They are all meant to be constructive and friendly! :-)
How would you write a board file for a board with two LPC2103 in the chain?
A simple
source [find target/lpc2103.cfg]
source [find target/lpc2103.cfg]
wouldn't work because it would try to declare two targets with the same name
(lpc2103.cpu).
Previously it was possible to write:
set CHIPNAME chip1
source [find target/lpc2103.cfg]
set CHIPNAME chip2
source [find target/lpc2103.cfg]
It gave you two targets chip1.cpu and chip2.cpu.
Regarding the clock speed: What you call CRYSTAL_FREQ is the frequency that is
in use when you do the flash programming. In order to be able to maximize the
download speed, I want to enable the PLL in the "reset init" script. This
operating frequency isn't really related to the crystal frequency, and I think
the name CRYSTAL_FREQ is misleading.
Many people in the past had problems with flash programming because they
specified the crystal frequency where they should have used the real CCLK!
This clock frequency is something that the user should specify in a board file.
The reset init script must be available to the user, because he needs it to add
the PLL initialization. Where would I enable the PLL when a default reset init
script is already defined in the target script?
The working area should start at 0x4200. This makes sure that there is no
conflict with possible temporary storage of IAP code (has been a problem in the
past, although the 0x4000--0x41FF area should have been used by ISP
code only).
A strict requirement is to not touch the upper 32 bytes of the internal SRAM.
This RAM area is definitely used by the IAP routines internally!
There are devices with external memory bus. A user might want to use an
external RAM for the working area instead of the internal SRAM. Therefore I
think the working area declaration is board specific and doesn't belong to the
target declaration.
What do you think about modifying the LPC2000 flash driver to adapt itself to
the various devices? It can read the part id and auto-configure itself. You
could keep the FLASH_SIZE and RAM_SIZE variables to override any automatic
detection. I feel it would make life a lot easier!
Regards,
Rolf
--- Freddie Chopin schrieb am So, 27.9.2009:
> Von: Freddie Chopin
> Betreff: Re: [Openocd-development] new lpc2xxx cfg files layout
> An: "openocd-development"
> Datum: Sonntag, 27. September 2009, 21:05
> Be it your way...
>
> 4\/3!!
>
> -Integrierter Anhang folgt-
>
> Index: tcl/target/lpc2103.cfg
> ===
> --- tcl/target/lpc2103.cfg (revision
> 2744)
> +++ tcl/target/lpc2103.cfg (working
> copy)
> @@ -1,38 +1,19 @@
> -# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM,
> clocked with 12MHz crystal
> +# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM
> +#
> -
> +# do not use this file directly! the caller has to specify
> CRYSTAL_FREQ with:
> +# set CRYSTAL_FREQ
> +#
> -
>
> -if { [info exists CHIPNAME] } {
> - set _CHIPNAME $CHIPNAME
> -} else {
> - set _CHIPNAME lpc2103
> -}
> +set CHIPNAME lpc2103
> +set FLASH_SIZE 0x8000
> +set RAM_SIZE 0x2000
>
> -if { [info exists ENDIAN] } {
> - set _ENDIAN $ENDIAN
> -} else {
> - set _ENDIAN little
> -}
> +set VARIANT lpc2000_v2
>
> -if { [info exists CPUTAPID ] } {
> - set _CPUTAPID $CPUTAPID
> -} else {
> - set _CPUTAPID 0x4f1f0f0f
> -}
> +set CPUTAPID 0x4f1f0f0f
>
> -# LPC2000 -> SRST causes TRST
> -reset_config trst_and_srst srst_pulls_trst
> +set JTAG_FREQ 100
>
> -# reset delays
> -jtag_nsrst_delay 100
> -jtag_ntrst_delay 100
> +set RESET_CONFIG trst_and_srst
>
> -jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask
> 0xf -expected-id $_CPUTAPID
> -
> -set _TARGETNAME $_CHIPNAME.cpu
> -target create $_TARGETNAME arm7tdmi -endian $_ENDIAN
> -chain-position $_TARGETNAME -variant arm7tdmi-s_r4
> -
> -# 8kB of internal SRAM
> -$_TARGETNAME configure -work-area-virt 0 -work-area-phys
> 0x4000 -work-area-size 0x2000 -work-area-backup 0
> -
> -# 32kB of internal Flash, core clocked with 12MHz crystal
> -# flash bank lpc2000 0 0
>
> [calc_checksum]
> -flash bank lpc2000 0x0 0x8000 0 0 0 lpc2000_v2 12000
> calc_checksum
> +source [find target/lpc2xxx_internals.tcl]
> Index: tcl/target/lpc2124.cfg
> ===
> --- tcl/target/lpc2124.cfg (revision
> 2744)
> +++ tcl/target/lpc2124.cfg (working
> copy)
> @@ -1,42 +1,19 @@
> -#LPC-2124 CPU
> +# NXP LPC2124 ARM7TDMI-S with 256kB Flash and 16kB SRAM
> +#
> -
> +# do not use this file directly! the caller has to specify
> CRYSTAL_FR
[Openocd-development] STR9 Hitex comStick jtag lockup problem FIX, for Linux, suggested updateing openocd DOC's to help people not all into this trap
Tittle: Fix for STR9 Hitex comStick(REV A2) evaluation board JTAG lockup. under openocd, and FTDI libftd2xx V 4.16(maybe other versions to) The Symptom: Comstick on board JTAG interface fail's, requiring the board to be unplugged and reinserted, to gain control. (even this will fail! fix the problem), could be other Symptom's too. The Problem: The hardware design of the str9 comStick board, use's a FT2232 usb chip in JTAG mode. This chip has 5 power pin's, 2 VCC,1 AVCC,1 VCCIOA and 1 VCCIOB. The power to the VCCIOA and VCCIOB is controlled by the FTDI PWREN# pin, via a FET, and 3.3 volt reg. (this also powers the STR912 CPU) While the 2 VCC pin's and AVCC is connected directly to the USB power from the host computer. When the chip is reset, the power to the VCCIOA(B) and CPU is turn off, This appears to mess up the FT2232 internal driver's powered from the VCCIOA and VCCIOB pin's, this powers the JTAG interface and reset to the str912 chip. The fault shows up as no JTAG clock, and low logic HI voltage's on the FT2232 JTAG pin's. Looking at the FTDI data sheet I see they don't give any examples of the VCCIOA and VCCIOB used in the way Hitex comStick have used it. FTDI examples shows VCCIOA,VCCIOB always power up/down the same time as VCC and AVCC. The Software Fix: (no luck here sorry.. ) The FTDI driver for Linux, always resets the FTDI chip on the board, when the openEx() is call from the openocd program, Which of course turns the power off/on to the VCCIOA(B) and if lucky may works, but for me most of the time it screw's up. The FTDI libftd2xx has a con-fig option which is supposed to disable the reset too the FTDI chip, when you use the openEx() call, but setting this option, had no affect. It still reset the FTDI chip on openEx call. The Hardware Fix: (only one which works so far) The FTDI site is not much help, no source etc.. it only left with hardware fix option. Solder a low (6.2 Ohms) value resistor or jumper across the power control FET. Thus shorting the FET out and keeping power on to the VCCIOA(B) pin's. If you use the 0 Ohms resistor jumper option you will get plug-in start up current spike. Which may cause the USB current limit safety circuit to trip. But for me, the 0 Ohms option work OK, I also tried 6.2 Ohms resistor jumper, and that appeared to work OK to. The jumper is placed bottom side of the PCB, where your see Ethernet connector, bottom side. looking you will see 2 wide trace's. Just to the NW of the Ethernet connector mount hole. (Orientation is USB connector to host computer, on right and expansion connectors, USB, Ethernet to the left bottom side) Scratch off the solder resist, and solder jumper/resistor there to join the two thick trace's, I can post/email picture's of the mode, if the above info is not helpful. On a side note, the FTDI serial port is not recognized by the Linux kernel so you can not use the serial port on the comStick to talk to the STR9 CPU, only fix for this is to add the VIP/PID too the ftdi_sio.c and ftdi_sio.h and also disable the disable the kernel from using the JTAG port as serial port. Recompile the kernel. I can post this patch if any one is interested. Good luck. Lachlan Audas _ Lauren found her dream laptop. Find the PC that’s right for you. http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Be it your way...
4\/3!!
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg (revision 2744)
+++ tcl/target/lpc2103.cfg (working copy)
@@ -1,38 +1,19 @@
-# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM, clocked with 12MHz
crystal
+# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM
+# -
+# do not use this file directly! the caller has to specify CRYSTAL_FREQ with:
+# set CRYSTAL_FREQ
+# -
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2103
-}
+set CHIPNAME lpc2103
+set FLASH_SIZE 0x8000
+set RAM_SIZE 0x2000
-if { [info exists ENDIAN] } {
- set _ENDIAN $ENDIAN
-} else {
- set _ENDIAN little
-}
+set VARIANT lpc2000_v2
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- set _CPUTAPID 0x4f1f0f0f
-}
+set CPUTAPID 0x4f1f0f0f
-# LPC2000 -> SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+set JTAG_FREQ 100
-# reset delays
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
+set RESET_CONFIG trst_and_srst
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi-s_r4
-
-# 8kB of internal SRAM
-$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x4000
-work-area-size 0x2000 -work-area-backup 0
-
-# 32kB of internal Flash, core clocked with 12MHz crystal
-# flash bank lpc2000 0 0
[calc_checksum]
-flash bank lpc2000 0x0 0x8000 0 0 0 lpc2000_v2 12000 calc_checksum
+source [find target/lpc2xxx_internals.tcl]
Index: tcl/target/lpc2124.cfg
===
--- tcl/target/lpc2124.cfg (revision 2744)
+++ tcl/target/lpc2124.cfg (working copy)
@@ -1,42 +1,19 @@
-#LPC-2124 CPU
+# NXP LPC2124 ARM7TDMI-S with 256kB Flash and 16kB SRAM
+# -
+# do not use this file directly! the caller has to specify CRYSTAL_FREQ with:
+# set CRYSTAL_FREQ
+# -
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2124
-}
+set CHIPNAME lpc2124
+set FLASH_SIZE 0x4
+set RAM_SIZE 0x4000
-if { [info exists ENDIAN] } {
- set _ENDIAN $ENDIAN
-} else {
- set _ENDIAN little
-}
+set VARIANT lpc2000_v1
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- # force an error till we get a good number
-set _CPUTAPID 0x4f1f0f0f
-}
+set CPUTAPID 0x4f1f0f0f
+set JTAG_FREQ 100
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+set RESET_CONFIG trst_and_srst
-# reset delays
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-jtag_khz 1000
-
-#jtag scan chain
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi-s_r4
-
-$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x4000
-work-area-size 0x4000 -work-area-backup 0
-
-
-#flash bank
-flash bank lpc2000 0x0 0x4 0 0 0 lpc2000_v1 14745 calc_checksum
+source [find target/lpc2xxx_internals.tcl]
Index: tcl/target/lpc2129.cfg
===
--- tcl/target/lpc2129.cfg (revision 2744)
+++ tcl/target/lpc2129.cfg (working copy)
@@ -1,41 +1,19 @@
-#LPC-2129 CPU
+# NXP LPC2129 ARM7TDMI-S with 256kB Flash and 16kB SRAM
+# -
+# do not use this file directly! the caller has to specify CRYSTAL_FREQ with:
+# set CRYSTAL_FREQ
+# -
+set CHIPNAME lpc2129
+set FLASH_SIZE 0x4
+set RAM_SIZE 0x4000
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2129
-}
+set VARIANT lpc2000_v1
-if { [info exists ENDIAN] } {
- set _ENDIAN $ENDIAN
-} else {
- set _ENDIAN little
-}
+set CPUTAPID 0x4f1f0f0f
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- # force an error till we get a good number
- set _CPUTAPID 0x
-}
+set JTAG_FREQ 100
+set RESET_CONFIG trst_and_srst
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
-
-# reset delays
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#jtag scan chain
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-
-
-set _TARGETNAME $_
Re: [Openocd-development] new lpc2xxx cfg files layout
David Brownell pisze: > Not sure; did it fail the same way with that set in > an "openocd.cfg" file? > > There's a bunch of code that works today and uses > variables set in previous files. If you're doing > that the same way that code does, I'd expect it > to "just work". > > If it doesn't ... seems buggish, but maybe you > could declare it as a global. I works when I use a wrapper script, but doesn't work when I use -c "set CRYSTAL_FREQ 1200" -f target/lpc2103.cfg 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] srst pulls trst bug in ft2232
On Sun, Sep 27, 2009 at 7:28 PM, David Brownell wrote: > On Sunday 27 September 2009, Ųyvind Harboe wrote: >> I can't find the place in the ft2232 code where the state is set >> to TAP_RESET when srst pulls trst under a reset... > > I'd have expected that to be in common jtag/core.c code ... > > >> How does the attached patch look? >> >> rlink.c, bitbang.c, bitq.c and zy1000 all have this code >> path right. > > instead of needing to modify every driver. In this > case there's no obstacle to fixing that once in the core. > (Instead of N times in each driver...) I don't think you can or should do this in the core driver. core.c has no way of knowing and shouldn't know how each driver tracks the current state. The current TAP state can be tracked by hardware and it would add software overhead(yes, this *does* matter for embedded implementations) to track the TAP state. The current solution is relatively straightforward, even if it is a bit of copy & paste. -- Øyvind Harboe 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] new lpc2xxx cfg files layout
On Sunday 27 September 2009, Freddie Chopin wrote: > David Brownell pisze: > >> -f interface/sth.cfg -f target/sth.cfg > > > > That's the same as a "wrapper script". > > > > Just stick "-c set CRYSTAL_SPEED 3579545" in there, same effect. > > I tried the same yesterday (-c "set CRYSTAL_FREQ xxx") but... it doesn't > work... > > > c:\>openocd -c "set CRYSTAL_FREQ 1200" -f target/lpc2103.cfg > > Open On-Chip Debugger 0.2.0 (2009-07-26-10:51) Release > > $URL: > > http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd > > .c $ > > For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > Runtime error, file "C:\Program > > Files\OpenOCD\0.2.0\bin\../target/lpc2xxx_intern > > als.tcl", line 32: > > Variable: CRYSTAL_FREQ is not set, cannot continue > > What am I missing? Not sure; did it fail the same way with that set in an "openocd.cfg" file? There's a bunch of code that works today and uses variables set in previous files. If you're doing that the same way that code does, I'd expect it to "just work". If it doesn't ... seems buggish, but maybe you could declare it as a global. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] srst pulls trst bug in ft2232
On Sunday 27 September 2009, Øyvind Harboe wrote: > I can't find the place in the ft2232 code where the state is set > to TAP_RESET when srst pulls trst under a reset... I'd have expected that to be in common jtag/core.c code ... > How does the attached patch look? > > rlink.c, bitbang.c, bitq.c and zy1000 all have this code > path right. instead of needing to modify every driver. In this case there's no obstacle to fixing that once in the core. (Instead of N times in each driver...) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] bugfix ft2232 entry to TAP_RESET
On Sunday 27 September 2009, Øyvind Harboe wrote: > I think we should list the broken drivers in TODO and > leave it at that. Done ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] srst pulls trst bug in ft2232
I can't find the place in the ft2232 code where the state is set
to TAP_RESET when srst pulls trst under a reset...
How does the attached patch look?
rlink.c, bitbang.c, bitq.c and zy1000 all have this code
path right.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/ft2232.c
===
--- src/jtag/ft2232.c (revision 2762)
+++ src/jtag/ft2232.c (working copy)
@@ -1701,6 +1701,11 @@
first_unsent = cmd;
}
+ if ((cmd->cmd.reset->trst == 1) || (cmd->cmd.reset->srst &&
(jtag_get_reset_config() & RESET_SRST_PULLS_TRST)))
+ {
+ tap_set_state(TAP_RESET);
+ }
+
layout->reset(cmd->cmd.reset->trst, cmd->cmd.reset->srst);
require_send = 1;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] bugfix ft2232 entry to TAP_RESET
> Fixing around a dozen driver seems messy, but perhaps > unavoidable. Do you think I should check in $SUBJECT > and have us seek patches and testing for all of the > other drivers? I think we should list the broken drivers in TODO and leave it at that. There are lots of known bugs/problems in OpenOCD for which help is wanted... -- Øyvind Harboe 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/rfc] bugfix ft2232 entry to TAP_RESET
On Sunday 27 September 2009, Øyvind Harboe wrote:
> > Comments?
>
> TAP_RESET is special. Navigating to this state
> can only be done via jtag_add_tlr().
Or equivalently jtag_add_statemove(TAP_RESET), which
calls jtag_add_tlr() in turn.
There's bit of a maze at the intermediate levels, which
to a first approximation map add_tlr() to a driver level
JTAG_STATEMOVE and everything else to JTAG_PATHMOVE.
> No assumptions
> should be made about the JTAG TAP state as
e.g. by not calling tap_get_state() ...
> jtag_add_tlr() supports being invoked when the state has
> been modified by some external event.
That doesn't help as much as I'd like, since it's a few
levels above where symptoms start to appear.
My concern is that it looks like most of the JTAG adapter
("interface") drivers have a bug in this area. STATEMOVE
handler code for most drivers seems to assume the current
recorded TAP state is correct in all cases ... instead of
ignoring it for TAP_RESET transitions. (The first few
drivers, in alphabetical order, are all wrong in how they
handle that case ...)
Fixing around a dozen driver seems messy, but perhaps
unavoidable. Do you think I should check in $SUBJECT
and have us seek patches and testing for all of the
other drivers?
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] core dump files for openocd
Has anyone looked at adding coredump file support to OpenOCD? I don't know what the format is, but core dump files could be quite small for many targets(a few megabytes at most). If OpenOCD grows coredump support and the coredump files are small, then perhaps OpenOCD could be modified to save off the state every time the target enters the halted state, giving a full debug session record w/possibility of attaching the full debug sessions to bug reports, etc. Such advanced features are powerful, but the downside is that the audience is going to be limited to those that have a need and manage to dig up such features. It would be good if there was some natural way in which such features could be made more visible. -- Øyvind Harboe 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/rfc] bugfix ft2232 entry to TAP_RESET
> Comments? TAP_RESET is special. Navigating to this state can only be done via jtag_add_tlr(). No assumptions should be made about the JTAG TAP state as jtag_add_tlr() supports being invoked when the state has been modified by some external event. -- Øyvind Harboe 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/rfc] bugfix ft2232 entry to TAP_RESET
David Brownell wrote: > So this one's nasty, because of the root cause: OpenOCD init > state is incorrect, so "shortest path" through the JTAG state > machine wrongly short-circuits. Fix is either: > > (a) update every interface driver (!) like this > (b) or else find some core fix > > Expedience suggests (a), since there's no TMS+TCK level interface > to the drivers, and I'm not sure there should be. > ACK from me. The drivers should always enter TAP_RESET unconditionally, and not try to short-circuit that state. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
David Brownell pisze: >> -f interface/sth.cfg -f target/sth.cfg > > That's the same as a "wrapper script". > > Just stick "-c set CRYSTAL_SPEED 3579545" in there, same effect. I tried the same yesterday (-c "set CRYSTAL_FREQ xxx") but... it doesn't work... > c:\>openocd -c "set CRYSTAL_FREQ 1200" -f target/lpc2103.cfg > Open On-Chip Debugger 0.2.0 (2009-07-26-10:51) Release > $URL: > http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd > .c $ > For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > Runtime error, file "C:\Program > Files\OpenOCD\0.2.0\bin\../target/lpc2xxx_intern > als.tcl", line 32: > Variable: CRYSTAL_FREQ is not set, cannot continue What am I missing? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
