Re: [Openocd-development] Halt times out on a LPC3131 board during reset

[Andrew L. <cor...@gm...>]

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