date:20090921

Re: [Openocd-development] problems with FASTDATA bulk write and spansion flash

2009-09-21 Thread Rolf Meeser

Hi Stephan,

Thanks!

I just saw that you are using a MIPS processor. The cfi_spansion_write_block() 
function supports ARM targets only. Currently this executes ARM opcodes on your 
machine, so you can be lucky that it returned at all :-)
There is no checking the architecture yet.

I believe your only choice at the moment is to not define a working area (or 
one that has a ~300 bytes maximum). That would ensure that the ARM code doesn't 
get executed because of low resources.

Or maybe you want to fix it? :-)

Regards,
Rolf

Anyone: How can I detect most efficiently that a target supports ARM code?




--- Stephan Winokur  schrieb am Mo, 21.9.2009:

> Von: Stephan Winokur 
> Betreff: Re: AW: [Openocd-development] problems with FASTDATA bulk  write and 
> spansion flash
> An: "Rolf Meeser" , openocd-development@lists.berlios.de
> Datum: Montag, 21. September 2009, 7:47
> Hi Rolf,
> 
> The device is a Spansion S29GL512P11TFI01.
> 
> flash info 0 says:
> > flash info 0
> #0 : cfi at 0x4800, size 0x0400, buswidth 2,
> chipwidth 2
>         #  0: 0x (0x2
> 128kB) protection state unknown
>         #  1: 0x0002 (0x2
> 128kB) protection state unknown
>         #  2: 0x0004 (0x2
> 128kB) protection state unknown
>         #  3: 0x0006 (0x2
> 128kB) protection state unknown
>         #  4: 0x0008 (0x2
> 128kB) protection state unknown
>         #  5: 0x000a (0x2
> 128kB) protection state unknown
>         #  6: 0x000c (0x2
> 128kB) protection state unknown
>         #  7: 0x000e (0x2
> 128kB) protection state unknown
>         #  8: 0x0010 (0x2
> 128kB) protection state unknown
> [...]
>         #510: 0x03fc (0x2
> 128kB) protection state unknown
>         #511: 0x03fe (0x2
> 128kB) protection state unknown
> 
> cfi information:
> 
> mfr: 0x0001, id:0x227e
> qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id:
> 0x, alt_addr: 0x
> Vcc min: 2.7, Vcc max: 3.6, Vpp min: 0.0, Vpp max: 0.0
> typ. word write timeout: 64, typ. buf write timeout: 64,
> typ. block erase timeout: 512, typ. chip erase timeout:
> 524288
> max. word write timeout: 512, max. buf write timeout: 2048,
> max. block erase timeout: 4096, max. chip erase timeout:
> 2097152
> size: 0x400, interface desc: 2, max buffer write size:
> 40
> 
> Spansion primary algorithm extend information:
> pri: 'PRI', version: 1.3
> Silicon Rev.: 0x5, Address Sensitive unlock: 0x0
> Erase Suspend: 0x2, Sector Protect: 0x1
> VppMin: 11.5, VppMax: 12.5
> 
> 
> 
> 
> 
> At 10:40 PM 9/20/2009, Rolf Meeser wrote:
> > Hi Stephan,
> > 
> > What is the exact type number of the flash device?
> > 
> > Regards,
> > Rolf
> > 
> > --- Stephan Winokur 
> schrieb am Mo, 21.9.2009:
> > 
> > > Von: Stephan Winokur 
> > > Betreff: [Openocd-development] problems with
> FASTDATA bulk write and spansion flash
> > > An: openocd-development@lists.berlios.de
> > > Datum: Montag, 21. September 2009, 4:45
> > > Hi all,
> > >
> > > I'm trying to make faster flash writes happen on
> a mips
> > > based
> > > platform -- because this is crazy: wrote 524288
> byte from
> > > file
> > > /root/flashme.bin in 45807.718750s (0.011177
> kb/s).
> > >
> > > I've downloaded the svn snapshot (2734), applied
> the
> > > "FASTDATA" bulk
> > > write optimization, and made the necessary
> changes in my
> > > target to
> > > add a working area.  (mww and mdw show me
> able to
> > > modify values, read
> > > them back, etc.)
> > >
> > > (the target line is: target create $_TARGETNAME
> mips_m4k
> > > -endian
> > > $_ENDIAN -variant ejtag_srst -chain-
> > > position $_TARGETNAME  -work-area-phys
> 0xb010
> > > -work-area-size 0x1000)
> > >
> > >
> > > When I try to write flash, I get this error:
> > >
> > > Debug: 260 36117 target.c:1108
> target_write_buffer():
> > > writing buffer
> > > of 2048 byte at 0xb0100060
> > > Debug: 261 36117 mips_m4k.c:990
> > > mips_m4k_bulk_write_memory():
> > > address: 0xb0100060, count: 0x0200
> > > Debug: 262 36117 target.c:962
> target_alloc_working_area():
> > > allocating
> > > new working area
> > > Info : 266 37460 mips32_pracc.c:858
> > > mips32_pracc_fastdata_xfer():
> > > mips32_pracc_fastdata_xfer using 0xb0100860 for
> write
> > > handler
> > >
> > > Debug: 267 37504 cfi.c:1562
> cfi_spansion_write_block():
> > > status: 0xb7fac190
> > > Error: 268 37504 flash.c:100
> flash_driver_write(): error
> > > writing to
> > > flash at address 0x4800 at offset 0x
> (-902)
> > >
> > > When I try to use load_image, I get this error:
> > >
> > >  > load_image /root/small.bin 0xb020
> > > mips32_pracc_fastdata_xfer using 0xb010 for
> write
> > > handler
> > >
> > > User : 134 6572 mips32.c:269 mips32_arch_state():
> target
> > > halted due
> > > to debug-request, pc: 0xbfc0
> > > Debug: 136 10713 command.c:68 script_debug():
> command -
> > > load_image
> > > Debug: 137 10713 command.c:77 script_debug():
> load_image -
> > >
> > > argv[0]=oc

[Openocd-development] board config script for Cogent CSB732 i.MX35 (arm1136)

2009-09-21 Thread Ethan Eade

Attached is the board config I've written for the CSB732, including 
basic clocking and SDRAM initialization.


Single stepping and burst writing work correctly.  I haven't tried flashing.

Regards,
Ethan
# The Cogent CSB732 board has a single i.MX35 chip
source [find target/imx35.cfg]

# Determined by trial and error
reset_config trst_and_srst combined
jtag_nsrst_delay 200
jtag_ntrst_delay 200

$_TARGETNAME configure -event gdb-attach { reset init }
$_TARGETNAME configure -event reset-init { csb732_init }

# Bare-bones initialization of core clocks and SDRAM
proc csb732_init { } {

# Disable fast writing only for init
memwrite burst disable

# All delay loops are omitted.
# We assume the interpreter latency is enough.

# Allow access to all coprocessors
arm11 mcr imx35.cpu 15 0 15 1 0 0x2001

# Disable MMU, caches, write buffer
arm11 mcr imx35.cpu 15 0 1 0 0 0x78

# Grant manager access to all domains
arm11 mcr imx35.cpu 15 0 3 0 0 0x

# Set ARM clock to 532 MHz, AHB to 133 MHz
mww 0x53F80004 0x1000

# Set core clock to 2 * 24 MHz * (11 + 1/12) = 532 MHz
mww 0x53F8001C 0xB2C01

set ESDMISC 0xB8001010
set ESDCFG0 0xB8001004
set ESDCTL0 0xB8001000

# Enable DDR
mww $ESDMISC 0x4

# Timing
mww $ESDCFG0 0x007fff3f

# CS0
mww $ESDCTL0 0x92120080

# Precharge all dummy write
mww 0x8400 0

# Enable CS) auto-refresh
mww $ESDCTL0 0xA2120080

# Refresh twice (dummy writes)
mww 0x8000 0
mww 0x8000 0

# Enable CS0 load mode register
mww $ESDCTL0 0xB2120080

# Dummy writes  
mwb 0x8033 0x01
mwb 0x8100 0x01

mww $ESDCTL0 0x82226080
mww 0x8000 0

# Re-enable fast writing
memwrite burst enable
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] problems with FASTDATA bulk write and spansion flash

2009-09-21 Thread Stephan Winokur

Rolf,

Yes - I'm running without defining a working area.  Unfortunately, I 
seem to be getting the sort of write speeds normally reserved for 
paper tape and acoustic couplers.  (which is why I called for help on 
this list!)

I was hoping that block write and/or fastdata would help me out.

I can use code and hack on it a bit, but I'm nowhere near able to fix 
something like this...

Thanks,

-S


At 12:02 AM 9/21/2009, Rolf Meeser wrote:
>Hi Stephan,
>
>Thanks!
>
>I just saw that you are using a MIPS processor. The 
>cfi_spansion_write_block() function supports ARM targets only. 
>Currently this executes ARM opcodes on your machine, so you can be 
>lucky that it returned at all :-)
>There is no checking the architecture yet.
>
>I believe your only choice at the moment is to not define a working 
>area (or one that has a ~300 bytes maximum). That would ensure that 
>the ARM code doesn't get executed because of low resources.
>
>Or maybe you want to fix it? :-)
>
>Regards,
>Rolf
>
>Anyone: How can I detect most efficiently that a target supports ARM code?
>
>
>
>
>--- Stephan Winokur  schrieb am Mo, 21.9.2009:
>
> > Von: Stephan Winokur 
> > Betreff: Re: AW: [Openocd-development] problems with FASTDATA 
> bulk  write and spansion flash
> > An: "Rolf Meeser" , 
> openocd-development@lists.berlios.de
> > Datum: Montag, 21. September 2009, 7:47
> > Hi Rolf,
> >
> > The device is a Spansion S29GL512P11TFI01.
> >
> > flash info 0 says:
> > > flash info 0
> > #0 : cfi at 0x4800, size 0x0400, buswidth 2,
> > chipwidth 2
> > #  0: 0x (0x2
> > 128kB) protection state unknown
> > #  1: 0x0002 (0x2
> > 128kB) protection state unknown
> > #  2: 0x0004 (0x2
> > 128kB) protection state unknown
> > #  3: 0x0006 (0x2
> > 128kB) protection state unknown
> > #  4: 0x0008 (0x2
> > 128kB) protection state unknown
> > #  5: 0x000a (0x2
> > 128kB) protection state unknown
> > #  6: 0x000c (0x2
> > 128kB) protection state unknown
> > #  7: 0x000e (0x2
> > 128kB) protection state unknown
> > #  8: 0x0010 (0x2
> > 128kB) protection state unknown
> > [...]
> > #510: 0x03fc (0x2
> > 128kB) protection state unknown
> > #511: 0x03fe (0x2
> > 128kB) protection state unknown
> >
> > cfi information:
> >
> > mfr: 0x0001, id:0x227e
> > qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id:
> > 0x, alt_addr: 0x
> > Vcc min: 2.7, Vcc max: 3.6, Vpp min: 0.0, Vpp max: 0.0
> > typ. word write timeout: 64, typ. buf write timeout: 64,
> > typ. block erase timeout: 512, typ. chip erase timeout:
> > 524288
> > max. word write timeout: 512, max. buf write timeout: 2048,
> > max. block erase timeout: 4096, max. chip erase timeout:
> > 2097152
> > size: 0x400, interface desc: 2, max buffer write size:
> > 40
> >
> > Spansion primary algorithm extend information:
> > pri: 'PRI', version: 1.3
> > Silicon Rev.: 0x5, Address Sensitive unlock: 0x0
> > Erase Suspend: 0x2, Sector Protect: 0x1
> > VppMin: 11.5, VppMax: 12.5
> >
> >
> >
> >
> >
> > At 10:40 PM 9/20/2009, Rolf Meeser wrote:
> > > Hi Stephan,
> > >
> > > What is the exact type number of the flash device?
> > >
> > > Regards,
> > > Rolf
> > >
> > > --- Stephan Winokur 
> > schrieb am Mo, 21.9.2009:
> > >
> > > > Von: Stephan Winokur 
> > > > Betreff: [Openocd-development] problems with
> > FASTDATA bulk write and spansion flash
> > > > An: openocd-development@lists.berlios.de
> > > > Datum: Montag, 21. September 2009, 4:45
> > > > Hi all,
> > > >
> > > > I'm trying to make faster flash writes happen on
> > a mips
> > > > based
> > > > platform -- because this is crazy: wrote 524288
> > byte from
> > > > file
> > > > /root/flashme.bin in 45807.718750s (0.011177
> > kb/s).
> > > >
> > > > I've downloaded the svn snapshot (2734), applied
> > the
> > > > "FASTDATA" bulk
> > > > write optimization, and made the necessary
> > changes in my
> > > > target to
> > > > add a working area.  (mww and mdw show me
> > able to
> > > > modify values, read
> > > > them back, etc.)
> > > >
> > > > (the target line is: target create $_TARGETNAME
> > mips_m4k
> > > > -endian
> > > > $_ENDIAN -variant ejtag_srst -chain-
> > > > position $_TARGETNAME  -work-area-phys
> > 0xb010
> > > > -work-area-size 0x1000)
> > > >
> > > >
> > > > When I try to write flash, I get this error:
> > > >
> > > > Debug: 260 36117 target.c:1108
> > target_write_buffer():
> > > > writing buffer
> > > > of 2048 byte at 0xb0100060
> > > > Debug: 261 36117 mips_m4k.c:990
> > > > mips_m4k_bulk_write_memory():
> > > > address: 0xb0100060, count: 0x0200
> > > > Debug: 262 36117 target.c:962
> > target_alloc_working_area():
> > > > allocating
> > > > new working area
> > > > Info : 266 37460 mips32_pracc.c:858
> > > > mips32_pracc_fastdata_xfer():
> > > > mips32_pracc_fastdata_xfer using 0xb0100860 for
> > write
> > > > handler
> > > >
> > >

Re: [Openocd-development] A few thoughts on OpenOCD long term goals

2009-09-21 Thread Nico Coesel

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe
> Sent: zondag 20 september 2009 19:53
> To: openocd-development@lists.berlios.de
> Subject: [Openocd-development] A few thoughts on OpenOCD long term goals
> 
> One of my goals w/OpenOCD is that it becomes yet another
> thing that hardware vendors have to "check off" on the
> GCC toolchain list. Not having OpenOCD support should
> be like not having GDB support.
> 
> This is a long way off, but it's something to aspire to.

Just keep pushing. We are looking for a SoC for a new platform and we are 
basically saying that only devices with OpenOCD support are considered.
 
> It would be nice to have support for other targets than ARM,
> and we're doing well w/MIPS, but we really need a significantly
> bigger community or direct support from hardware vendors
> (the gorillas get things for free, the chimps don't...) to
> boast equally broad MIPS support as ARM support. Either
> that or ARM support has to reach a point of maturity where
> MIPS can start to catch up. Then again ARM is messier

I don't know if MIPS is something to give much concern. IMHO MIPS is a dead 
platform unless the PIC32 is catching on which is unlikely since ARM devices 
are way ahead. Freescale's Coldfire would be much more interesting. I know 
Freescale is having a very hard time selling the Coldfire due to lack of Open 
Source tools support. The price of the devices is right, but the tooling is not.

> Eventually I hope that we'll be able to identify some killer
> features that closed source solutions just don't offer and
> that it will become uneconomical to implement from scratch
> for each JTAG debugger. I don't really know what those
> features might be though. Some ideas:

> - Threads support(e.g. eCos, FreeRTOS, etc. threads)
> - Profiling support(??) there is profiling support in OpenOCD
> now, but I haven't heard about anyone using it.
> - Connect up to other GPL code. We're already connected
> to GDB as much as we should be... What else?
> - Killer FPGA soft CPU workflow support(not quite sure
> what that means yet :-)

I think the best feature is that it just works. A lot of software does not have 
that feature!

Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd 0.3.0 + GDB + ECLIPSE not working

2009-09-21 Thread Jiří Kubias

To Laurent Gauch: Did you received my private email?

Jiri Kubias

2009/9/17 Laurent Gauch 

> Hi Jir(í Kubias,
>
> Good to know you resolved your problem using GDB / OpenOCD / Amontec
> JTAGkey-2 for your lpc2378 board.
> Also, thank you for giving the how you have resolved the issue. It is nice
> for other users.
>
> (By the way, I double checked our Amontec email box, but I did not find any
> email from you regarding driver troubles.)
> Actually, we did not have published the new driver, since we are doing
> Microsoft certification for our new driver. For now, Amontec Team gives the
> new driver on demand. But we will updated Amontec JTAGkey Dongle Drivers
> tomorrow (uncertified one). Please check tomorrow http://www.amontec.com .
> The certified one (VISTA 64 bits) should come in the next 2 weeks.
>
> Regards,
> Laurent Gauch
> http://www.amontec.com
>
> Jir(í Kubias wrote:
>
>> Hi,
>> I thought that this email didn't reach opnocd mailing list (I didnt
>> recieve copy from mailing list). I solved my problem yesterday - the main
>> problem was missconfigured GDB (it was configured only for i686-linux
>> platform and not for arm-elf  The second was enabled code compression -
>> eclipse didn't survive this. Well now it works fine.
>>
>> I have troubles with the drivers provided on amontec web page - the
>> windows driver is quied old (DriverVer=12/01/2005, taken from FTD2XX.inf),
>> in linux I have the same problems so Im using the second driver usblib for
>> ftdi chips. I reported this problem to amontec - but no response.
>>
>> Jirka
>>
>>
>>
>> 2009/9/17 Laurent Gauch > laurent.ga...@amontec.com>>
>>
>>>
>>> Hi,
>>> Im newbie to debugging under linux at all. Im tying to make work
>>openocd
>>> 0.3.0 + jtagkey2 + gdb + eclipse working. However Im not
>>sucessfull. I
>>> found several problems:
>>>
>>> 1) Maybe this is not problem, but when i open opencd with
>>jkagkey script and
>>> lpc2378 (im using lpc2364 - config is wery similar) I get this
>>output
>>> Error: EmbeddedICE v7 handling might be broken
>>> but everything seems that is working
>>>
>>> 2) but when i use eclipse with CDT pluguin from Zylin and
>>configure GDB with
>>> this init command;
>>> target remote localhost:
>>> set mem inaccessible-by-default off
>>> monitor halt
>>> monitor arm7_9 dcc_downloads enable
>>> monitor gdb_breakpoint_override hard
>>> monitor arm7_9 fast_memory_access enable
>>> monitor wait_halt
>>> break main
>>> continue
>>>
>>> It always fails see this log from openocd
>>>
>>> Open On-Chip Debugger 0.3.0-in-development (2009-09-16-11:44)
>>svn:2714
>>> $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c
>> $
>>> For bug reports, read
>>http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>>> jtag_nsrst_delay: 200
>>> jtag_ntrst_delay: 200
>>> Warn : use 'lpc2378.cpu' as target identifier, not '0'
>>> 500 kHz
>>> Info : max TCK change to: 3 kHz
>>> Info : clock speed 500 kHz
>>> Info : JTAG tap: lpc2378.cpu tap/device found: 0x4f1f0f0f (mfg:
>>0x787, part:
>>> 0xf1f0, ver: 0x4)
>>> Error: EmbeddedICE v7 handling might be broken
>>> target state: halted
>>> target halted in ARM state due to breakpoint, current mode:
>>Supervisor
>>> cpsr: 0x2013 pc: 0x0238
>>> Info : accepting 'gdb' connection from 0
>>> Warn : acknowledgment received, but no packet pending
>>> Warn : memory read caused data abort (address: 0x0800, size:
>>0x4, count:
>>> 0x2)
>>> Warn : memory read caused data abort (address: 0x0800, size:
>>0x4, count:
>>> 0x1)
>>> dcc downloads are enabled
>>> force hard breakpoints
>>> fast memory access is enabled
>>> Info : dropped 'gdb' connection - error -400
>>>
>>> the log from eclipse
>>>
>>> source .gdbinit
>>> target remote localhost:
>>> 0x0800 in ?? ()
>>> set mem inaccessible-by-default off
>>> monitor halt
>>> monitor arm7_9 dcc_downloads enable
>>> dcc downloads are enabled
>>> monitor gdb_breakpoint_override hard
>>> force hard breakpoints
>>> monitor arm7_9 fast_memory_access enable
>>> fast memory access is enabled
>>> monitor wait_halt
>>> break main
>>> Breakpoint 1 at 0x64c: file
>>> /home/data/robot/eurobot/sysless-lpc21xx/app/test222/main.c,
>>line 141.
>>> Note: automatically using hardware breakpoints for read-only
>>addresses.
>>> continue
>>>
>>> So please help me. Im not sure if is not somethig wrong with
>>eclipse, but is
>>> wery hard to find wiking exaple for Amontec Jtagkey2 , the
>>lastest openocd
>>> and eclipse.
>>>
>>> OpenOCD - 0.3.0 svn build: 2741
>>> Eclipse 3.4.1
>>> GDB 6.8
>>> system Gentoo
>>>
>>> J

Re: [Openocd-development] A few thoughts on OpenOCD long term goals

2009-09-21 Thread Jiří Kubias

Hi,
because I'm particularly newbie in Linux debugging, I have another view than
you. Im trying to run jtag + openocd + gdb + something (Eclipse) to run, and
there is several another problems than openocd which needs to be solved.
Jtag + openocd + gdb runs perfectly (if you find your jtag and chip in /
scripts) - but Im missing here some simple how-to for beginners which will
be on 20 lines max. something like: Find your jtag key in /scripts/...  and
find your chip in /scripts/...  try to run:   openocd -f your_jtag.cfg
-f your_chip.cfg if you see something like this ... than everything is
ok. Well make openocd to work takes me cca 1/2 day work (currently release
dont support jtagkey2 ...).   Another problem is to make it work with some
IDE. Plain GDB is for hardcore programmers. Im trying to configure Eclipse
to be cool with ARM debugging - but im not eclipse guru and Im experiencing
problems with breakpoint limiting (only two for HW breakpoint in LPC23xx)
and viewing SFR registers  Well openocd + jtag + eclipse takes me more
than one day  and it is not working in the way how i need it...For
you it is probably easy for setup GDB scripts (will be cool to publish some
with open ocd), but for beginners it is uncovered area. However tis is not
directly belong to openocd project, but in future plans it may be
considered.

Jirka

2009/9/20 Øyvind Harboe 

> One of my goals w/OpenOCD is that it becomes yet another
> thing that hardware vendors have to "check off" on the
> GCC toolchain list. Not having OpenOCD support should
> be like not having GDB support.
>
> This is a long way off, but it's something to aspire to.
>
> Short term(a year or so), I'd like to see robustness for
> the ARM target *much* improved and the target library
> become increasingly support more targets and support
> them better. OpenOCD should be the best and cheapest
> alternative (in terms of engineering & marketing effort) for
> ARM chip vendors. I'm not concerned about hardware cost
> to developers, because putting an ft2232 on an eval
> board costs $1, it doesn't get any cheaper...
>
> It would be nice to have support for other targets than ARM,
> and we're doing well w/MIPS, but we really need a significantly
> bigger community or direct support from hardware vendors
> (the gorillas get things for free, the chimps don't...) to
> boast equally broad MIPS support as ARM support. Either
> that or ARM support has to reach a point of maturity where
> MIPS can start to catch up. Then again ARM is messier
> than MIPS. PowerPC is hard because OpenOCD does not
> have the leverage to pry open the NDAs that shroud the
> PowerPC architecture so that gets to be a pain with open
> source development.
>
> In terms of getting levarage with smaller chip vendors,
> I believe http://www.vinchip.com is a case in point, but
> I have no idea if their 32 bit risc is just another ARM
> or whether it's something proprietary(didn't really look).
>
> Eventually I hope that we'll be able to identify some killer
> features that closed source solutions just don't offer and
> that it will become uneconomical to implement from scratch
> for each JTAG debugger. I don't really know what those
> features might be though. Some ideas:
>
> - Threads support(e.g. eCos, FreeRTOS, etc. threads)
> - Profiling support(??) there is profiling support in OpenOCD
> now, but I haven't heard about anyone using it.
> - Connect up to other GPL code. We're already connected
> to GDB as much as we should be... What else?
> - Killer FPGA soft CPU workflow support(not quite sure
> what that means yet :-)
>
> --
> Ø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
>



-- 
===
Bc. Jiri Kubias
Czech Technical University in Prague
Faculty of Electrical Engineering
dept. of Control Engineering
Karlovo namesti 13/E, 121 35 Prague
Czech Republic

web page: http://dce.felk.cvut.cz
e-mail: jiri.kub...@gmail.com
mobile: 777 974167
===
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] A few thoughts on OpenOCD long term goals

2009-09-21 Thread Øyvind Harboe

I've heard this concern many times, but I guess at the end of the
day experienced embedded engineers have an edge

Embedded development *is* quite involved... Also tools are
quite rough around the edges because any particular MCU
has a very narrow audience.

There are *literally* 1 different MCUs out there(when you
count all the parts and packagings).

When you pile the # of different PCBs that exist on top of those
1 MCU parts, then you can understand that the effort
into tools and support for each PCB gets *very* diluted.



-- 
Ø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] A few thoughts on OpenOCD long term goals

2009-09-21 Thread Nico Coesel

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe
> Sent: maandag 21 september 2009 11:28
> To: Jiří Kubias
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] A few thoughts on OpenOCD long term goals
> 
> I've heard this concern many times, but I guess at the end of the
> day experienced embedded engineers have an edge
> 
> Embedded development *is* quite involved... Also tools are
> quite rough around the edges because any particular MCU
> has a very narrow audience.

True. I always tell people not to debug on embedded targets but test the 
software on a PC first. A PC will always have superior debugging and functional 
verification facilities.

Nico Coesel

___
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

2009-09-21 Thread Petri Pirttinen

 > BTW I have also attached a reset-init script that not only does a
 > soft_reset_halt and vector table remap, but also disables MAM and PLL
 > after reset - without that two steps I experienced really crazy
 > behaviour in a very simple and correct code while debugging.

This is a little bit same what we have done recently in here. I have 
never figured out how these scripts could have worked "out of box" for 
anyone unless using internal RC oscillator as the only clock source 
Without dealing with this things went crooked from time to time.

What we actually did was making another procedure function called 
"activateInternalOsc" to target script that basically does the same 
things described here previously; disabling PLL, switching to internal 
RC oscillator, etc. Most importantly: putting the target device into 
/known/ state. This way we didn't have to worry about what crystal or 
PLL settings the device is used with. This function is called from 
reset-init event.

We also made another procedure function called "writeToInternalFlash" 
that can be evoked when we want to use OOCD just to program the FLASH 
memory. One of the first things this function does is calling the 
"activateInternalOsc", again to bring the device into known state and 
then perform what is necessary for flash programming.

> - JTAG_FREQ - CRYSTAL_FREQ / 8 works for me all the times, but 
> CRYSTAL_FREQ / 6 - not (in the .tcl file I divide by 8 now)

Agreed. Divided by 8 seems to be a more stable option in here as well.
___
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

2009-09-21 Thread Petri Pirttinen

>>> Why are you doing a soft_reset_halt?
>> Why not?
>>
>> If this command is forbidden / wrong / whatever - remove it. If it's not,
>> why do you care if I use it? Without that command it does not work. Or maybe
>> I just don't understand the meaning of "reset init"? For me that is "do a
>> reset, init everything that should be initialized". If that's not the case,
>> then the name should be changed, as it's misleading.
> 
> I asked because I recently removed soft_reset_halt from
> lpc2478.cfg because it made things fail.
> 
> I have no idea *why* it fails, so I hoped that you could
> shed light on that problem.

We have fiddled so much with the config files in here that I lost track 
of affects long time ago. But in our current script we use 
soft_rest_halt as well (while using LPC23xx series, I'm not sure if we 
have tried it out with LPC2478 - we do have board for this as well). 
Bottom line is that it works for us - I don't know about other people or 
even less why it works without.


Now following is just flow of mind thus may include major errors but 
hopefully will arise some conversation.

What is the purpose of reset-init event? In my opinion it is where we 
want to get things back to the beginning. Performing system reset may 
reset other hardware on target board as well and may cause some major 
trouble while debugging. I don't like doing this anyway as it causes the 
EmbeddedICE logic to reset as well and OOCD to lose control for a moment.

Soft reset makes a "fake" reset by altering the program counter, leaving 
the hardware to probably steady yet unknown state. This is why we need 
additional steps to configure some peripherals or clock source to fixed, 
known state as discussed before. Then we let the embedded software to 
handle rest of the initializations - just like if it was coming out from 
any ordinary reset.

 From what I have experienced, soft_reset_halt is a safe way of reseting 
the system. Then again the problems we have had, may all be just our own 
fooling with the OOCD and that utterance may not be true. OOCD isn't one 
of the easiest choices for debugging on the market.

Regards,
Petri
___
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

2009-09-21 Thread Øyvind Harboe

> What is the purpose of reset-init event?

"reset init"  puts a target that is reset into the halted state,
into a state where gdb load, flash programming, etc. will work.

I.e. that the target is ready to be debugged or programmed.

the reset-init event is the most straightforward way to implement
the "reset init" contract.

-- 
Ø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] 0.3 anyone?

2009-09-21 Thread Øyvind Harboe

0.3 anyone?

There's lots of good progress since 0.2.

Does anyone have a bunch of stuff that will be completed in the near future?




-- 
Ø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] 0.3 anyone?

2009-09-21 Thread Freddie Chopin

Øyvind Harboe pisze:
> Does anyone have a bunch of stuff that will be completed in the near future?

How about that new LPC2xxx cfg files layout?

With a bit of investigation the "reset init" should be working, or that 
can be left for future, as now this script is not fully functional either...

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

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Petri Pirttinen wrote:
> What is the purpose of reset-init event? In my opinion it is where we 
> want to get things back to the beginning.

A "reset halt" is intended to reset and cause a halt before
execution of the first post-reset instruction.  That's "back
to the beginning", if you will.

A "reset init" is the same as a "reset halt" *EXCEPT* that
it also runs a Tcl "reset-init" event handler.

Re what the "reset-init" handler should do ... lowlevel
setup for the board.  On most ARM9 class chips it would
be doing what the boot loader does:  set up clocks and
PLL, switch core to PLL-based clocking, set up external
SDRAM or DDR2, probe flash chips, and more.

> Performing system reset may  
> reset other hardware on target board as well and may cause some major 
> trouble while debugging. I don't like doing this anyway as it causes the 
> EmbeddedICE logic to reset as well and OOCD to lose control for a moment.

That seems like a different issue.  I agree that it would be
good to avoid issuing SRST ... that's a general limitation of
the current OOCD reset framework, that it uses SRST (and for
that matter TRST!) way too readily, *AND* doesn't have good
alternatives (yet).

Resetting the EmbeddedICE logic ... I don't believe that's
a general characteristic of SRST on ARMs.  Though it does
sound like it's true on LPC2xxx chips.  (Example, ARM920 and
ARM926 boards I have here could not implement "reset halt"
if SRST covered the EmbeddedICE.  The "halt" mechanism uses
the vector catch hardware to trap right after reset.)

Like my current pet peeve:  how to get OpenOCD to reboot a
system which doesn't have SRST wired.  After I finish
chasing down the current set of problems, I'll do something
about that.

- Dave

___
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

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Petri Pirttinen wrote:
> > - JTAG_FREQ - CRYSTAL_FREQ / 8 works for me all the times, but 
> > CRYSTAL_FREQ / 6 - not (in the .tcl file I divide by 8 now)
> 
> Agreed. Divided by 8 seems to be a more stable option in here as well.

div/6 is *ABSOLUTE BEST CASE* that more or less requires the
JTAG frequency to be derived from the core oscillator... see

  http://www.arm.com/support/faqdev/4170.html

for a picture of equivalent logic.  I would not expect to see
that rate work in many systems; the clocks aren't synchronized
well enough.

Heck ... div/8 often doesn't work well either!

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] 0.3 anyone?

2009-09-21 Thread Rolf Meeser

Hi,

I had problems with the "reset init" on LPC2478, too. I didn't analyze it 
deeply, but I noticed this problem:

OpenOCD reported that it couldn't halt the target. With debug on, I got the 
impression that the EmbeddedICE had been programmed for a break before the 
final SRST/TRST happened. There was an attempt to reprogram it afterwards, but 
that didn't seem to be complete.

I've added a call to jtag_add_tlr(), and that solved it for me.
All relevant EmbeddedICE registers are now reprogrammed.

It looks like there's some internal state which didn't notice that the target 
hardware got a reset. Seems reasonable to me to have the TAP reset call here, 
but I'm not an expert...

Regards,
Rolf


Index: src/target/arm7_9_common.c
===
--- src/target/arm7_9_common.c  (revision 2731)
+++ src/target/arm7_9_common.c  (working copy)
@@ -1105,6 +1105,9 @@
if (target->reset_halt && (jtag_reset_config & RESET_SRST_PULLS_TRST) 
!= 0)
{
LOG_WARNING("srst pulls trst - can not reset into halted mode. 
Issuing halt after reset.");
+
+   jtag_add_tlr();
+
/* set up embedded ice registers again */
if ((retval = target_examine_one(target)) != ERROR_OK)
return retval;



--- Freddie Chopin  schrieb am Mo, 21.9.2009:

> Von: Freddie Chopin 
> Betreff: Re: [Openocd-development] 0.3 anyone?
> An: "Øyvind Harboe" 
> CC: openocd-development@lists.berlios.de
> Datum: Montag, 21. September 2009, 19:04
> Øyvind Harboe pisze:
> > Does anyone have a bunch of stuff that will be
> completed in the near future?
> 
> How about that new LPC2xxx cfg files layout?
> 
> With a bit of investigation the "reset init" should be
> working, or that 
> can be left for future, as now this script is not fully
> functional either...
> 
> 4\/3!!
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
> 


  
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] 0.3 anyone?

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Øyvind Harboe wrote:
> 0.3 anyone?
> 
> There's lots of good progress since 0.2.
> 
> Does anyone have a bunch of stuff that will be completed in the near future?

Yeah, I was going to comment on this ...

I'm chasing down stuff to make sure that new JTAG event behaves
for automatic activation of ARM taps.  I want that to be in 0.3
so we're certain that mechanism is functionally complete.  Related
to that are some doc updates and minor patches.

Everything else I've got is more minor; or not quite started yet.

If we have time, I've got an idea for how to easily handle the
"board doesn't have SRST" reset cases.  That will help Beagle,
just like that automatic activation ... making 0.3 a solid base
for folk wanting a BeagleBoard.org-ready debugger.

How about we aim to get remaining significant updates in by Friday,
and use next week as the first all-bugfixes QA cycle?  This week
could, for most folk, be a primarily-bugfixing cycle.  Test the code
on your boards, report and resolve the bugs...

- Dave
___
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

2009-09-21 Thread David Brownell

On Saturday 19 September 2009, Freddie Chopin wrote:
> I don't know how should the GDB initialization commands look like:
> 
> monitor reset init
> load
> (let's call that "v1")

That should work.  If it doesn't, there's a bug lurking somewhere.

> or maybe:
> 
> monitor reset halt
> monitor reset init
> load
> (let's call that "v2")

"reset init" is "reset halt" plus execution of the "reset-init"
event handler.  So if v2 behavior *differs* in any way from v1
behaviour, this is a bug ... doing "reset halt" twice should be
exactly equivalent to doing it once.

- Dave

___
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

2009-09-21 Thread David Brownell

On Saturday 19 September 2009, Freddie Chopin wrote:
> 1. When there is "soft_reset_halt" in the script:
> 
> v1 fails - target not halted
> v1 (without load) - works
> v2 fails - target not halted
> v2 (without load) - works
> 
> But: When I want to load I have to do:
> 
> monitor reset halt
> load
> monitor reset init
> 
> or:
> 
> monitor reset init
> monitor reset halt
> load
> 
> And this way it works

Sounds like the "soft_reset_halt" doesn't belong, then,
especially given (2) below:

> 2. When there is no soft_reset_halt in the script:
> 
> v1 works
> v1 (without load) fails / works wrong
> v2 works
> v2 (without load) works wrong

... except for those "without load" cases.

> 3. When there is "armv4_5 core_state arm" instead of soft_reset_halt:
> 
> v1 works
> v1 (without load) works wrong
> v2 works
> v2 (without load) works wrong
> 
> For 2. and 3. cases that fail, I need to manually add soft_reset_halt in 
> the gdb init command for things to work.
> 
> Generally most of the time monitor reset halt + monitor soft_reset_halt 
> alone works fine, but sometimes enabled MAM and PLL make things go crazy...

Normally a "reset halt" should have caused MAM and PLL to
enter their just-after-hard-reset hardware default states ...

Are you saying those hardware default states cause problems?
If so, that seems buggy.  I'm not sure where the issue would
lie, but it's hard to imagine the chips could boot properly
if the hardware defaults didn't work ...

> This would be pretty cool to just use lpc2xxx like stm32: monitor reset 
> halt (+ load) and that's all.

I think the fact that it doesn't work reflects a bug.  But I
don't know those LPC chips, or thus where the bug would be.

> That's doesn't have to be "-halt" but  
> having "reset init" do all the job would be great, as now that's a 
> lottery and shooting in the dark.

On a microcontroller -- ARM7TDMI plus flash -- I would expect
that if the 'reset-init' script just probed the flash chips
that should suffice.  Do one "reset init" and from  then on
the "reset halt" *SHOULD* be enough.

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Query on FT4232H support

2009-09-21 Thread Austin, Alex

Hello,
My company is developing a JTAG debugger for internal use. We expect to start 
using it within a week or so, though there are other capability requests that 
would make use of the FT4232H advantageous.

Can we rely on the ft4232h today, or should we place a pair of ft2232Ls and a 
USB hub for now?

Thank you,

-  Alex
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] FYI -- flakey reset scenario

2009-09-21 Thread David Brownell

Just recording this in case other folk see it and wonder
what's going on ... or have suggestions about how to handle
such things better:

Environment:
ft2232d based JTAG adapter
OpenOCD 0.3-dev
arm926, running Linux
*NO BOOT LOADER ACCESSIBLE* (booted via OpenOCD)
JTAG clock at max (6 MHz)

Action:
in Linux, "reboot"

Result:
background polling starts to spew error messages

Recover by:
"reset halt"

What happened:
System reset triggered reinit from scratch
"from scratch" means on-chip ROM boot loader
ROM boot loader doesn't set up system clocks and PLLs
JTAG clock is thus 4x faster than what can work
background polling ("poll on") feeds garbage to EmbeddedICE

Current best workarounds:
set up to use worst-case JTAG clock before reboot (sigh)
use adaptive clocking (not possible with this adapter)

___
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

2009-09-21 Thread Freddie Chopin

David Brownell pisze:
> Normally a "reset halt" should have caused MAM and PLL to
> enter their just-after-hard-reset hardware default states ...
> 
> Are you saying those hardware default states cause problems?
> If so, that seems buggy.  I'm not sure where the issue would
> lie, but it's hard to imagine the chips could boot properly
> if the hardware defaults didn't work ...

Well, all LPC2xxx chips are "srst_pulls_trst" - that's the first thing. 
Moreover - due to internal bootloader operation there is some delay 
between de-asserting reset and activating the JTAG interface (this is 
some protection mechanism). That's why on LPC2xxx "reset halt" does:
1. reset
2. wait a while
3. halt
4. do a soft_reset_halt

during 2. there is enough time for the core to execute A LOT of 
instructions, like enabling MAM and PLL, which DO cause trouble whan you 
expect them to be disabled.

I haven't investigated that much, but I thing there is some hidden bug 
in soft_reset_halt, that makes programming (via gdb's "load") fail with 
"target not halted" (and yet - just before the "load" a "poll" command 
shows, that the core is halted /; )

> I think the fact that it doesn't work reflects a bug.  But I
> don't know those LPC chips, or thus where the bug would be.

That's a silicon limitation of LPC chips... For example in CrossWorks 
this is overcome by injection a startup with a "forever loop" that is 
later skipped by the debugger - this way at the start of the debugging 
session the chip is in good state. Unfortunately something like this 
cannot be implemented without build-tools integration /; Or maybe I'm wrong?

One way could be to implement some king of hardware reset (maybe via 
Watchdog?), the other - to halt the execution in some infinite loop...

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] 0.3 anyone?

2009-09-21 Thread Øyvind Harboe

On Mon, Sep 21, 2009 at 7:04 PM, Freddie Chopin  wrote:
> Øyvind Harboe pisze:
>>
>> Does anyone have a bunch of stuff that will be completed in the near
>> future?
>
> How about that new LPC2xxx cfg files layout?
>
> With a bit of investigation the "reset init" should be working, or that can
> be left for future, as now this script is not fully functional either...

When it's ready it should be committed, but I think this is one
thing that either is ready by the time we cut 0.3 or not, we don't
push out 0.3 for these changes.


-- 
Ø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] 0.3 anyone?

2009-09-21 Thread Freddie Chopin

Rolf Meeser pisze:
> I had problems with the "reset init" on LPC2478, too. I didn't analyze it 
> deeply, but I noticed this problem:
> 
> OpenOCD reported that it couldn't halt the target. With debug on, I got the 
> impression that the EmbeddedICE had been programmed for a break before the 
> final SRST/TRST happened. There was an attempt to reprogram it afterwards, 
> but that didn't seem to be complete.
> 
> I've added a call to jtag_add_tlr(), and that solved it for me.
> All relevant EmbeddedICE registers are now reprogrammed.
> 
> It looks like there's some internal state which didn't notice that the target 
> hardware got a reset. Seems reasonable to me to have the TAP reset call here, 
> but I'm not an expert...

Unfortunately your patch doesn't solve my general problem:

- with "soft_reset_halt" before "load" programming fails
- without "soft_reset_halt" when there is no "load" debugging works wrong

/;

That's why I prefer STM32 now <:

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] 0.3 anyone?

2009-09-21 Thread Freddie Chopin

Øyvind Harboe pisze:
> When it's ready it should be committed, but I think this is one
> thing that either is ready by the time we cut 0.3 or not, we don't
> push out 0.3 for these changes.

For me, the main cfg files layout is ready, I can make a patch even 
today. I'm just waiting for the opinions and a "go" sign. The reset-init 
script IMHO is a separate issue, which should be investigated further.


4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Change in GDB handling of halted/running state

2009-09-21 Thread Øyvind Harboe

I'm wondering if it would be a good idea to modify the handling
of GDB halted/running state as follows:

- do nothing upon attaching GDB to OpenOCD. This gives
the GDB init script more freedom w.r.t. what should happen
when connecting to the target.
- if the target is running and GDB is halted, then OpenOCD
returns "white lies" in the register and memory queries. This
allows users to issue a "monitor halt" or "stepi/continue" command
after attaching to either halt the target or sync up with it.
- When connecting to a halted target, the next stepi/continue
returns immediately, thus allowing the register state to sync
up to the current state of the target without modifying the
state of the target
- if, while GDB is halted, the target state changes behind
GDBs back, then the  next stepi/continue returns immediately
to sync up GDB to the current state


-- 
Ø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] new lpc2xxx cfg files layout

2009-09-21 Thread Jiří Kubias

Hi,
Im using LPC2364 with modified sample target/lpc2378.cfg with
interface/jtagkey2.cfg  and with modification reset_config none (I dont have
connected reset to JTAG). My GDB flash init is:

target remote localhost:
monitor soft_reset_halt
monitor gdb_breakpoint_override hard
d
b main
c


And I dont find out any strange behaviour. But there is several
recommendations which you must take in care.
1) In setup PLL you must check if PLL is connected or if is locked -> if yes
you must disconnect it!!! If you dint check it, it should produce some
errors during setup JTAG interface. Im dont know why but this part is often
missing in published  code...
2) if you are using JTAG is highly recommended to add long busy wait before
startup routine is called. (Im using cca 0.5 sec dummy wait)

The JTAG start routine runs processor for a while -> it runs application
code.

Jirka




2009/9/21 Freddie Chopin 

> David Brownell pisze:
> > Normally a "reset halt" should have caused MAM and PLL to
> > enter their just-after-hard-reset hardware default states ...
> >
> > Are you saying those hardware default states cause problems?
> > If so, that seems buggy.  I'm not sure where the issue would
> > lie, but it's hard to imagine the chips could boot properly
> > if the hardware defaults didn't work ...
>
> Well, all LPC2xxx chips are "srst_pulls_trst" - that's the first thing.
> Moreover - due to internal bootloader operation there is some delay
> between de-asserting reset and activating the JTAG interface (this is
> some protection mechanism). That's why on LPC2xxx "reset halt" does:
> 1. reset
> 2. wait a while
> 3. halt
> 4. do a soft_reset_halt
>
> during 2. there is enough time for the core to execute A LOT of
> instructions, like enabling MAM and PLL, which DO cause trouble whan you
> expect them to be disabled.
>
> I haven't investigated that much, but I thing there is some hidden bug
> in soft_reset_halt, that makes programming (via gdb's "load") fail with
> "target not halted" (and yet - just before the "load" a "poll" command
> shows, that the core is halted /; )
>
> > I think the fact that it doesn't work reflects a bug.  But I
> > don't know those LPC chips, or thus where the bug would be.
>
> That's a silicon limitation of LPC chips... For example in CrossWorks
> this is overcome by injection a startup with a "forever loop" that is
> later skipped by the debugger - this way at the start of the debugging
> session the chip is in good state. Unfortunately something like this
> cannot be implemented without build-tools integration /; Or maybe I'm
> wrong?
>
> One way could be to implement some king of hardware reset (maybe via
> Watchdog?), the other - to halt the execution in some infinite loop...
>
> 4\/3!!
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>



-- 
===
Bc. Jiri Kubias
Czech Technical University in Prague
Faculty of Electrical Engineering
dept. of Control Engineering
Karlovo namesti 13/E, 121 35 Prague
Czech Republic

web page: http://dce.felk.cvut.cz
e-mail: jiri.kub...@gmail.com
mobile: 777 974167
===
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase

2009-09-21 Thread Johnny Halfmoon


David Brownell wrote:
> On Sunday 20 September 2009, Johnny Halfmoon wrote:
>> +   if ((retval = flash_check_sector_parameters(cmd_ctx, first, 
>> last, p->num_sectors)) !
> 
> I had in mind more like
> 
>   uint32_t value; 


Okay. Like this then:


= = = = = = = = = = = =


 doc/openocd.texi  |6 ++-
 src/flash/flash.c |   97 +++---
 2 files changed, 67 insertions(+), 36 deletions(-)

Index: src/flash/flash.c
===
--- src/flash/flash.c   (revision 2736)
+++ src/flash/flash.c   (working copy)
@@ -559,40 +559,62 @@
return ERROR_OK;
 }
 
+int flash_check_sector_parameters(struct command_context_s *cmd_ctx, uint32_t 
first, uint32_t last, uint num_sectors)
+{
+   if ( first >= last ) {
+   command_print(cmd_ctx, "ERROR: last sector must be > first 
sector");
+   return ERROR_FAIL;
+   }
+
+   if ( last > (num_sectors - 1)) {
+   command_print(cmd_ctx, "ERROR: last sector must be =< %d", 
num_sectors - 1);
+   return ERROR_FAIL;
+   }
+
+   return ERROR_OK;
+}
+
 static int handle_flash_erase_command(struct command_context_s *cmd_ctx, char 
*cmd, char **args, int argc)
 {
if (argc > 2)
{
-   int first = strtoul(args[1], NULL, 0);
-   int last = strtoul(args[2], NULL, 0);
+   uint32_t bank_nr;
+   uint32_t first;
+   uint32_t last;
int retval;
-   flash_bank_t *p = get_flash_bank_by_num(strtoul(args[0], NULL, 
0));
+
+   if ((retval = parse_u32(args[0], &bank_nr)) != ERROR_OK)
+   return retval;
+
+   flash_bank_t *p = get_flash_bank_by_num(bank_nr);
+   if (!p)
+   return ERROR_OK;
+
+   if ((retval = parse_u32(args[1], &first)) != ERROR_OK)
+   return retval;
+   if (strcmp(args[2], "last") == 0)
+   last = p->num_sectors - 1;
+   else
+   if ((retval = parse_u32(args[2], &last)) != ERROR_OK)
+   return retval;
+
+   if ((retval = flash_check_sector_parameters(cmd_ctx, first, 
last, p->num_sectors)) != ERROR_OK)
+   return retval;
+
duration_t duration;
char *duration_text;
-
duration_start_measure(&duration);
 
-   if (!p)
-   {
-   return ERROR_COMMAND_SYNTAX_ERROR;
-   }
-
-   if ((retval = flash_driver_erase(p, first, last)) == ERROR_OK)
-   {
+   if ((retval = flash_driver_erase(p, first, last)) == ERROR_OK) {
if ((retval = duration_stop_measure(&duration, 
&duration_text)) != ERROR_OK)
-   {
return retval;
-   }
-
-   command_print(cmd_ctx, "erased sectors %i through %i on 
flash bank %li in %s",
-   first, last, strtoul(args[0], 0, 0), 
duration_text);
+   command_print(cmd_ctx, "erased sectors %i through %i on 
flash bank %i in %s",
+   first, last, bank_nr, duration_text);
free(duration_text);
}
}
else
-   {
return ERROR_COMMAND_SYNTAX_ERROR;
-   }
 
return ERROR_OK;
 }
@@ -601,40 +623,47 @@
 {
if (argc > 3)
{
-   int first = strtoul(args[1], NULL, 0);
-   int last = strtoul(args[2], NULL, 0);
+   uint32_t bank_nr;
+   uint32_t first;
+   uint32_t last;
+   int retval;
int set;
-   int retval;
-   flash_bank_t *p = get_flash_bank_by_num(strtoul(args[0], NULL, 
0));
+
+   if ((retval = parse_u32(args[0], &bank_nr)) != ERROR_OK)
+   return retval;
+
+   flash_bank_t *p = get_flash_bank_by_num(bank_nr);
if (!p)
-   {
-   command_print(cmd_ctx, "flash bank '#%s' is out of 
bounds", args[0]);
return ERROR_OK;
-   }
 
+   if ((retval = parse_u32(args[1], &first)) != ERROR_OK)
+   return retval;
+   if (strcmp(args[2], "last") == 0)
+   last = p->num_sectors - 1;
+   else
+   if ((retval = parse_u32(args[2], &last)) != ERROR_OK)
+   return retval;
+
if (strcmp(args[3], "on") == 0)
set = 1;
else if (strcmp(args[3], "off") == 0)
set = 0;
else
-   {
return ERROR_

Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase

2009-09-21 Thread Rolf Meeser

Hi Johnny,

it should be 
> +if ( first > last ) {
not
> +if ( first >= last ) {

With first=last you can erase a single sector.

Regards,
Rolf


--- Johnny Halfmoon  schrieb am Mo, 21.9.2009:

> Von: Johnny Halfmoon 
> Betreff: Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last 
> sector for protection and erase
> An: "David Brownell" 
> CC: openocd-development@lists.berlios.de
> Datum: Montag, 21. September 2009, 21:33
> 
> David Brownell wrote:
> > On Sunday 20 September 2009, Johnny Halfmoon wrote:
> >> +           
>    if ((retval =
> flash_check_sector_parameters(cmd_ctx, first, last,
> p->num_sectors)) !
> > 
> > I had in mind more like
> > 
> >     uint32_t value; 
> 
> 
> Okay. Like this then:
> 
> 
> = = = = = = = = = = = =
> 
> 
>  doc/openocd.texi  |    6 ++-
>  src/flash/flash.c |   97
> +++---
>  2 files changed, 67 insertions(+), 36 deletions(-)
> 
> Index: src/flash/flash.c
> ===
> --- src/flash/flash.c    (revision 2736)
> +++ src/flash/flash.c    (working copy)
> @@ -559,40 +559,62 @@
>      return ERROR_OK;
>  }
>  
> +int flash_check_sector_parameters(struct command_context_s
> *cmd_ctx, uint32_t first, uint32_t last, uint num_sectors)
> +{
> +    if ( first >= last ) {
> +       
> command_print(cmd_ctx, "ERROR: last sector must be >
> first sector");
> +        return ERROR_FAIL;
> +    }
> +
> +    if ( last > (num_sectors - 1)) {
> +       
> command_print(cmd_ctx, "ERROR: last sector must be =<
> %d", num_sectors - 1);
> +        return ERROR_FAIL;
> +    }
> +
> +    return ERROR_OK;
> +}
> +
>  static int handle_flash_erase_command(struct
> command_context_s *cmd_ctx, char *cmd, char **args, int
> argc)
>  {
>      if (argc > 2)
>      {
> -        int first =
> strtoul(args[1], NULL, 0);
> -        int last =
> strtoul(args[2], NULL, 0);
> +        uint32_t bank_nr;
> +        uint32_t first;
> +        uint32_t last;
>          int retval;
> -        flash_bank_t *p =
> get_flash_bank_by_num(strtoul(args[0], NULL, 0));
> +
> +        if ((retval =
> parse_u32(args[0], &bank_nr)) != ERROR_OK)
> +           
> return retval;
> +
> +        flash_bank_t *p =
> get_flash_bank_by_num(bank_nr);
> +        if (!p)
> +           
> return ERROR_OK;
> +
> +        if ((retval =
> parse_u32(args[1], &first)) != ERROR_OK)
> +           
> return retval;
> +        if (strcmp(args[2],
> "last") == 0)
> +           
> last = p->num_sectors - 1;
> +        else
> +           
> if ((retval = parse_u32(args[2], &last)) != ERROR_OK)
> +           
>     return retval;
> +
> +        if ((retval =
> flash_check_sector_parameters(cmd_ctx, first, last,
> p->num_sectors)) != ERROR_OK)
> +           
> return retval;
> +
>          duration_t
> duration;
>          char
> *duration_text;
> -
>         
> duration_start_measure(&duration);
>  
> -        if (!p)
> -        {
> -           
> return ERROR_COMMAND_SYNTAX_ERROR;
> -        }
> -
> -        if ((retval =
> flash_driver_erase(p, first, last)) == ERROR_OK)
> -        {
> +        if ((retval =
> flash_driver_erase(p, first, last)) == ERROR_OK) {
>             
> if ((retval = duration_stop_measure(&duration,
> &duration_text)) != ERROR_OK)
> -           
> {
>             
>     return retval;
> -           
> }
> -
> -           
> command_print(cmd_ctx, "erased sectors %i through %i on
> flash bank %li in %s",
> -           
>     first, last, strtoul(args[0], 0, 0),
> duration_text);
> +           
> command_print(cmd_ctx, "erased sectors %i through %i on
> flash bank %i in %s",
> +           
>     first, last, bank_nr, duration_text);
>             
> free(duration_text);
>          }
>      }
>      else
> -    {
>          return
> ERROR_COMMAND_SYNTAX_ERROR;
> -    }
>  
>      return ERROR_OK;
>  }
> @@ -601,40 +623,47 @@
>  {
>      if (argc > 3)
>      {
> -        int first =
> strtoul(args[1], NULL, 0);
> -        int last =
> strtoul(args[2], NULL, 0);
> +        uint32_t bank_nr;
> +        uint32_t first;
> +        uint32_t last;
> +        int retval;
>          int set;
> -        int retval;
> -        flash_bank_t *p =
> get_flash_bank_by_num(strtoul(args[0], NULL, 0));
> +
> +        if ((retval =
> parse_u32(args[0], &bank_nr)) != ERROR_OK)
> +           
> return retval;
> +
> +        flash_bank_t *p =
> get_flash_bank_by_num(bank_nr);
>          if (!p)
> -        {
> -           
> command_print(cmd_ctx, "flash bank '#%s' is out of bounds",
> args[0]);
>             
> return ERROR_OK;
> -        }
>  
> +        if ((retval =
> parse_u32(args[1], &first)) != ERROR_OK)
> +           
> return retval;
> +        if (strcmp(args[2],
> "last") == 0)
> +           
> last = p->num_sectors - 1;
> +        else
> +           
> if ((retval = parse_u32(args[2], &last)) != ERROR_OK)
> +           
>     return retval;
> +
>          if (strcmp(args[3],
> "on") == 0)
>             
> set =

Re: [Openocd-development] new lpc2xxx cfg files layout

2009-09-21 Thread Freddie Chopin

Here is the patch that adds the lpc2xxx_internals.tcl file and modifies 
all lpc2xxx (ARM7) files to use that.


4\/3!!
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg  (revision 2744)
+++ tcl/target/lpc2103.cfg  (working copy)
@@ -1,38 +1,16 @@
 # NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM, clocked with 12MHz 
crystal
 
-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 CRYSTAL_FREQ 1200
+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,16 @@
-#LPC-2124 CPU
+# NXP LPC2124 ARM7TDMI-S with 256kB Flash and 16kB SRAM, clocked with 12MHz 
crystal
 
-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 CRYSTAL_FREQ 1200
+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,16 @@
-#LPC-2129 CPU
+# NXP LPC2129 ARM7TDMI-S with 256kB Flash and 16kB SRAM, clocked with 12MHz 
crystal
 
+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 CRYSTAL_FREQ 1200
+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 $_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 14765 calc_checksum
+source [find target/lpc2xxx_internals.tcl]
Index: tcl/target/lpc2148.cfg
===
--- tcl/target/lpc2148.cfg  (revision 2744)
+++ tcl/target/lpc2148.cfg  (working copy)
@@ -1,55 +1,17 @@
-# Use RCLK. If RCLK is not av

Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Johnny Halfmoon wrote:
> 
> David Brownell wrote:
> > On Sunday 20 September 2009, Johnny Halfmoon wrote:
> >> +   if ((retval = flash_check_sector_parameters(cmd_ctx, 
> >> first, last, p->num_sectors)) !
> > 
> > I had in mind more like
> > 
> > uint32_t value; 
> 
> 
> Okay. Like this then:

Yes!  If I don't hear objections from anyone, I'll
check this in later today.

- Dave

> 
> = = = = = = = = = = = =
> 
> 
>  doc/openocd.texi  |6 ++-
>  src/flash/flash.c |   97 
> +++---
>  2 files changed, 67 insertions(+), 36 deletions(-)
> 
> Index: src/flash/flash.c
> ===
> --- src/flash/flash.c (revision 2736)
> +++ src/flash/flash.c (working copy)
> @@ -559,40 +559,62 @@
>   return ERROR_OK;
>  }
>  
> +int flash_check_sector_parameters(struct command_context_s *cmd_ctx, 
> uint32_t first, uint32_t last, uint num_sectors)
> +{
> + if ( first >= last ) {
> + command_print(cmd_ctx, "ERROR: last sector must be > first 
> sector");
> + return ERROR_FAIL;
> + }
> +
> + if ( last > (num_sectors - 1)) {
> + command_print(cmd_ctx, "ERROR: last sector must be =< %d", 
> num_sectors - 1);
> + return ERROR_FAIL;
> + }
> +
> + return ERROR_OK;
> +}
> +
>  static int handle_flash_erase_command(struct command_context_s *cmd_ctx, 
> char *cmd, char **args, int argc)
>  {
>   if (argc > 2)
>   {
> - int first = strtoul(args[1], NULL, 0);
> - int last = strtoul(args[2], NULL, 0);
> + uint32_t bank_nr;
> + uint32_t first;
> + uint32_t last;
>   int retval;
> - flash_bank_t *p = get_flash_bank_by_num(strtoul(args[0], NULL, 
> 0));
> +
> + if ((retval = parse_u32(args[0], &bank_nr)) != ERROR_OK)
> + return retval;
> +
> + flash_bank_t *p = get_flash_bank_by_num(bank_nr);
> + if (!p)
> + return ERROR_OK;
> +
> + if ((retval = parse_u32(args[1], &first)) != ERROR_OK)
> + return retval;
> + if (strcmp(args[2], "last") == 0)
> + last = p->num_sectors - 1;
> + else
> + if ((retval = parse_u32(args[2], &last)) != ERROR_OK)
> + return retval;
> +
> + if ((retval = flash_check_sector_parameters(cmd_ctx, first, 
> last, p->num_sectors)) != ERROR_OK)
> + return retval;
> +
>   duration_t duration;
>   char *duration_text;
> -
>   duration_start_measure(&duration);
>  
> - if (!p)
> - {
> - return ERROR_COMMAND_SYNTAX_ERROR;
> - }
> -
> - if ((retval = flash_driver_erase(p, first, last)) == ERROR_OK)
> - {
> + if ((retval = flash_driver_erase(p, first, last)) == ERROR_OK) {
>   if ((retval = duration_stop_measure(&duration, 
> &duration_text)) != ERROR_OK)
> - {
>   return retval;
> - }
> -
> - command_print(cmd_ctx, "erased sectors %i through %i on 
> flash bank %li in %s",
> - first, last, strtoul(args[0], 0, 0), 
> duration_text);
> + command_print(cmd_ctx, "erased sectors %i through %i on 
> flash bank %i in %s",
> + first, last, bank_nr, duration_text);
>   free(duration_text);
>   }
>   }
>   else
> - {
>   return ERROR_COMMAND_SYNTAX_ERROR;
> - }
>  
>   return ERROR_OK;
>  }
> @@ -601,40 +623,47 @@
>  {
>   if (argc > 3)
>   {
> - int first = strtoul(args[1], NULL, 0);
> - int last = strtoul(args[2], NULL, 0);
> + uint32_t bank_nr;
> + uint32_t first;
> + uint32_t last;
> + int retval;
>   int set;
> - int retval;
> - flash_bank_t *p = get_flash_bank_by_num(strtoul(args[0], NULL, 
> 0));
> +
> + if ((retval = parse_u32(args[0], &bank_nr)) != ERROR_OK)
> + return retval;
> +
> + flash_bank_t *p = get_flash_bank_by_num(bank_nr);
>   if (!p)
> - {
> - command_print(cmd_ctx, "flash bank '#%s' is out of 
> bounds", args[0]);
>   return ERROR_OK;
> - }
>  
> + if ((retval = parse_u32(args[1], &first)) != ERROR_OK)
> + return retval;
> + if (strcmp(args[2], "last") == 0)
> + last = p->num_sectors - 1;
> + else
> + if ((retval = parse_u32(args[2], &last)) != ERROR_OK)
> +

Re: [Openocd-development] 0.3 anyone?

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Rolf Meeser wrote:
> I've added a call to jtag_add_tlr(), and that solved it for me.
> All relevant EmbeddedICE registers are now reprogrammed.

Did you try for example just adding a bunch of TCK cycles,
via runtest?  Or maybe just reading a register?  (There's
code elsewhere which uses register reads to work around
things not getting set as expected.)

We have too many add_tlr() calls already, and on systems
with an ICEpick they will take the ARMs out of the scan
chain.  It's bad enough that happens four (!) times during
a reset -- I want to get rid of most of them -- but let's
not add them elsewhere except possibly as variant-specific
behaviors.

- 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

2009-09-21 Thread michal smulski

I checked out r2726 and applied the patch. It works great during 'reset
halt/init/run/etc' but again does not do anything for initial JTAG scan.

I hooked up scope to the srst and trst to see how the jtag controller
drives those signals.
For the initial reset (before first JTAG scan) I get about 170ms pulse
on srst and trst is pulled low (but not strongly enough to make it look
like low signal, I think telo's pull-up is about as strong as olimex's
pull-down on trst line).
Now, during 'reset halt', the reset signals behave as expected (that is
they both drive reset lines for the requested time). They *_assert_width
is a great addition to the openocd.

I can't figure out where in the code is the reset command invoked. This
is clearly broken code (at least for ft2232 chip). If this is done
outside of openocd (in libftd during driver setup for example) then
openocd should apply the reset procedure as defined in config files
before doing initial JTAG scan buf after this strange 'reset'.

BTW I set the reset_config to:
reset_config trst_and_srst separate
But it does not matter for the 'initial reset'

Anybody can point out where the first reset occurs? Does this also
happen on the non-ft2232 controllers?

On Fri, 2009-09-18 at 08:04 +0200, Øyvind Harboe wrote:
> 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...
> 

___
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

2009-09-21 Thread Duane Ellis

Freddie Chopin wrote:
> Here is the patch that adds the lpc2xxx_internals.tcl file and 
> modifies all lpc2xxx (ARM7) files to use that.

1) Looks good, I agree the "reset" issue can be resolved later.

2) Only thing I can think of is this.. type of a change
But that is a minor thing, I hate hidden default values.
They are MAGIC - that always mess me up, been  burned one too many 
many times.

+# check for RESET_CONFIG - if not defined set the default: trst_and_srst
+if { [info exists RESET_CONFIG ] } {
+   set _RESET_CONFIG $RESET_CONFIG
+} else {
+   set _RESET_CONFIG trst_and_srst
+   puts "WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG"
+}

___
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

2009-09-21 Thread Freddie Chopin

Duane Ellis pisze:
> 2) Only thing I can think of is this.. type of a change
>But that is a minor thing, I hate hidden default values.
>They are MAGIC - that always mess me up, been  burned one too many 
> many times.
> 
> +# check for RESET_CONFIG - if not defined set the default: trst_and_srst
> +if { [info exists RESET_CONFIG ] } {
> +set _RESET_CONFIG $RESET_CONFIG
> +} else {
> +set _RESET_CONFIG trst_and_srst
> +   puts "WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG"
> +}

I also thought about that, but... in here such line does not print any 
output in the console... It doesn't get printed even with "-d 3", so I 
have no idea what's wrong.

Any clues? I'd gladly add some warning messages to this file when the 
default values are selected.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Enhancement: Allow -1 as last sector for protection and erase

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Johnny Halfmoon wrote:
> Okay. Like this then:

Merged with some cleanups, including the one noted by Rolf.

___
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

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Freddie Chopin wrote:
> > +       puts "WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG"
> > +}
> 
> I also thought about that, but... in here such line does not print any 
> output in the console... It doesn't get printed even with "-d 3", so I 
> have no idea what's wrong.
> 
> Any clues? I'd gladly add some warning messages to this file when the 
> default values are selected.

"echo" works.  
___
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

2009-09-21 Thread Øyvind Harboe

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] 0.3 anyone?

2009-09-21 Thread Øyvind Harboe

On Tue, Sep 22, 2009 at 12:03 AM, David Brownell  wrote:
> On Monday 21 September 2009, Rolf Meeser wrote:
>> I've added a call to jtag_add_tlr(), and that solved it for me.
>> All relevant EmbeddedICE registers are now reprogrammed.
>
> Did you try for example just adding a bunch of TCK cycles,
> via runtest?  Or maybe just reading a register?  (There's
> code elsewhere which uses register reads to work around
> things not getting set as expected.)
>
> We have too many add_tlr() calls already, and on systems
> with an ICEpick they will take the ARMs out of the scan
> chain.  It's bad enough that happens four (!) times during
> a reset -- I want to get rid of most of them -- but let's
> not add them elsewhere except possibly as variant-specific
> behaviors.

Could he be repairing a bug in the driver where the
driver does not track the JTAG state correctly after
a srst that pulls trst?

-- 
Ø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] 0.3 anyone?

2009-09-21 Thread David Brownell

On Monday 21 September 2009, Øyvind Harboe wrote:
> Could he be repairing a bug in the driver where the
> driver does not track the JTAG state correctly after
> a srst that pulls trst?

Could be; I hope he reports what's up ... :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

40 matches

Mail list logo