Re: [Openocd-development] Analog Device AduC70xx support

2009-07-08 Thread Thomas A. Moulton 
On Wed, 2009-07-08 at 09:41 +0200, Øyvind Harboe wrote:
 I have an Aduc7024 here that I can test with.
 
 Could you provide instructions on how to reproduce the crash on
 that target?
 
 

It works without crashing now!

The elf file does have a problem.

I will send it to you.

I did not change any setting to remove unnecessary sections from the
output.

tom


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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-08 Thread Thomas A. Moulton 
On Wed, 2009-07-08 at 14:43 +0200, Øyvind Harboe wrote:
 On Wed, Jul 8, 2009 at 2:22 PM, Thomas A. Moultont...@moulton.us wrote:
  On Wed, 2009-07-08 at 09:41 +0200, Øyvind Harboe wrote:
  I have an Aduc7024 here that I can test with.
 
  Could you provide instructions on how to reproduce the crash on
  that target?
 
 
 
  It works without crashing now!
 
 With or without the patch?
 
 

svn head plus

Index: src/flash/flash.c
===
--- src/flash/flash.c   (revision 2498)
+++ src/flash/flash.c   (working copy)
@@ -1091,6 +1091,12 @@
 
/* allocate buffer */
buffer = malloc(run_size);
+if (buffer == NULL)
+{
+LOG_ERROR(Out of memory allocating %d bytes,
run_size);
+return ERROR_FAIL;
+}
+   
buffer_size = 0;
 
/* read sections to the buffer */


Should I try the other patch you sent?

Tom

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

Re: [Openocd-development] Fix flash programming w/aduc702x

2009-07-08 Thread Thomas A. Moulton 
On Wed, 2009-07-08 at 16:10 +0200, Øyvind Harboe wrote:
 This patch fixes the broken flash programming w/workarea enabled.
 
 Please test  report.
 
 These bugs explain the intermittent SEGFAULT's reported +
 that flash programming worked some of the time.
 

Pardon my ignorance, but is there an easy way to automatically apply
this patch?

tom

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

Re: [Openocd-development] Fix flash programming w/aduc702x

2009-07-08 Thread Thomas A. Moulton 
On Wed, 2009-07-08 at 17:31 +0200, Øyvind Harboe wrote:
 On Wed, Jul 8, 2009 at 5:20 PM, Thomas A. Moultont...@moulton.us wrote:
  On Wed, 2009-07-08 at 16:10 +0200, Øyvind Harboe wrote:
  This patch fixes the broken flash programming w/workarea enabled.
 
  Please test  report.
 
  These bugs explain the intermittent SEGFAULT's reported +
  that flash programming worked some of the time.
 
 
  Pardon my ignorance, but is there an easy way to automatically apply
  this patch?
 
 
 patch -p0 /cygdrive/c/temp/fixaduc702xflash.txt
 
 NB! Note that without this fix you'll get *intermittant* crashes
 and flashing *could* work in some cases.
 
 

Excellent!  It works fine!

Thanks.

Now to build a windows version.

tom

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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-06 Thread Thomas A. Moulton 
When I try to burn flash on a ADuC7021 using the ADuC702x.cfg I get a a
crash. (traceback attached)

in aduc7021.cfg if I comment out the following line it works

$_TARGETNAME configure -work-area-phys 0x1 -work-area-size 0x2000

 it just takes a LONG time - of course)

The lines below the HALT can be commented out with no effect.
I included them here because they were active during this traceback
---

Main command file

telnet_port 
tcl_port 
gdb_port 

source [find interface/olimex-jtag-tiny.cfg]
source [find target/aduc702x.cfg]

init
halt

# Write to MEMMAP to enable access to flash below first 64 bytes
mwh 0xf804 0x8

#setup POWCON register to obtain the default 5.22MHz (RC osc) clock.
#  POWKEY1 = 0x01;
mwh 0x0404 0x01
#  POWCON = 0x0;
mwh 0x0408 0x0
#  POWKEY2 = 0xF4;
mwh 0x040c 0xf4
---

I then erase flash and issue:

flash write_image file.elf 0x8 elf


tom

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.

target_buffer_get_u32 (target=0x9465a20, buffer=0x948b000 Address 0x948b000 
out of bounds)
at ../../src/helper/types.h:80
80  return (uint32_t)(buf[0] | buf[1]  8 | buf[2]  16 | buf[3] 
 24);
(gdb) where
#0  target_buffer_get_u32 (target=0x9465a20, 
buffer=0x948b000 Address 0x948b000 out of bounds) at 
../../src/helper/types.h:80
#1  0x0806f642 in arm7_9_write_memory (target=0x9465a20, address=65600, size=4, 
count=1750, 
buffer=0x948b004 Address 0x948b004 out of bounds) at arm7_9_common.c:2458
#2  0x0806e935 in arm7_9_bulk_write_memory (target=0x9465a20, address=65600, 
count=1750, 
buffer=0x948ad30 ) at arm7_9_common.c:2664
#3  0x08061c8d in target_write_buffer (target=0x9465a20, address=65600, 
size=7000, 
buffer=0x948ad30 ) at target.c:1167
#4  0x080b7261 in aduc702x_write (bank=0x946ad40, buffer=0x948ad30 , 
offset=0, count=7176)
at aduc702x.c:284
#5  0x0805e80b in flash_driver_write (bank=0x946ad40, buffer=0x0, offset=0, 
count=38676)
at flash.c:94
#6  0x0805f2c0 in flash_write (target=0x9465a20, image=0xbfa4da24, 
written=0xbfa4da58, erase=0)
at flash.c:1138
#7  0x0805fead in handle_flash_write_image_command (cmd_ctx=0x94657e8, 
cmd=0x9477ee8 write_image, args=0x94595bc, argc=3) at flash.c:699
#8  0x0809c3cc in run_command (context=0x94657e8, c=0x9477ef8, words=0x94595b8, 
num_words=4)
at command.c:415
#9  0x0809c672 in script_command (interp=0x9449020, argc=4, argv=0xbfa4db40) at 
command.c:142
#10 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x947aa48) at 
jim.c:8708
#11 0x080ed5c7 in Jim_EvalCoreCommand (interp=0x9449020, argc=3, 
argv=0xbfa4dc00)
at jim.c:10846
#12 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9459160) at 
jim.c:8708
#13 0x080ebf6f in Jim_CatchCoreCommand (interp=0x9449020, argc=2, 
argv=0xbfa4dcc0)
at jim.c:11413
#14 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x94599f8) at 
jim.c:8708
#15 0x080e9123 in Jim_EvalExpression (interp=0x9449020, exprObjPtr=0x9459a70, 
exprResultPtrPtr=0xbfa4de1c) at jim.c:6927
#16 0x080e9ea1 in Jim_GetBoolFromExpr (interp=0x9449020, exprObjPtr=0x9459a70, 
boolPtr=0xbfa4de58) at jim.c:7210
#17 0x080eed14 in Jim_IfCoreCommand (interp=0x9449020, argc=5, argv=0xbfa4dec0) 
at jim.c:10297
#18 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9479630) at 
jim.c:8708
#19 0x080e812b in JimCallProcedure (interp=0x9449020, cmd=0x94797e0, argc=3, 
argv=0xbfa4dfb0)
at jim.c:8857
#20 0x080e7e06 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9459990) at 
jim.c:8714
#21 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x94695f8) at 
jim.c:8708
#22 0x080e7b22 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9468ba0) at 
jim.c:8654
#23 0x080eee1d in Jim_IfCoreCommand (interp=0x9449020, argc=3, argv=0xbfa4e1a0) 
at jim.c:10319
#24 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9468150) at 
jim.c:8708
#25 0x080eee1d in Jim_IfCoreCommand (interp=0x9449020, argc=3, argv=0xbfa4e270) 
at jim.c:10319
#26 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x944fbc0) at 
jim.c:8708
#27 0x080e812b in JimCallProcedure (interp=0x9449020, cmd=0x9455160, argc=5, 
argv=0xbfa4e35c)
at jim.c:8857
#28 0x080e83e0 in Jim_EvalObjVector (interp=0x9449020, objc=6, objv=0xbfa4e35c) 
at jim.c:8424
#29 0x080e84d8 in JimUnknown (interp=0x9449020, argc=5, argv=0xbfa4e3e0) at 
jim.c:8383
#30 0x080e7e67 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9457cd0) at 
jim.c:8723
#31 0x080e8c02 in Jim_Eval_Named (interp=0x9449020, 
script=0x9459218 flash write_image file.elf 0x8 elf, 
filename=0x810648e command.c, lineno=469) at jim.c:8901
#32 0x0809c2e2 in command_run_line (context=0x94657e8, 
line=0x9459218 flash write_image file.elf 0x8 elf) at command.c:469
#33 0x080987cd in telnet_input (connection=0x9463be8) at telnet_server.c:330
#34 0x08099d20 in server_loop (command_context=0x9449008) at server.c:433
#35 0x0804a57c in

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-06 Thread Thomas A. Moulton 
On Mon, 2009-07-06 at 18:14 +0200, Øyvind Harboe wrote:
 Hmm. here is a stab in the dark. Try the attached
 patch...
 
 

it is still dark...

Program received signal SIGSEGV, Segmentation fault.
target_buffer_get_u32 (target=0x82a2a20, buffer=0x82c8000 Address
0x82c8000 out of bounds)
at ../../src/helper/types.h:80
80  return (uint32_t)(buf[0] | buf[1]  8 | buf[2]  16 | buf[3] 

24);
(gdb) 
(gdb) where
#0  target_buffer_get_u32 (target=0x82a2a20, 
buffer=0x82c8000 Address 0x82c8000 out of bounds)
at ../../src/helper/types.h:80
#1  0x0806f772 in arm7_9_write_memory (target=0x82a2a20, address=65600,
size=4, count=1750, 
buffer=0x82c8004 Address 0x82c8004 out of bounds) at
arm7_9_common.c:2450
#2  0x0806ea45 in arm7_9_bulk_write_memory (target=0x82a2a20,
address=65600, count=1750, 
buffer=0x82c7d30 ) at arm7_9_common.c:2656
#3  0x08061d3d in target_write_buffer (target=0x82a2a20, address=65600,
size=7000, 
buffer=0x82c7d30 ) at target.c:1167
#4  0x080b7651 in aduc702x_write (bank=0x82a7d40, buffer=0x82c7d30 ,
offset=0, count=7176)
at aduc702x.c:284
#5  0x0805e86b in flash_driver_write (bank=0x82a7d40, buffer=0x0,
offset=0, count=38676)
at flash.c:94
#6  0x0805f328 in flash_write (target=0x82a2a20, image=0xbf890064,
written=0xbf890098, erase=0)
at flash.c:1144
#7  0x0805ff5d in handle_flash_write_image_command (cmd_ctx=0x82a27e8, 
cmd=0x82b4ee8 write_image, args=0x82965bc, argc=3) at flash.c:699
#8  0x0809c7bc in run_command (context=0x82a27e8, c=0x82b4ef8,
words=0x82965b8, num_words=4)
at command.c:415
#9  0x0809ca62 in script_command (interp=0x8286020, argc=4,
argv=0xbf890180) at command.c:142
#10 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82b7a48)
at jim.c:8708
#11 0x080ed9b7 in Jim_EvalCoreCommand (interp=0x8286020, argc=3,
argv=0xbf890240)
at jim.c:10846
#12 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x8296160)
at jim.c:8708
#13 0x080ec35f in Jim_CatchCoreCommand (interp=0x8286020, argc=2,
argv=0xbf890300)
at jim.c:11413
#14 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82969f8)
at jim.c:8708
#15 0x080e9513 in Jim_EvalExpression (interp=0x8286020,
exprObjPtr=0x8296a70, 
exprResultPtrPtr=0xbf89045c) at jim.c:6927
#16 0x080ea291 in Jim_GetBoolFromExpr (interp=0x8286020,
exprObjPtr=0x8296a70, 
boolPtr=0xbf890498) at jim.c:7210
#17 0x080ef104 in Jim_IfCoreCommand (interp=0x8286020, argc=5,
argv=0xbf890500) at jim.c:10297
#18 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82b6630)
at jim.c:8708
#19 0x080e851b in JimCallProcedure (interp=0x8286020, cmd=0x82b67e0,
argc=3, argv=0xbf8905f0)
at jim.c:8857
#20 0x080e81f6 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x8296990)
at jim.c:8714
#21 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82a65f8)
at jim.c:8708
#22 0x080e7f12 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82a5ba0)
at jim.c:8654
#23 0x080ef20d in Jim_IfCoreCommand (interp=0x8286020, argc=3,
argv=0xbf8907e0) at jim.c:10319
#24 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82a5150)
at jim.c:8708
#25 0x080ef20d in Jim_IfCoreCommand (interp=0x8286020, argc=3,
argv=0xbf8908b0) at jim.c:10319
#26 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x828cbc0)
at jim.c:8708
#27 0x080e851b in JimCallProcedure (interp=0x8286020, cmd=0x8292160,
argc=5, argv=0xbf89099c)
at jim.c:8857
#28 0x080e87d0 in Jim_EvalObjVector (interp=0x8286020, objc=6,
objv=0xbf89099c) at jim.c:8424
#29 0x080e88c8 in JimUnknown (interp=0x8286020, argc=5, argv=0xbf890a20)
at jim.c:8383
#30 0x080e8257 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x8294cd0)
at jim.c:8723
#31 0x080e8ff2 in Jim_Eval_Named (interp=0x8286020, 
script=0x8296218 flash write_image C0-4AD2DA-1.elf 0x8 elf, 
filename=0x8106909 command.c, lineno=469) at jim.c:8901
#32 0x0809c6d2 in command_run_line (context=0x82a27e8, 
line=0x8296218 flash write_image C0-4AD2DA-1.elf 0x8 elf) at
command.c:469
#33 0x08098a3d in telnet_input (connection=0x82a0be8) at
telnet_server.c:330
#34 0x08099f90 in server_loop (command_context=0x8286008) at
server.c:433
#35 0x0804a5dc in openocd_main (argc=3, argv=0xbf8911d4) at
openocd.c:283
#36 0x0804a332 in main (argc=Cannot access memory at address 0x82c8000
) at main.c:39
(gdb) 


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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-06 Thread Thomas A. Moulton 
On Mon, 2009-07-06 at 19:01 +0200, Øyvind Harboe wrote:
 I'm guessing that this is an elf file parsing problem.
 
 Can you provide the elf file?


Here is the same crash with a BIN file

flash write file.bin 0x8 bin

Program received signal SIGSEGV, Segmentation fault.
target_buffer_get_u32 (target=0x8567a20, buffer=0x858d000 Address
0x858d000 out of bounds)
at ../../src/helper/types.h:80
80  return (uint32_t)(buf[0] | buf[1]  8 | buf[2]  16 | buf[3] 

24);
(gdb) 
(gdb) where
#0  target_buffer_get_u32 (target=0x8567a20, 
buffer=0x858d000 Address 0x858d000 out of bounds)
at ../../src/helper/types.h:80
#1  0x0806f772 in arm7_9_write_memory (target=0x8567a20, address=65600,
size=4, count=1750, 
buffer=0x858d004 Address 0x858d004 out of bounds) at
arm7_9_common.c:2450
#2  0x0806ea45 in arm7_9_bulk_write_memory (target=0x8567a20,
address=65600, count=1750, 
buffer=0x858c6c8 ) at arm7_9_common.c:2656
#3  0x08061d3d in target_write_buffer (target=0x8567a20, address=65600,
size=7000, 
buffer=0x858c6c8 ) at target.c:1167
#4  0x080b7651 in aduc702x_write (bank=0x856cd40, buffer=0x858c6c8 ,
offset=0, count=7176)
at aduc702x.c:284
#5  0x0805e86b in flash_driver_write (bank=0x856cd40, buffer=0x0,
offset=0, count=38676)
at flash.c:94
#6  0x0805f328 in flash_write (target=0x8567a20, image=0xbfedeeb4,
written=0xbfedeee8, erase=0)
at flash.c:1144
#7  0x0805ff5d in handle_flash_write_image_command (cmd_ctx=0x85677e8, 
cmd=0x8579ee8 write_image, args=0x855b5bc, argc=3) at flash.c:699
#8  0x0809c7bc in run_command (context=0x85677e8, c=0x8579ef8,
words=0x855b5b8, num_words=4)
at command.c:415
#9  0x0809ca62 in script_command (interp=0x854b020, argc=4,
argv=0xbfedefd0) at command.c:142
#10 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x857ca48)
at jim.c:8708
#11 0x080ed9b7 in Jim_EvalCoreCommand (interp=0x854b020, argc=3,
argv=0xbfedf090)
at jim.c:10846
#12 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x855b160)
at jim.c:8708
#13 0x080ec35f in Jim_CatchCoreCommand (interp=0x854b020, argc=2,
argv=0xbfedf150)
at jim.c:11413
#14 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x855b9f8)
at jim.c:8708
#15 0x080e9513 in Jim_EvalExpression (interp=0x854b020,
exprObjPtr=0x855ba70, 
exprResultPtrPtr=0xbfedf2ac) at jim.c:6927
#16 0x080ea291 in Jim_GetBoolFromExpr (interp=0x854b020,
exprObjPtr=0x855ba70, 
boolPtr=0xbfedf2e8) at jim.c:7210
#17 0x080ef104 in Jim_IfCoreCommand (interp=0x854b020, argc=5,
argv=0xbfedf350) at jim.c:10297
#18 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x857b630)
at jim.c:8708
#19 0x080e851b in JimCallProcedure (interp=0x854b020, cmd=0x857b7e0,
argc=3, argv=0xbfedf440)
at jim.c:8857
#20 0x080e81f6 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x855b990)
at jim.c:8714
#21 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x856b5f8)
at jim.c:8708
#22 0x080e7f12 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x856aba0)
at jim.c:8654
#23 0x080ef20d in Jim_IfCoreCommand (interp=0x854b020, argc=3,
argv=0xbfedf630) at jim.c:10319
#24 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x856a150)
at jim.c:8708
#25 0x080ef20d in Jim_IfCoreCommand (interp=0x854b020, argc=3,
argv=0xbfedf700) at jim.c:10319
#26 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x8551bc0)
at jim.c:8708
#27 0x080e851b in JimCallProcedure (interp=0x854b020, cmd=0x8557160,
argc=5, argv=0xbfedf7ec)
at jim.c:8857
#28 0x080e87d0 in Jim_EvalObjVector (interp=0x854b020, objc=6,
objv=0xbfedf7ec) at jim.c:8424
#29 0x080e88c8 in JimUnknown (interp=0x854b020, argc=5, argv=0xbfedf870)
at jim.c:8383
#30 0x080e8257 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x8559cd0)
at jim.c:8723
#31 0x080e8ff2 in Jim_Eval_Named (interp=0x854b020, 
script=0x855b218 flash write_image file.bin 0x8 bin, 
filename=0x8106909 command.c, lineno=469) at jim.c:8901
#32 0x0809c6d2 in command_run_line (context=0x85677e8, 
line=0x855b218 flash write_image file.bin 0x8 bin) at
command.c:469
#33 0x08098a3d in telnet_input (connection=0x8565be8) at
telnet_server.c:330
#34 0x08099f90 in server_loop (command_context=0x854b008) at
server.c:433
#35 0x0804a5dc in openocd_main (argc=3, argv=0xbfee0024) at
openocd.c:283
#36 0x0804a332 in main (argc=Cannot access memory at address 0x858d000
) at main.c:39
(gdb) 


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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-06 Thread Thomas A. Moulton 
On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote:
 Can you reproduce with:
 
 - dummy driver? (--enable-dummy + -f interface/dummy.cfg)
 - help fill = flash fill
 

I built with

./configure --enable-maintainer-mode --enable-parport
--enable-ft2232_libftdi --enable-jlink --enable-dummy

ran as

sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg

Open On-Chip Debugger 0.2.0-in-development (2009-07-06-14:45) svn:2482M
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read
http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
Error: There are no enabled taps?
Error: There are no enabled taps?
Warn : no gdb ports allocated as no target has been specified
Info : accepting 'telnet' connection from 0
Unknown command: flash fill

 
 help fill
 


No known command...

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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-06 Thread Thomas A. Moulton 
On Mon, 2009-07-06 at 21:23 +0200, Øyvind Harboe wrote:
 On Mon, Jul 6, 2009 at 8:52 PM, Thomas A. Moultont...@moulton.us wrote:
  On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote:
  Can you reproduce with:
 
  - dummy driver? (--enable-dummy + -f interface/dummy.cfg)
  - help fill = flash fill
 
 
  I built with
 
  ./configure --enable-maintainer-mode --enable-parport
  --enable-ft2232_libftdi --enable-jlink --enable-dummy
 
  ran as
 
  sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg
 
 you need to add your target configuration file as well
 
 sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg
 -f /usr/local/share/openocd/scripts/target/adu.cfg
 

t...@w2vy:~$ sudo openocd
-f /usr/local/share/openocd/scripts/interface/dummy.cfg
-f /usr/local/share/openocd/scripts/target/aduc702x.cfg
[sudo] password for tom: 
Open On-Chip Debugger 0.2.0-in-development (2009-07-06-14:45) svn:2482M
$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 : Tap/Device does not have IDCODE
Error: JTAG tap: aduc702x.cpu  got: 0x (mfg: 0x000,
part: 0x, ver: 0x0)
Error: JTAG tap: aduc702x.cpu  expected 1 of 1: 0x3f0f0f0f (mfg: 0x787,
part: 0xf0f0, ver: 0x3)
Error: trying to validate configured JTAG chain anyway...
Error: Could not validate JTAG scan chain, IR mismatch, scan returned
0x3F. tap=aduc702x.cpu pos=0 expected 0x1 got 3
Warn : Could not validate JTAG chain, continuing anyway...
Error: unknown EmbeddedICE version (comms ctrl: 0x)
target state: halted
target halted in Thumb state due to watchpoint, current mode: System
cpsr: 0x pc: 0xffef

are these errors/warnings ok?

tom

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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-06 Thread Thomas A. Moulton 
On Mon, 2009-07-06 at 21:23 +0200, Øyvind Harboe wrote:
 On Mon, Jul 6, 2009 at 8:52 PM, Thomas A. Moultont...@moulton.us wrote:
  On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote:
  Can you reproduce with:
 
  - dummy driver? (--enable-dummy + -f interface/dummy.cfg)
  - help fill = flash fill
 
 
  I built with
 
  ./configure --enable-maintainer-mode --enable-parport
  --enable-ft2232_libftdi --enable-jlink --enable-dummy
 
  ran as
 
  sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg
 
 you need to add your target configuration file as well
 
 sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg
 -f /usr/local/share/openocd/scripts/target/adu.cfg

t...@w2vy:~$ sudo openocd
-f /usr/local/share/openocd/scripts/interface/dummy.cfg
-f /usr/local/share/openocd/scripts/target/aduc702x.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-07-06-14:45) svn:2482M
$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 : Tap/Device does not have IDCODE
Error: JTAG tap: aduc702x.cpu  got: 0x (mfg: 0x000,
part: 0x, ver: 0x0)
Error: JTAG tap: aduc702x.cpu  expected 1 of 1: 0x3f0f0f0f (mfg: 0x787,
part: 0xf0f0, ver: 0x3)
Error: trying to validate configured JTAG chain anyway...
Error: Could not validate JTAG scan chain, IR mismatch, scan returned
0x3F. tap=aduc702x.cpu pos=0 expected 0x1 got 3
Warn : Could not validate JTAG chain, continuing anyway...
Error: unknown EmbeddedICE version (comms ctrl: 0x)
target state: halted
target halted in Thumb state due to watchpoint, current mode: System
cpsr: 0x pc: 0xffef
Info : accepting 'telnet' connection from 0
Warn : target reentered debug state, but not at the desired exit point:
0xffef
Error: error executing aduc702x flash write algorithm
Error: flash block writing failed





t...@w2vy:~$ telnet 127.0.0.1 
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Open On-Chip Debugger
 flash fillw 0x8 0x1234 4
target reentered debug state, but not at the desired exit point:
0xffef
error executing aduc702x flash write algorithm
flash block writing failed
error writing to flash at address 0x0008 at offset 0x (-902)

called at file command.c, line 469
called at file embedded:startup.tcl, line 89
called at file embedded:startup.tcl, line 91
called at file embedded:startup.tcl, line 93


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

Re: [Openocd-development] Analog Device AduC70xx support

2009-07-03 Thread Thomas A. Moulton 
I am also using an ADuC702x (7021)

I was using the windows version (pre-built r1888 I think)

And when I try to use the internal RAM for flash writes I get a SEGV
If I do not give it a ram block it finishes (eventually)

I am running svn HEAD

This may not be a new problem, as the r1888 on windows crashed too.

Has anyone else had such problems?

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

[Openocd-development] Building on Ubuntu (9.04)

2009-06-25 Thread Thomas A. Moulton 
Ok this should be an easy one compared to what we have been dealing
with :)

I have check out out svn,
./bootstrap

./configure --enable-ft2232_libftdi --enable-jlink --enable-arm-jtag-ew
--enable-ioutil 

and I get

checking Build  Link with libftdi.. configure: error: Cannot build
 run test program using libftdi

I checked the archives and see talk of fixing this kind of problem in
december an did mentioned version 0.10 (which is what I have)

Is that something that should have been committed?

Should I download and build the latest libftdi instead?

tom

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

Re: [Openocd-development] Building on Ubuntu (9.04)

2009-06-25 Thread Thomas A. Moulton 
On Thu, 2009-06-25 at 17:05 -0300, Alain Mouette wrote:
 Building OpenOCD is far more complex then it should be :(
 
 I also had a few problems building on Ubuntu 8.04. I made a detailed 
 report on the problems, so that they could be improved. Unfortunately I 
 got no echo from the list on these matters
 
 :(
 Alain

Thanks, I will track down your message...

I am curious... what hosts does it build properly right out of the box?

tom

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

Re: [Openocd-development] Building on Ubuntu (9.04)

2009-06-25 Thread Thomas A. Moulton 
On Thu, 2009-06-25 at 13:26 -0700, David Brownell wrote:
 On Thursday 25 June 2009, Alain Mouette wrote:
  Building OpenOCD is far more complex then it should be :(
  
  I also had a few problems building on Ubuntu 8.04. I made a detailed 
  report on the problems, so that they could be improved. Unfortunately I 
  got no echo from the list on these matters
 
 I thought I followed up on that.  The issue with the 8.04
 release is that it's got an old libftdi.
 
 To build on that you'll need a new libftdi.
 
   https://lists.berlios.de/pipermail/openocd-development/2009-June/008095.html
 
 Ah, I see.  Wrong thread.

Boy they gotta watch the numbering... I have 8.04LTS on a machine in my
office and 9.04 is running at home... g I am going to upgrade my
office machine...

Let me get up to date and try again...

I do see other comments about the errors reported and will watch out
too...

tom

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

Re: [Openocd-development] Summer coding project proposal

2009-06-24 Thread Thomas A. Moulton 
Michael Bruck wrote:
 If a third party develops a libftdi.dll replacement then there is no
 reason a user can not use that replacement. The GPL license that
 applies to the user does not restrict at all what he does with the
 code or binary as long as he does not distribute binaries of it.

 Obviously to put the dll wrapper wrapper under a GPL+exceptions
 license it would have to be written from scratch rather than just
 copypasting GPLed libftdi header files (although one could ask the
 libfti author to re-license his/her files).
   
Yes, another developer could produce such a library.
There might be GPL Gray areas, etc

But the discussion would need to be some place else, not on this list.

:)

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

[Openocd-development] Can we get back to forward progress?

2009-06-24 Thread Thomas A. Moulton 
As far as I can see there are two solutions being worked on:

USB (winusb, libusb) and libftdi

and

tcpip/Sockets/pipes/ipc

Can the person who is heading up each task start a NEW thread and 
identify who else is working with you and the state of the work.

I for one will be willing to test anything.

Tom
ps. let's let the old threads die
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 Windows - summary of options

2009-06-24 Thread Thomas A. Moulton 
On Wed, 2009-06-24 at 16:56 +0200, Freddie Chopin wrote:

 GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
 Important Qestion - Is OpenOCD meant for users to use, or just to be 
 100%-GPL-at-any-cost?
 
  You're the ONLY one advocating a we-don't-care-for-X mindset.
 
 Damn, I see that the opposite way - 5-10 ppl are 100% GPL (that's 
 where you are) while everyone else is like why create artificial 
 problems?.

Freddie,

I have been involved with a number of distributed group projects and GPL
is the best way to go to insure the collective work will survive the
longest.

Case and point.

I wrote a Wireless X.25 packet switch in the 1980s, it was used world
wide on Amateur Packet Radio. It was called The ROSE X.25 Packet Switch.

It was not open source, I sold rights to it, ended up working on it for
a year and then the project was flushed.

I was burned out by this and no longer developed the switch and ROSE
died.

I was a core developer on osCommerce (aka The Exchange Project) that
project seems to be all but dead as well, but there are many forks and
some of them are still alive. Personally I still use it for one of my
websites. (GPL)

I have made a few changes to GNUBG (GNU Backgammon), nothing big, but
every little bit helps. (GPL)

I also play backgammon on FIBS (First Internet Backgammon Server) and
for a while tried to get the clients used there modernized. Sadly none
of them are really open source, I did get a few copies of source, but
the most popular one the author will not allow it to be converted to GPL
and they demand rights to any code I develop, with no rights to me (or
others). (closed)

I also took over a dead project that was a Tourney Robot for FIBS.
The original author long lost interest, but because it was GPL and
posted in a public place I was able to get the code and make
improvements, after seeing those updates the author did get responsive
to my questions, etc.

The fact that I was able to get the source and do something without
asking anyone for anything made it possible.

As a developer I DO care about the license. If it is not GPL (or
compatible) I will not waste my time. Now as a USER I also check the
license, if it is GPL then I know I can become a developer, if needed.

Could it be that the 5-10 people that are GPL 110% might just be the
active developers?

Tom



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

Re: [Openocd-development] openocd, ftd2xx

2009-06-24 Thread Thomas A. Moulton 
On Wed, 2009-06-24 at 11:26 -0700, Zach Welch wrote:

 
 We can raise money to pay for the signing costs; presumably, they don't
 need to be signed during development testing.  
 

My IT guys said that in Vista unsigned drivers can be loaded if you
enable a boot time option and it only lasts for that boot.

Ok for development, ng for users.

The signing problem is only Vista right?

I have an unsigned driver we use with one of our products that just
gives the warning message... hit continue and all is fine

tom

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

Re: [Openocd-development] FT2232 Windows - summary of options

2009-06-23 Thread Thomas A. Moulton 
On Mon, 2009-06-22 at 15:30 -0400, Duane Ellis wrote:
 All - I believe - I am not sure - that the primary benefit of 
 libft2xxx is as follows:
 
 (a)   It is measurably faster.
 
 That just requires work to make it faster.
 
 (b)   It works on more platforms, ie: Win7, WinVista, because drivers 
 exist for those platforms.
 
 This is tough/hard, nobody on this list is a windows driver developer.
 Grrr. Such is life.
 
 (c)   Nobody was offering a universal libusb - type INF files for 
 windows.
 
 Looks like Freddie Chopin is working on that :-)  Perhaps - we could 
 have a contrib folder with a *binary* libusb0.sys file
 and associated INF files that references *ALL* ftdi based dongles 
 - (The VID/PID list is in the source file...)
 That *INF* file and matching SYS file should be deliverable with 
 OpenOCD.
 
 (d) There is another choice -  WinUSB
 
 http://msdn.microsoft.com/en-us/library/aa476426.aspx
 
 As I understand, it is a a multi-(windoze)-platform solution that 
 exposes the USB device, functionally in the same manor and style as 
 libusb does, ie: the ablity (1) to rd/wr endpoints, (2) send control 
 commands.
 
 I believe there is the only open question that needs to be asked and 
 answered.
 
 The MS-WinUSB driver - did not  *ship* with WinXP, but is available as a 
 co-install for WinXP.
 
 As I understand (I have not confirmed, and I do not know all the details 
 of it), the driver and associated OS-libraries/headers are *PRESENT* on 
 Vista, and I presume Win7 (with appropriate dev tools installed), 
 therefore it functionally *SHIPS* with the operating system, and as such 
 it sould fall under the standard operating system component exception to 
 the GPL.
 
 This solution is - by design - something that can be added to WinXP (the 
 co-install solution).  I think of it sort of like this: The old system 
 only supplied a CDROM (read-only) driver - later - new systems come 
 with CD-WRITER (and today, we have CD-RW) - the *new* os does not 
 require an upgrade, the *old* os has an upgrade path to make the 
 CD-WRITER (and now CD-RW) work.
 
 I should - as a user of that old system - install the OS update - and be 
 able to make use of that GPL software.
 
 All is not rosy and perfect, WinUSB would require an INF file that 
 *points* to the driver - much like the work that Freddy is working 
 towards with a universal libusb inf file
 
 Agree?
 
 -Duane.

This is a VERY interesting suggestion.

WunUSB *is* a system library, as it comes from the OS vendor and
provides general services for many devices, not just one subset of
devices. It is a General USB interface.

This should also have the advantage of being signed by microsoft so it
will install on all (current) versions of the windows operating systems.

The question I have is...

If we have an INF file pointing to a signed driver, does the INF/Driver
pair need to be signed, or is the signing just the authenticate the
driver CODE as being trusted?

If it is just the driver code, then I think this is the most stable long
term solution above all.

Now assuming libftdi interfaces to a USB library that could mean that
the 32/64 bit issues can be handled in winusb, since USB is just a frame
based communications pipe (byte stream)

Tom

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

Re: [Openocd-development] License

2009-06-23 Thread Thomas A. Moulton 
On Tue, 2009-06-23 at 22:10 +, Photo Leecher wrote:
 Guess what, OpenOCD wasn't started so YOU can get paid.
 If you don't like the way OpenOCD is managed, get out.
  
 You're quite an asswipe.
 
 

Lets keep it civil here.

In GPL Free means freedom, not no costs ever.

You can develop your own changes to the code, costing you time
or you can hire someone to make change costing you money

Many people make a living developing open source code, and those
changes are also available for others to use

tom
 

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

Re: [Openocd-development] License

2009-06-23 Thread Thomas A. Moulton 
On Tue, 2009-06-23 at 22:02 +, Photo Leecher wrote:
 Isn't it great that you are against a solution that would put a dent
 in sales of your overpriced rip off 700€ hardware?
 Gotta love the impartiality here...
 
 The exception could be allowed now and then removed later once the
 supposed new solutions are done and working.
 
A Real exception once added can not be removed.

tom
 

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

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

2009-06-23 Thread Thomas A. Moulton 
On Tue, 2009-06-23 at 15:33 -0700, Rick Altherr wrote:

 The community as a whole can easily decide to remove your code,  
 replace it, and relicense.  The community can also choose to follow an  
 alternate interpretation of the license that you may not agree with.   
 Again, you have no rights to declare which interpretation must be  
 followed.  Your rights only extend to bring a court case to decide the  
 claims.  The community must reach a resolution and individual members  
 don't have the rights to assert that theirs must be used.

Rick,

The term community and authors are not interchangeable.

What you are suggesting is not a trivial task.

tom

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

Re: [Openocd-development] License

2009-06-23 Thread Thomas A. Moulton 
On Tue, 2009-06-23 at 22:37 +, Photo Leecher wrote:
 Oh really?
 So one can no longer remove code that uses FTDI2xx in a newer
 revision/version and remove it from the license?
 You should get yourself a lawyer... That will be the day when one is
 not allowed to DELETE CODE.
  
 Oh dear
 
 

Well, you would have a hard time deleting the code from my computer
and I would still be able to distribute it, so not it can not be totally
removed.

tom
 

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

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

2009-06-23 Thread Thomas A. Moulton 
On Wed, 2009-06-24 at 00:55 +0200, Magnus Lundin wrote:
 Thomas A. Moulton wrote:
  On Tue, 2009-06-23 at 15:33 -0700, Rick Altherr wrote:
 

  The community as a whole can easily decide to remove your code,  
  replace it, and relicense.  The community can also choose to follow an  
  alternate interpretation of the license that you may not agree with.   
  Again, you have no rights to declare which interpretation must be  
  followed.  Your rights only extend to bring a court case to decide the  
  claims.  The community must reach a resolution and individual members  
  don't have the rights to assert that theirs must be used.
  
 
  Rick,
 
  The term community and authors are not interchangeable.
 
  What you are suggesting is not a trivial task.
 

 And what is your position in this ? 
 Author or community?
 And what is your opinion ?
 /M
 

I am a developer in a number of (minor patches in most, core developer
in one) Open Source projects (mostly GPLv2) and a developer on a ARM
related project.

I have not even looked at the OpenOCD code yet...

The version of OpenOCD I have does not work for me 100% but I have not
looked at the source yet... I was going to but the windows build
complexity has deterred me from attempting it.

My position is that GPL is the best license to use for most group
projects of this nature (ad hoc developers, etc)
 
My opinion in this is there is no way to control what has been released
in the past and the future releases should adhere to the license.

If this means some limitations then that is acceptable, since the
community will implement features to remove those limitations.

That is a very nature of open source... when a bug pisses me off enough
I take time to find and/or fix it.

It seems while this list is called openocd-development it may have more
users than developers. That is my observation... besides we all were
users before we became developers!

Tom

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

Re: [Openocd-development] License

2009-06-23 Thread Thomas A. Moulton 
LMAO

That could be said for a lot of the recent messages on this list!

A very LOW signal to Noise ratio

Lets start talking about solutions

tom

On Tue, 2009-06-23 at 23:27 +, Photo Leecher wrote:
 People can already do what you say... They can merge+build the latest
 and use FTDI2xx.
 Amount of information: 0
 
  
 
 
 __
 From: Thomas A. Moulton t...@moulton.us
 To: Photo Leecher photoleec...@yahoo.co.uk
 Cc: openocd-development@lists.berlios.de
 Sent: Wednesday, 24 June, 2009 0:24:09
 Subject: Re: [Openocd-development] License
 
 On Tue, 2009-06-23 at 22:59 +, Photo Leecher wrote:
  Your copy would have the exception because you got revision X.
  Revision X+1 would not, and therefore you wouldn't be able to
  distribute FTDI2XX any longer as part of = X+1.
   
  People who want to keep revision X 5 years later can do so, but
 would
  no longer get the latest-and-greatest code.
  
 I could merge any patches I wanted to and release...
 
 Like I said it would be complex.. That was my only point
 
 tom
  
 
 
 
 ___
 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] FT2232 Windows - summary of options

2009-06-21 Thread Thomas A. Moulton 
On Sun, 2009-06-21 at 15:00 +0200, Michael Fischer wrote:
 Hello List,
 
 No response, no windows user here which need FTD2XX support?
 
 Best regards,
 
 Michael

Well 2 points come to mind...

1 - as pointed out before, most of us windows users are interested in
plug and play
2 - this is a developers list... (svn commits and all)

so it is not likely we know we need it...

now... if the question is:

Can we live without Serial Port support

I would say maybe... but then again I am only needing production flash
programming, not debugging, so I can only speak for a small minority.

tom

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

Re: [Openocd-development] OpenOCD + libftdi on Windows

2009-06-20 Thread Thomas A. Moulton 
On Sat, 2009-06-20 at 11:13 +0800, Xiaofan Chen wrote:
 On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopinfreddie_cho...@op.pl wrote:
  Anyway, about that equal performance with libftdi:
  Tested with a ~29kB image on LPC2103 (upload to flash):
 
  libftdi:
Start address 0x3c, load size 29640
Transfer rate: 6 KB/sec, 14820 bytes/write.
  ftd2xx:
Start address 0x3c, load size 29640
Transfer rate: 15 KB/sec, 14820 bytes/write.
 
  So: libftdi is 2.5x slower
 
  Tested with ~114kB image on STM32 (upload to flash):
 
  libftdi:
Start address 0x8000134, load size 114432
Transfer rate: 8 KB/sec, 16347 bytes/write.
  ftd2xx:
 
Start address 0x8000134, load size 114432
Transfer rate: 11 KB/sec, 16347 bytes/write.
 
  Again slower, this time only about 30%, but still, that's nowhere to
  comparable
 

I have been watching this thread with interest.

I do not think the *slower* argument matters at all, the majority of the
devices we are using have small flash chips.

In the example above 114k file at 8KB/sec is 14 seconds vs 11KB/sec is
10 seconds - a difference of 4 seconds - I for one do not care and my
flash is smaller than that!

I am a developer and *could* build openocd for windows, but I can tell
you I would rather not.

If libusb and libftdi works, then please build it and make it available
so it can be used.

Being 30% slower and 100% GPL compatible is very attractive, and for
those who need the fastest, they will take the time to build as private
copy.

But in the real world, if it works, that is often good enough!
But I still encourage the hard core developers to keep pushing, that is
what makes a great reliable tool to use!

And to answer who could be sued? Well if a business takes a non-GPL
complaint tool and redistributes it, then they could be at risk.
So yes the developers are right to be GPL purists, it does matter!


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

[Openocd-development] ADuC702x Flash driver

2009-06-08 Thread Thomas A. Moulton 
I am trying to program the Internal Flash of a ADuC7021
with OpenOCD and an Olimex OpenOCD JTAG TINY A

If I use the other tool chain (IAR) to program the part
I can use OpenOCD to 'verify_image file 0 elf'

But if I try to do a

flash write_image file.elf 0 elf

It tells me there is no flash at 0

flash write_image file.elf 0 elf
No flash at address 0x

No flash at address 0x8000

No flash at address 0x8140

No flash at address 0x9708

wrote 0 byte from file file.elf in 0.00s (nan kb/s)

flash banks returns:

flash banks
#0: aduc702x at 0x0008, size 0xf800, buswidth 0, chipwidth 0

Which is where the flash is physically located, but at Reset (POR)
it maps flash to 0 which where we expect to execute from.

I did try adding an offset to get to the base of flash

flash write_image file.elf 0x8 elf

but that crashes (using windows openocd-ftd2xx)

Open On-Chip Debugger 0.2.0-in-development (2009-05-23-14:36) svn:1888M
(snapshot 1888 from SVN tree + patch, no official release)

Is the maintainer of ADuC702x active?

Anyone else using this driver?

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

Re: [Openocd-development] ADuC702x Flash driver

2009-06-08 Thread Thomas A. Moulton 

[snip]
 ==

 I was using it on a windows machine to which I don't have easy access at
 the moment, but I think it was as above. If you have no luck let me know
 I will find out my exact configuration.

 --

 John Devereux

I made some progress.

I tried your memory writes and it does the same thing either way.

I then disabled the 'work area' and it worked (very very slowly)
(as expected)

I guess if you can check that machine and see if there is anything
important left out...

If needed I should be able to build a local version for testing,
but I'd love to let someone else look at the windows traceback
to see if it is something obvious first...

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