Re: [Openocd-development] [PATCH] dsp563xx: fix alignment warnings

2011-03-15 Thread Domen Puncer 
On Mon, Mar 14, 2011 at 15:33, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
 ---
  src/target/dsp563xx.c |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
 index cb2025e..19f793e 100644
 --- a/src/target/dsp563xx.c
 +++ b/src/target/dsp563xx.c
...
 @@ -1466,8 +1466,8 @@ static int dsp563xx_read_memory(struct target *target, 
 int mem_type, uint32_t ad

        for(i=0,i1=0;icount;i+=2,i1++)
        {
 -               ((uint32_t*)buffer)[i] = ((uint32_t*)buffer_y)[i1];
 -               ((uint32_t*)buffer)[i] = ((uint32_t*)buffer_x)[i1];
 +               buf_set_u32(buffer + i*sizeof(uint32_t), 0, 32, 
 buf_get_u32(buffer_y+i1*sizeof(uint32_t), 0, 32));
 +               buf_set_u32(buffer + i*sizeof(uint32_t), 0, 32, 
 buf_get_u32(buffer_x+i1*sizeof(uint32_t), 0, 32));

Was this ever correct? It looks like the 'x' line should have (i+1), like below.

        }

        free(buffer_y);
 @@ -1587,8 +1587,8 @@ static int dsp563xx_write_memory(struct target *target, 
 int mem_type, uint32_t a

        for(i=0,i1=0;icount;i+=2,i1++)
        {
 -               ((uint32_t*)buffer_y)[i1] = ((uint32_t*)buffer)[i];
 -               ((uint32_t*)buffer_x)[i1] = ((uint32_t*)buffer)[i+1];
 +               buf_set_u32(buffer_y + i1*sizeof(uint32_t), 0, 32, 
 buf_get_u32(buffer+i*sizeof(uint32_t), 0, 32));
 +               buf_set_u32(buffer_x + i1*sizeof(uint32_t), 0, 32, 
 buf_get_u32(buffer+(i+1)*sizeof(uint32_t), 0, 32));
        }

        err = 
 dsp563xx_write_memory_core(target,MEM_Y,address,size,count/2,buffer_y);


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

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-12-13 Thread Domen Puncer 
On Thu, Nov 25, 2010 at 15:45, Domen Puncer domen.pun...@visionect.si wrote:
 I can reliably reproduce this one with:
 jtag_khz 1000
 verify_image my_image.elf
 # some prints about too high clock
 reset init
 # openocd aborts

Additional info.

valgrind:
==32465== Invalid free() / delete / delete[]
==32465==at 0x4C270BD: free (vg_replace_malloc.c:366)
==32465==by 0x4B4CD9: Jim_EvalObj (jim.c:527)
==32465==by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)
==32465==by 0x424AA4: handle_reset_command (target.c:505)
==32465==by 0x42F448: script_command_run (command.c:627)
==32465==by 0x4B4E30: Jim_EvalObj (jim.c:9398)
==32465==by 0x4B60E8: Jim_EvalCoreCommand (jim.c:11557)
==32465==by 0x4B4E30: Jim_EvalObj (jim.c:9398)
==32465==by 0x4B83CC: Jim_CatchCoreCommand (jim.c:12372)
==32465==by 0x4B4E30: Jim_EvalObj (jim.c:9398)
==32465==by 0x4B6F8B: Jim_EvalExpression (jim.c:8227)
==32465==by 0x4B7482: Jim_GetBoolFromExpr (jim.c:8269)
==32465==  Address 0x7feffeb00 is on thread 1's stack
==32465==

And it's really bugging me, because I can't figure out where exactly.

It disappears if I configure jimtcl with ./configure CFLAGS=-g, also
disappeared when I inserted some printfs in Jim_EvalObj.

I do have some questions about some code:
1.
In jim.c Jim_EvalObj there's a loop:

/* Now copy in the expanded version */
for (k = 0; k  len; k++) {
argv[j++] = wordObjPtr-internalRep.listValue.ele[k];
Jim_IncrRefCount(wordObjPtr-internalRep.listValue.ele[k]);
}

but code only allocates space for extra len-1 objects.


2.
src/target/target.c:
In handle_reg_command, there is:
/* display a register */
if ((CMD_ARGC == 1) || ((CMD_ARGC == 2)  !((CMD_ARGV[1][0] = '0')
 (CMD_ARGV[1][0] = '9'

it seems to be that should be written as:
if ((CMD_ARGC == 1) || ((CMD_ARGC == 2)  !((CMD_ARGV[0][0] = '0')
 (CMD_ARGV[0][0] = '9'
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-12-13 Thread Domen Puncer 
On Mon, Dec 13, 2010 at 12:47, Steve Bennett ste...@workware.net.au wrote:

 On 13/12/2010, at 8:12 PM, Domen Puncer wrote:

 but code only allocates space for extra len-1 objects.

 There is already one slot allocated for the arg. If the arg expands to 'len'
 elements, we only need to allocate 'len-1' more.

OK then, just seemed fishy.


 Can we see the code being evaluated here?
 ==32465==    by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)


 9643 else {
 9644 retval = Jim_EvalObj(interp, scriptObjPtr);
 9645 }
 9646 Jim_DecrRefCount(interp, scriptObjPtr);
 9647 return retval;
 9648 }


And the error happens (as the previous gdb backtrace shows) in
Jim_Free, almost at the end of Jim_EvalObj:

if (argv != sargv) {
Jim_Free(argv);
argv = sargv;
}

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

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-12-13 Thread Domen Puncer 
On Mon, Dec 13, 2010 at 20:32, Steve Bennett ste...@workware.net.au wrote:
 On 13/12/2010, at 11:00 PM, Domen Puncer wrote:

 On Mon, Dec 13, 2010 at 12:47, Steve Bennett ste...@workware.net.au wrote:

 Can we see the code being evaluated here?
 ==32465==    by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)


 9643     else {
 9644         retval = Jim_EvalObj(interp, scriptObjPtr);
 9645     }
 9646     Jim_DecrRefCount(interp, scriptObjPtr);
 9647     return retval;
 9648 }

 Sorry, I meant the Tcl script that is being evaluated at that point.

Oh, I don't know.
How do I find out?
It was after verify_image and reset init commands executed with
too high clock (so there were some errors printed, as mentioned in
original post).


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

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-12-13 Thread Domen Puncer 
On Mon, Dec 13, 2010 at 21:17, Steve Bennett ste...@workware.net.au wrote:
 On 14/12/2010, at 5:50 AM, Domen Puncer wrote:

 On Mon, Dec 13, 2010 at 20:32, Steve Bennett ste...@workware.net.au wrote:
 On 13/12/2010, at 11:00 PM, Domen Puncer wrote:

 On Mon, Dec 13, 2010 at 12:47, Steve Bennett ste...@workware.net.au 
 wrote:

 Can we see the code being evaluated here?
 ==32465==    by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)


 9643     else {
 9644         retval = Jim_EvalObj(interp, scriptObjPtr);
 9645     }
 9646     Jim_DecrRefCount(interp, scriptObjPtr);
 9647     return retval;
 9648 }

 Sorry, I meant the Tcl script that is being evaluated at that point.

 Oh, I don't know.
 How do I find out?
 It was after verify_image and reset init commands executed with
 too high clock (so there were some errors printed, as mentioned in
 original post).

 Never mind. I see this in target.c:

    sprintf(buf, ocd_process_reset %s, n-name);
    retval = Jim_Eval(cmd_ctx-interp, buf);

 So it is executing a pretty simple script.

 Is there any chance you can build just jim.c with '-g -O0' and rerun with 
 valgrind?

I tried that before, well... actually only '-g', valgrind reported no problems.
It's a tricky one, isn't it :-)


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

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-12-01 Thread Domen Puncer 
On Wed, Dec 1, 2010 at 08:41, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Can you try with a 32 bit OpenOCD executable?

I don't have a 32-bit linux box around. Can someone share a binary?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-11-27 Thread Domen Puncer 
On Fri, Nov 26, 2010 at 13:29, Spencer Oliver s...@spen-soft.co.uk wrote:
 Just tried to reproduce this on two boards with your exact config - all ok.

You tried setting clock to too high etc., as described in original
post? It works fine otherwise, it's just this one bug I noticed while
playing with jtag_khz


 Have a read of BUGS in the openocd src directory on details about providing
 a backtrace.

OK, I'll do that when I'm back at work.


 Cheers
 Spen




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

Re: [Openocd-development] Aborted; stm32 with too high clock

2010-11-26 Thread Domen Puncer 
On Thu, Nov 25, 2010 at 19:29, Peter Stuge pe...@stuge.se wrote:
 Domen Puncer wrote:
 I can reliably reproduce this one with:
 jtag_khz 1000
 verify_image my_image.elf
 # some prints about too high clock
 reset init
 # openocd aborts

 It would be helpful if you could recompile openocd with debugging
 symbols, and send a backtrace of the output from that.

Without digging through build system, how do I do that?




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




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

[Openocd-development] Aborted; stm32 with too high clock

2010-11-25 Thread Domen Puncer 
I can reliably reproduce this one with:
jtag_khz 1000
verify_image my_image.elf
# some prints about too high clock
reset init
# openocd aborts

Open On-Chip Debugger 0.5.0-dev-00620-g1892a2b (2010-11-25-15:32)
...
Error: 654 48021 adi_v5_jtag.c:335 jtagdp_transaction_endcheck():
MEM_AP_CSW 0x2342, MEM_AP_TAR 0x8008000
User : 655 48023 target.c:1904 handle_target(): Polling target failed,
GDB will be halted. Polling again in 100ms
Debug: 656 48023 target.c:1024 target_call_event_callbacks(): target
event 2 (gdb-halt)
User : 657 48228 target.c:1915 handle_target(): Polling succeeded again
Debug: 658 51139 gdb_server.c:2181 gdb_input_inner(): received packet:
'qRcmd,726573657420696e6974'
Debug: 659 51143 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_reset init
Debug: 660 51143 command.c:156 script_debug(): command - reset ocd_reset init
Debug: 662 51145 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_target names
Debug: 663 51145 command.c:156 script_debug(): command - ocd_target
ocd_target names
Debug: 664 51145 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_stm32.cpu invoke-event reset-start
Debug: 665 51145 command.c:156 script_debug(): command - ocd_stm32.cpu
ocd_stm32.cpu invoke-event reset-start
Debug: 666 51145 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_jtag arp_init-reset
Debug: 667 51145 command.c:156 script_debug(): command - ocd_jtag
ocd_jtag arp_init-reset
Debug: 668 51145 core.c:1509 jtag_init_reset(): Initializing with hard
TRST+SRST reset
Debug: 669 51145 core.c:727 jtag_add_reset(): JTAG reset with TLR
instead of TRST
Debug: 670 51145 core.c:330 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 671 51146 core.c:1414 jtag_init_inner(): Init JTAG chain
Debug: 672 51146 core.c:330 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 673 51147 core.c:1049 jtag_examine_chain(): DR scan
interrogation for IDCODE/BYPASS
Debug: 674 51147 core.c:330 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 675 51150 core.c:949 jtag_examine_chain_display(): JTAG tap:
stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver:
0x3)
Info : 676 51150 core.c:949 jtag_examine_chain_display(): JTAG tap:
stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver:
0x0)
Debug: 677 51150 core.c:1213 jtag_validate_ircapture(): IR capture
validation scan
Debug: 678 51152 core.c:1274 jtag_validate_ircapture(): stm32.cpu: IR
capture 0x01
Debug: 679 51152 core.c:1274 jtag_validate_ircapture(): stm32.bs: IR
capture 0x01
Debug: 680 51152 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_stm32.cpu cget -chain-position
Debug: 681 51152 command.c:156 script_debug(): command - ocd_stm32.cpu
ocd_stm32.cpu cget -chain-position
Debug: 682 51152 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_jtag tapisenabled stm32.cpu
Debug: 683 51152 command.c:156 script_debug(): command - ocd_jtag
ocd_jtag tapisenabled stm32.cpu
Debug: 684 51152 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_stm32.cpu arp_examine
Debug: 685 51152 command.c:156 script_debug(): command - ocd_stm32.cpu
ocd_stm32.cpu arp_examine
Debug: 686 51152 arm_adi_v5.c:914 ahbap_debugport_init():
Debug: 687 51154 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_stm32.cpu invoke-event reset-assert-pre
Debug: 688 51154 command.c:156 script_debug(): command - ocd_stm32.cpu
ocd_stm32.cpu invoke-event reset-assert-pre
Debug: 689 51154 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_stm32.cpu cget -chain-position
Debug: 690 51154 command.c:156 script_debug(): command - ocd_stm32.cpu
ocd_stm32.cpu cget -chain-position
Debug: 691 51154 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_jtag tapisenabled stm32.cpu
Debug: 692 51154 command.c:156 script_debug(): command - ocd_jtag
ocd_jtag tapisenabled stm32.cpu
Debug: 693 51154 command.c:156 script_debug(): command - ocd_command
ocd_command type ocd_stm32.cpu arp_reset assert 1
Debug: 694 51154 command.c:156 script_debug(): command - ocd_stm32.cpu
ocd_stm32.cpu arp_reset assert 1
Debug: 695 51155 cortex_m3.c:926 cortex_m3_assert_reset():
target-state: unknown
Debug: 696 51156 adi_v5_jtag.c:274 jtagdp_transaction_endcheck():
jtag-dp: CTRL/STAT error, 0xf003
Debug: 697 51156 adi_v5_jtag.c:297 jtagdp_transaction_endcheck():
MEM-AP Cached values: ap_bank 0x10, ap_csw 0xa202, ap_tar
0xe000edf0
Error: 698 51156 adi_v5_jtag.c:301 jtagdp_transaction_endcheck():
JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Debug: 699 51158 adi_v5_jtag.c:320 jtagdp_transaction_endcheck():
jtag-dp: CTRL/STAT 0xf001
Error: 700 51160 adi_v5_jtag.c:335 jtagdp_transaction_endcheck():
MEM_AP_CSW 0x2342, MEM_AP_TAR 0x8008000
*** glibc detected *** /home/domen/tmp/openocd.git/src/openocd:
munmap_chunk(): invalid pointer: 0x7fffc463b100 ***

Re: [Openocd-development] segfault when gdb connects, but target is not connected

2010-11-14 Thread Domen Puncer 
On Sat, Nov 13, 2010 at 13:08, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Does the attached patch fix the problem?

Jup, did the trick.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] segfault when gdb connects, but target is not connected

2010-11-11 Thread Domen Puncer 
On Thu, Nov 11, 2010 at 08:48, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Try:

 openocd -c interface dummy -c gdb_memory_map disable -f target/stm32.cfg


No segfault in this case.

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

[Openocd-development] segfault when gdb connects, but target is not connected

2010-11-10 Thread Domen Puncer 
Hello,

I can reproduce this one easily, amontec tiny dongle, stm32 target,
which isn't connected. Fire up gdb to connect to openocd, and this
happens:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/domen/tmp/openocd.git/src/openocd
Open On-Chip Debugger 0.5.0-dev-00583-ge7b2958 (2010-11-10-09:09)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
100 kHz
Info : clock speed 100 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Info : accepting 'gdb' connection from 
Error: Target not examined yet
Error: auto_probe failed -4

Error: Connect failed. Consider setting up a gdb-attach event for the
target to prepare target for GDB connect.
Error: attempted 'gdb' connection rejected
Polling target failed, GDB will be halted. Polling again in 6300ms

Program received signal SIGSEGV, Segmentation fault.
gdb_frontend_halted (target=0x7717f0, connection=0x7612b0) at gdb_server.c:749
749             if (gdb_connection-frontend_state == TARGET_RUNNING)
(gdb) bt
#0  gdb_frontend_halted (target=0x7717f0, connection=0x7612b0) at
gdb_server.c:749
#1  0x00427dbb in gdb_target_callback_event_handler
(target=0x7717f0, event=TARGET_EVENT_GDB_HALT, priv=0x7612b0) at
gdb_server.c:783
#2  0x00424ecf in target_call_event_callbacks
(target=0x7717f0, event=TARGET_EVENT_GDB_HALT) at target.c:1031
#3  0x00425cb6 in handle_target (priv=value optimized out)
at target.c:1909
#4  0x00423ce3 in target_call_timer_callback (checktime=1) at
target.c:1056
#5  target_call_timer_callbacks_check_time (checktime=1) at target.c:1085
#6  0x004261ff in server_loop (command_context=value
optimized out) at server.c:433
#7  0x00404a29 in openocd_main (argc=value optimized out,
argv=0x7fffdf38) at openocd.c:356
#8  0x77464c4d in __libc_start_main (main=value optimized
out, argc=value optimized out, ubp_av=value optimized out,
init=value optimized out, fini=value optimized out,
rtld_fini=value optimized out, stack_end=0x7fffdf28) at
libc-start.c:226
#9  0x004046d9 in _start ()
(gdb) p gdb_connection
$1 = (struct gdb_connection *) 0x6e6961676120676e
(gdb) i lo
gdb_connection = 0x6e6961676120676e
(gdb) i registers
rax            0x0      0
rbx            0x6e6961676120676e       7955997313365731182
rcx            0x7751e500   140737342727424
rdx            0x7612b0 7738032
rsi            0x7612b0 7738032
rdi            0x7717f0 7804912
rbp            0x7612b0 0x7612b0
rsp            0x7fffdc30   0x7fffdc30
r8             0x7612a0 7738016
r9             0x4cd949 5036361
r10            0x30303336206e6920       3472331620268009760
r11            0x246    582
r12            0x7717f0 7804912
r13            0x0      0
r14            0x7fffdd60   140737488346464
r15            0x7fffdde0   140737488346592
rip            0x427cbd 0x427cbd gdb_frontend_halted+29
eflags         0x10206  [ PF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb)




And a longer output with --debug=3
$ gdb --args ~/tmp/openocd.git/src/openocd --debug=3
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/domen/tmp/openocd.git/src/openocd...done.
(gdb) r
Starting program: /home/domen/tmp/openocd.git/src/openocd --debug=3
Open On-Chip Debugger 0.5.0-dev-00583-ge7b2958 (2010-11-10-09:09)
Licensed under GNU GPL v2
For bug reports, read
       http://openocd.berlios.de/doc/doxygen/bugs.html
User : 11 1 command.c:566 command_print(): debug_level: 3
Debug: 12 1 configuration.c:45 add_script_search_dir(): adding
/home/domen/.openocd
Debug: 13 1 configuration.c:45 add_script_search_dir(): adding
/usr/local/share/openocd/site
Debug: 14 1

Re: [Openocd-development] segfault when gdb connects, but target is not connected

2010-11-10 Thread Domen Puncer 
On Wed, Nov 10, 2010 at 22:59, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Could you try reproducing this problem using the dummy driver?

 openocd -c interface dummy -f yourconfig.cfg

Gdb can't connect to openocd when using a dummy driver.

My config, in case it matters:

interface ft2232
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8

source [find target/stm32.cfg]

jtag_khz 100


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

[Openocd-development] flash programming clock, and how it really matters for lpc2000, although things may appear to just work

2010-01-21 Thread Domen Puncer 
Hello!

In hope noone will deal with this issue again :-)

I've never paid attention to clock parameter of flash bank, since it
just worked... well, with some odd problems, like code jumping to random
places, read only data being wrong etc - and that happened RARELY.

So I began suspecting a flash issue, and wrote a simple crc16 checker
app, and surely, crc16 differed (in same app run, just different crc16
iteration), more so with higher clocks, and MAM enabled.

I sought help, and Paul Curtis suggested this might be the issue
http://tech.groups.yahoo.com/group/lpc2000/message/47056

I would never have guessed that write can be successful, and fail only
when reading, and in different ways when reading the same area multiple
times.

So, a heads up. Flash timings matter, at least for lpc2000.
And since you don't know how chip is set up when jtag catches it, you
have to play with PLL setting.

My current lpc2387 config, if someone finds it useful:


# NXP LPC2387 ARM7TDMI-S with 512kB Flash and 32kB Local On-Chip SRAM (58kB 
total), clocked with 72MHz PLL from internal oscillator

if { [info exists CHIPNAME] } {
set  _CHIPNAME $CHIPNAME
} else {
set  _CHIPNAME lpc2387
}

if { [info exists ENDIAN] } {
set  _ENDIAN $ENDIAN
} else {
set  _ENDIAN little
}

if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x4f1f0f0f
}

#delays on reset lines
jtag_nsrst_delay 200
jtag_ntrst_delay 200

# LPC2000 - SRST causes TRST
reset_config trst_and_srst srst_pulls_trst

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

# LPC2378 has 32kB of SRAM on its main system bus (so-called Local On-Chip SRAM)
$_TARGETNAME configure -work-area-phys 0x4000 -work-area-size 0x8000 
-work-area-backup 0

$_TARGETNAME configure -event reset-start {
jtag_khz 20
}

$_TARGETNAME configure -event reset-init {

# Force target into ARM state
arm core_state arm
#do not remap 0x-0x0020 to anything but the flash
mwb 0xE01FC040 0x01

# get it up to 72 MHz
mww 0xe01fc080 0x1  # PLLCON
mww 0xe01fc08c 0xaa # PLLFEED
mww 0xe01fc08c 0x55 # PLLFEED

mww 0xe01fc080 0x0  # PLLCON
mww 0xe01fc08c 0xaa # PLLFEED
mww 0xe01fc08c 0x55 # PLLFEED
mww 0xe01fc10c 0# CLKSRCSEL - internal 4 MHz

mww 0xe01fc084 0x0023   # PLLCFG *36/1 (288)
mww 0xe01fc08c 0xaa # PLLFEED
mww 0xe01fc08c 0x55 # PLLFEED

mww 0xe01fc080 0x1  # PLLCON enable
mww 0xe01fc08c 0xaa # PLLFEED
mww 0xe01fc08c 0x55 # PLLFEED
mww 0xe01fc104 0x3  # CCLKCFG (/4 - 72)
sleep 200   # wait for pll lock

mww 0xe01fc080 0x3  # PLLCON enable | connect
mww 0xe01fc08c 0xaa # PLLFEED
mww 0xe01fc08c 0x55 # PLLFEED

jtag_khz 12000
# 72MHz / 6 = 12MHz, so use 12000
}

# LPC2378 has 512kB of FLASH, but upper 8kB are occupied by bootloader.
# In boot loader the clock is 14.748 MHz
#flash bank lpc2000 base size 0 0 target# variant
set _FLASHNAME $_CHIPNAME.flash
#flash bank $_FLASHNAME lpc2000 0x0 0x0007D000 0 0 $_TARGETNAME lpc2000_v2 
14748 calc_checksum
flash bank $_FLASHNAME lpc2000 0x0 0x0007D000 0 0 $_TARGETNAME lpc2000_v2 72000 
calc_checksum

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