Hi Guys,

I have finally had a chance to do some testing and found the using

reset_config trst_and_srst separate srst_gates_jtag srst_open_drain 
connect_deassert_srst

works for connecting to the card but I have a new problem. Because of reset 
issue with the board I am using (waiting on new board with reset fixed) in 
order to reset the board, we are forced to press
and hold the reset button. In the OpenOCD console, do the following
    jtag_reset 1 0
    irscan mAUC.cpu 0x0c ;# Force an EJTAGBOOT
then reset button is released. This works fine using " reset_config srst_only 
separate srst_gates_jtag srst_open_drain connect_deassert_srst" without the 
changes to ftdi.c

I am able to cause the crash by entering the commands manually and it is the 
"irscan" ("irscan mAUC.cpu 0x0c") command that causes OpenOCD to crash.

Below is crash information:

$ ./openocd.exe -f busblaster.cfg -f mAUC.cfg -c "gdb_memory_map enable" -c 
"init"
Open On-Chip Debugger 0.9.0-dev-00098-ge03eb89-dirty (2014-07-16-16:56)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 15000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
connect_deassert_srst
scan delay: 20000 nsec
running in fast queued mode
mAUC.tcl(updated 20140508)
    reb                         (Setup for an EJTAGBOOT indicated reset via 
Sharta-A S8.)
    rnb                         (Setup for a NORNALBOOT indicated reset via 
Sharta-A S8.)
    fastq <mode>          (mode 0/1 disables/enables 'fast queued mode'.)
    myload                      (Example of FASTDATA load, verify, invalidate.)
    <CP0RegName> ?<new-value>?  (All CP0 registers now accessible by name.)
    cp0                         (dump all CP0 registers.)
Info : clock speed 15000 kHz
Info : JTAG tap: mAUC.cpu tap/device found: 0x00000001 (mfg: 0x000, part: 
0x0000, ver: 0x0)
Info : accepting 'telnet' connection on tcp/4444
Assertion failed: jtag_trst == 0, file core.c, line 340

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I'm I missing should on the modified reset_config command or is this an new 
problem?

Thanks,
Kent

-----Original Message-----
From: Paul Fertser [mailto:[email protected]] 
Sent: Tuesday, July 08, 2014 10:32 PM
To: Andreas Fritiofson
Cc: Kent Brinkley; [email protected]
Subject: Re: [OpenOCD-devel] jtag/drivers/ftdi: do not touch unavailable reset 
signals

Hi,

On Wed, Jul 09, 2014 at 01:08:21AM +0200, Andreas Fritiofson wrote:
> The above initializes nTRST to Hi-Z and with the mentioned change, 
> they will not get touched unless reset_config includes them.

And I guess that's the right thing to do.

> Can you check
> 1) That you have sufficient pull-up on the nTRST line? (check 
> visually, measure nTRST voltage after openocd start).

Yes, and if you have nTRST actually connected you should just include it in the 
reset_config if you count on it to provide the stable level, that will work 
regardless of the pull-up. And if you prefer to not connect an extra wire, then 
you need to have the pull-up on the nTRST line either on the target board or 
inside the SoC (as e.g. stm32's have).

> 2) If "reset_config srst_and_trst separate srst_gates_jtag 
> srst_open_drain connect_deassert_srst" makes any difference.
> 3) If "reset_config srst_and_trst separate srst_gates_jtag 
> srst_open_drain trst_push_pull connect_deassert_srst" makes any difference.

I think both are the same and are default + srst_and_trst, so basically the 
test would be to change srst_only to srst_and_trst in the config.

HTH
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[email protected]

------------------------------------------------------------------------------
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to