Hi Simon,
On 28/08/2011 4:04 PM, Simon Clubley wrote:
Hello,
I am using OpenOCD with a Olimex ARM-JTAG parallel port JTAG interface
to connect to a LPC3131 based board (the Olimex LPC-H3131) and I am
having problems with a reset based halt timing out.
I wrote the initial lpc3131.cfg that's included quite some time ago when
first getting into the embedded artists ea3131 board. It was also my
first ARM project so don't take the config file as gospel, it's just
what I came up with that worked after a _lot_ of difficulties similar to
yours.
The TRST and SRST lines are both connected on the board so I have used
"reset_config trst_and_srst" in my configuration. (BTW, I noticed that
although there is a reset-init procedure in the lpc3131.cfg script,
there is no definition for reset_config. Is this considered to be a
board level attribute and hence expected to be defined in a board
level script ?)
Ah yeah, that reset-init procedure... I actually don't even use that any
more. It's possibly worth me adding some comments / updates as such to
the file. I still use that file as ut stands, my init sequence just
doens't have a reset init so the function doesn't get called.
My command line (one long command; I put the backslashes in for posting):
/path/to/openocd -c "reset_config trst_and_srst" \
-f interface/parport.cfg -f target/lpc3131.cfg \
-c "adapter_khz 500"
and the resulting output from the telnet interface:
===========================================================
reset init
JTAG tap: lpc3131.cpu tap/device found: 0x07926f0f (mfg: 0x787, part:
0x7926, ver: 0x0)
timed out while waiting for target halted
TARGET: lpc3131.cpu - Not halted
<snip>
If I defer the halt until after the reset by telling OpenOCD
(incorrectly) that SRST pulls TRST, the halt works:
/path/to/openocd -c "reset_config trst_and_srst srst_pulls_trst" \
-f interface/parport.cfg -f target/lpc3131.cfg \
-c "adapter_khz 500"
For what it's worth, my custom hardware is physically wired such that
srst pulls trst (although in hindsight I wish I had them wired
separately) and I always assumed this is why I had issues with resetting
and halting, although perhaps this isn't the case, it might be more
chip/config level issues.
===========================================================
reset init
JTAG tap: lpc3131.cpu tap/device found: 0x07926f0f (mfg: 0x787, part:
0x7926, ver: 0x0)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x6000001f pc: 0x1102e114
MMU: disabled, D-Cache: disabled, I-Cache: enabled
Running reset init script for LPC3131
cpsr (/32): 0xA00000D3
pc (/32): 0x11029000
background polling: off
TAP: lpc3131.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xa00000d3 pc: 0x11029000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
===========================================================
While I have a workaround with srst_pulls_trst, it would be nice to
fix the real problem.
Does anyone have any ideas ?
Thanks,
Simon.
Actually, your problem may be directly caused by the delay settings in
the file:
jtag_nsrst_delay 1000
jtag_ntrst_delay 0
try setting both to 500, and bigger/smaller settings. The delay required
will be dependent on internal chip delays as well as speed of any
external reset hardware (I've just got caps with pullups on the my reset
lines, not even any proper supervisor chips - extreme cost cutting).
For your reference, my init scrip currently used
(a3p060_lpc3131_jtagkey.cfg - not in openocd distro):
Note: I have an fpga in my jtag chain as well as the lpc3131
source [find interface/jtagkey.cfg]
jtag_khz 1000
reset_config srst_only srst_pulls_trst
# Is the LPC on the chain?
source [find target/lpc3131.cfg]
#jtag newtap a3p060 tap -irlen 8 -expected-id 0x129121cf
# FPGA Tap: A3PN060 A3P060
jtag newtap fpga tap -irlen 8 -expected-id 0x1b9521cf -expected-id
0x129121cf
init
#scan_chain
openocd.exe -f a3p060_lpc3131_jtagkey.cfg
I use eclipse and gdp to connect to openocd on the telnet port, with the
"gdb hardware debugging" plugin. On the startup pane of this I have
[checked] Reset and Delay (seconds): [2]
[checked] Halt
<in the init commands box>
mon reg pc 0x11029000
tbreak c_entry
mon reg pc 0x11029000
[checked] Load image ..... project file
[checked] Load Symbols .... project file
[unchecked] Set Program Counter
[unchecked] Set Breakpoint at: ...
[unchecked] Resume
<Run Commands box>
mon sleep 100
mon reg pc 0x11029000
mon reg cpsr 0x000000d7
continue
All the extra setting of pc and arm core mode may be more than required
in places, but this had given me a perfectly reliable connection
sequence in eclipse. Earlier with less/different commands it would
sometimes connect, other times have halt timed out etc.
Good Luck,
Andrew Leech
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
