Products Used:                 ARM-USB-OCD 
(http://www.olimex.com/dev/arm-usb-ocd.html)

LPC-H2148 (http://www.olimex.com/dev/lpc-h2148.html) 

 

 

 

Background:                       The arm-usb-ocd.cfg and lpc2148.cfg files 
provided with the release 0.1.0 (packed in with the ARM-USB-OCD device) were 
used in attempt to initiate communication to the lpc-h2148 target.  openOCD was 
configured as follows:

 

./configure --enable-maintainer-mode --disable-werror --disable-shared 
--enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/openocd/ftd2xx CC="gcc 
-mno-cygwin" CFLAGS="-O0 -g -Wall"

 

 

 

Issue:                    While openOCD is able to connect to the lpc-h2148 via 
the JTAG interface and code is able to be flashed and run without problems, it 
doesn't appear that the device is talking to the chip correctly, as memory 
addresses seem to change values as displayed below ...

 

telnet localhost 4444

 

Open On-Chip Debugger

> armv4_5 disassemble 0x00000000 16

0x00000000      0x73cff80c      BICVC r15, r15, #0xc0000

 

0x00000008      0x73cff80c      BICVC r15, r15, #0xc0000

0x0000000c      0x73cff80c      BICVC r15, r15, #0xc0000

0x00000010      0x73cff80c      BICVC r15, r15, #0xc0000

should never reach this point

 

0x00000018      0x738ffff8      ORRVC r15, r15, #0x3e0

 

0x00000020      0x00000020      ANDEQ r0, r0, r0, LSR #0x20

0x00000024      0x00000072      ANDEQ r0, r0, r2, ROR r0

0x00000028      0x00000070      ANDEQ r0, r0, r0, ROR r0

0x0000002c      0x00000072      ANDEQ r0, r0, r2, ROR r0

0x00000030      0x00000072      ANDEQ r0, r0, r2, ROR r0

0x00000034      0x000000fc      STREQD r0, [r0], -r12

0x00000038      0x0000006e      ANDEQ r0, r0, r14, RRX

0x0000003c      0x00000000      ANDEQ r0, r0, r0

> mdh 0x00000000 8

0x00000000: 780c 73cf 780c 73cf 780c 73df f81c 73cf       ç========== different 
values exist between the same memory locations

> mdh 0x00000000 8

0x00000000: 780c 73cf 780c 73cf 7018 e59f f81c f7df       ç==========

> mdh 0x00000000 8

0x00000000: f81c f3cf 780c 73cf 780c 73cf 780c 73cf

> 

 

 

The last section shows something strange ...  a memory dump of address 
0x00000000 was performed, which should contain the reset vector.  Repeated mdh 
commands give different results.  I can tell you that the flash itself is fine, 
the device runs code without any problem.  RAM reads and writes do the same 
thing - you write a byte or word to RAM, what you read back isn't what you 
wrote, and what's read back changes from read to read.  Furthermore, what it's 
showing, it appears, is NOT what's actually in the flash.  

 

The LPC-H2148 was programmed using the H-JTAG programming tool with files in 
hex format (lpc2148 port of the lpcusb stack 
http://sourceforge.net/projects/lpcusb/files/target/v20070727/target-20070727.tar.gz/download
 was flashed), and the code executes just fine...no problems in its operation.  
The first word should contain an LDR instruction to the reset vector.  (The 
standard arm-gcc startup code).

 

When openocd starts, here's what it says (with included -d3 debugger option):

 

C:\gccfd\openocd\bin\lpcopenocd>openocd-ftd2xx -d3 -f arm-usb-ocd.cfg -f 
lpc2148.cfg

Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported

$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $

Debug:   5 0 command.c:432 command_run_line(): script arm-usb-ocd.cfg

Debug:   6 0 configuration.c:87 open_file_from_path(): opened arm-usb-ocd.cfg

Debug:   8 0 command.c:432 command_run_line(): interface ft2232

Debug:   10 0 command.c:432 command_run_line(): ft2232_device_desc "Olimex 
OpenOCD JTAG A"

Debug:   12 16 command.c:432 command_run_line(): ft2232_layout "olimex-jtag"

Debug:   14 16 command.c:432 command_run_line(): ft2232_vid_pid 0x15BA 0x0003

Debug:   16 16 command.c:432 command_run_line(): script lpc2148.cfg

Debug:   17 16 configuration.c:87 open_file_from_path(): opened lpc2148.cfg

Debug:   19 16 command.c:432 command_run_line(): jtag_nsrst_delay 200

Debug:   21 16 command.c:432 command_run_line(): jtag_ntrst_delay 200

Debug:   23 16 command.c:432 command_run_line(): reset_config trst_and_srst 
srst_pulls_trst

Debug:   25 16 command.c:432 command_run_line(): jtag_reset 1 1

Debug:   26 16 ft2232.c:1374 ft2232_init_ftd2xx(): 'ft2232' interface using 
FTD2XX with 'olimex-jtag' layout (15ba:0003)

Debug:   27 47 ft2232.c:1463 ft2232_init_ftd2xx(): current latency timer: 2

Debug:   28 47 ft2232.c:1810 olimex_jtag_init(): 80 08 1b

Debug:   29 47 ft2232.c:1853 olimex_jtag_init(): 82 09 0f

Debug:   30 47 ft2232.c:253 ft2232_speed(): 86 00 00

Debug:   31 63 jtag.c:992 jtag_add_reset(): SRST line asserted

Debug:   32 63 jtag.c:1015 jtag_add_reset(): TRST line asserted

Debug:   33 63 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG 
controller reset (TLR or TRST)

Debug:   34 63 ft2232.c:1037 olimex_jtag_reset(): trst: 1, srst: 1, 
high_output:0x02, high_direction: 0x0f

Debug:   36 63 command.c:432 command_run_line(): jtag_reset 0 0

Debug:   37 79 jtag.c:996 jtag_add_reset(): SRST line released

Debug:   38 79 ft2232.c:1037 olimex_jtag_reset(): trst: 0, srst: 0, 
high_output: 0x09, high_direction: 0x0f

Debug:   40 485 command.c:432 command_run_line(): jtag_device 4 0x1 0xf 0xe

Debug:   42 485 command.c:432 command_run_line(): target arm7tdmi little 
run_and_init 0 arm7tdmi-s_r4

Debug:   44 485 command.c:432 command_run_line(): run_and_halt_time 0 30

Debug:   46 485 command.c:432 command_run_line(): target_script 0 reset 
event/lpc2148_reset.script

Debug:   48 485 command.c:432 command_run_line(): working_area 0 0x40000000 
0x4000 nobackup

Debug:   50 485 command.c:432 command_run_line(): flash bank lpc2000 0x0 
0x7d0000 0 0 lpc2000_v2 14765

Debug:   52 485 command.c:432 command_run_line(): init

Debug:   53 485 openocd.c:102 handle_init_command(): target init complete

Debug:   54 485 openocd.c:109 handle_init_command(): jtag interface init 
complete

Debug:   55 485 jtag.c:1537 jtag_init_inner(): Init JTAG chain

Debug:   56 485 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG 
controller reset (TLR or TRST)

Debug:   57 485 jtag.c:1295 jtag_reset_callback(): -

Debug:   58 500 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG 
controller reset (TLR or TRST)

Debug:   59 500 jtag.c:1295 jtag_reset_callback(): -

Info:    60 500 jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x9f3f1f1f

(Manufacturer: 0x78f, Part: 0xf3f1, Version: 0x9)

Debug:   61 500 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG 
controller reset (TLR or TRST)

Debug:   62 500 jtag.c:1295 jtag_reset_callback(): -

Debug:   63 500 openocd.c:116 handle_init_command(): jtag init complete

Error:   64 500 embeddedice.c:191 embeddedice_build_reg_cache(): unknown 
EmbeddedICE version (comms ctrl: 0x80000000)

Debug:   65 516 openocd.c:119 handle_init_command(): jtag examine complete

Debug:   66 516 openocd.c:126 handle_init_command(): flash init complete

Debug:   67 516 openocd.c:130 handle_init_command(): NAND init complete

Debug:   68 516 openocd.c:134 handle_init_command(): pld init complete

Warning: 69 516 telnet_server.c:624 telnet_init(): no telnet port specified, 
using default port 4444

Warning: 70 532 gdb_server.c:2021 gdb_init(): no gdb port specified, using 
default port 3333

Debug:   71 532 gdb_server.c:2036 gdb_init(): gdb service for target arm7tdmi 
at port 3333

 

 

It's reporting that it found a JTAG device, manufacturer, and version.  I'm not 
entirely sure these make sense for an LPC2148.  The issue here seems to be 
something to do with the openOCD configuration file, and finding out exactly 
what it should look like for this combination of hardware - an Olimex 
ARM-USB-OCD, Windows XP machine, and an Olimex LPC-H2148 target.

 

 

Further, I have also downloaded and set up the 0.2.0 release in hopes that this 
issue would be resolved, but similar circumstances still occur (i.e. changing 
memory addresses at the same location after multiple reads).  If anyone could 
assist in any way possible, it would be greatly appreciated as many hours have 
been spent attempting to remedy these issues, and hopefully help others who may 
be having similar issues as well. 

 

 

Thank you in advance for your help!

 

 

Sincerely,

Kevin

 

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to