OpenOCD and Amontec JTagkey and ARM7 not working

Martin_Ludwig · July 31, 2006, 4:18pm

Hello,

iÂ´ve a problem with openocd connected to an arm7 board (ethernut3) via amontec jtagkey.

when i start openocd i get

Warning: jtag.c:986 jtag_read_buffer(): value captured during scan didn’t pass the requested check: captured: 0f check_value: 01 check_mask: 0f

after that i use telnet to test some things

poll

soft_reset_halt

then openocd hangs

i used the tutorial from michael fischer.

i can see nice patterns with my logicanalyzer, but i donÂ´t know to read them.

with the amontec test prog all seems to be well - iÂ´ve contacted amontec for this.

this is the first part of the log (rc78)

Debug: jtag.c:1150 jtag_init():

Debug: ftd2xx.c:887 ftd2xx_init(): current latency timer: 2

Debug: ftd2xx.c:977 jtagkey_init(): 80 08 1b

Debug: ftd2xx.c:1034 jtagkey_init(): 82 09 0f

Debug: ftd2xx.c:143 ftd2xx_speed(): 86 02 00

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1044 jtag_reset_callback():

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1044 jtag_reset_callback():

Debug: openocd.c:98 main(): jtag init complete

Debug: arm7_9_common.c:649 arm7_9_assert_reset(): target->state: unknown

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 0

Debug: jtag.c:1044 jtag_reset_callback():

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1044 jtag_reset_callback():

Warning: arm7_9_common.c:673 arm7_9_assert_reset(): srst resets test logic, too

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 0

Debug: jtag.c:1044 jtag_reset_callback():

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1044 jtag_reset_callback():

Debug: ftd2xx.c:614 jtagkey_reset(): trst: 0, srst: 1, high_output: 0x01, high_direction: 0x0f

Debug: arm7_9_common.c:712 arm7_9_deassert_reset(): target->state: reset

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 2

Debug: jtag.c:1044 jtag_reset_callback():

Debug: ftd2xx.c:614 jtagkey_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f

Debug: openocd.c:102 main(): target init complete

Debug: openocd.c:106 main(): flash init complete

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

Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 3

Debug: jtag.c:1044 jtag_reset_callback():

Warning: jtag.c:986 jtag_read_buffer(): value captured during scan didn’t pass the requested check: captured: 0f check_value: 01 check_mask: 0f

Debug: arm7_9_common.c:613 arm7_9_poll(): DBGACK set, dbg_state->value: 0xffffffff

Debug: embeddedice.c:251 embeddedice_write_reg(): 0: 0x00000005

Debug: embeddedice.c:251 embeddedice_write_reg(): 12: 0x00000000

Debug: arm7_9_common.c:899 arm7_9_debug_entry(): target entered debug from Thumb state

Warning: jtag.c:986 jtag_read_buffer(): value captured during scan didn’t pass the requested check: captured: 0f check_value: 01 check_mask: 0f

Debug: arm7_9_common.c:903 arm7_9_debug_entry(): r0_thumb: 0xffffffff, pc_thumb: 0xfffffff5

Debug: arm7_9_common.c:926 arm7_9_debug_entry(): target entered debug state in System mode

Debug: arm7_9_common.c:937 arm7_9_debug_entry(): thumb state, applying fixups

Debug: arm7_9_common.c:967 arm7_9_debug_entry(): entered debug state at PC 0xffffffef

Debug: target.c:439 target_call_event_callbacks(): target event 0

Debug: arm7_9_common.c:775 arm7_9_halt(): target->state: halted

Warning: arm7_9_common.c:779 arm7_9_halt(): target was already halted

Info: server.c:67 add_connection(): accepted ‘telnet’ connection from 0

Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1

Warning: jtag.c:986 jtag_read_buffer(): value captured during scan didn’t pass the requested check: captured: 0f check_value: 01 check_mask: 0f

Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1

…

i tried other speed values, pullup / pulldown res.

rc62 and rc78 version

nothing changes.

thanks fo any hints

Dominic · July 31, 2006, 5:27pm

Hello Martin,

revision 79 provides two new configuration commands:

ntrst_delay

nsrst_delay

They allow you to specify how long the OpenOCD should wait after deasserting a reset line before JTAG communication is attempted. The reset circuitry of the Ethernut might keep the reset asserted a bit longer, and the OpenOCD tries communicating via JTAG while the target is still being held in reset.

If this doesn’t help let me know, and I’ll have a closer look at the Ethernut schematics and the Atmel ARM they’re using.

Btw., does anyone know if the content of the CPLD is documented? The reset signal from the JTAG interface seems to go through the CPLD.

Regards,

Dominic

AMONTEC · July 31, 2006, 6:03pm

Hello Martin,

Please let me know if the r79 did not help.

If not, could you please put your logic analyzer between the CPLD and the processor and trigg on srst and catch trst srst TCK TMS TDI TDO processor signals.

Also, I can re-write VHDL code for the CPLD to do some other tests.

Best regards,

Laurent

Martin_Ludwig · August 1, 2006, 8:48am

thank you dominic and laurent,

iÂ´ll try to get the rc79.

i think i must compile it by myself ?

try to do this

(i have only the executables 62 and 78 from michael fischer)

Martin_Ludwig · August 1, 2006, 5:26pm

Hello Dominic,

michael fischer puts a build of the rc80 on his site. (thanks to him)

(i wasnÂ´t able to compile it by myself. cygwin autoconf ?)

In the source i see that the params are named

jtag_ntrst_delay … (hope iÂ´m right)

i use them in the #interface section of the cfg file.

things changed when i put in a really huge value 100000.

(lesser values have no effect)

openocd starts quickly without an error and in telnet i can control the arm-cpu. halt , reg , resume and so on and i can watch the results in my teraterm window (output of my testprog in the board).

Really nice, but i canÂ´t believe that the values are milliseconds. (but it works !)

but now iÂ´ve discovered the next problem with insight.

insight starts, and when i press the run button i can see in the

openocd window :

add_connection (): accepted gdb-connection from 0

gdb_get_packet(): ignoring character 0x0

gdb_get_packet(): ignoring character 0x8

gdb_get_packet(): ignoring character 0x0

gdb_get_packet(): ignoring character 0x7f

and so on

after some cykles insight showÂ´s

couldnÂ´t reset the board.

any idea what iÂ´m doing wrong ?

thank you for your effort

Martin

Dominic · August 1, 2006, 5:49pm

Hello Martin,

of course you’re right. I intended to specify the time in ms, but the sleep function i’m using takes us. I’ll fix that in the next svn version.

I’ll have a look at your Insight problems tomorrow. What toolchain did you use (winarm, gnuarm, …), and what version?

Regards,

Dominic

Martin_Ludwig · August 2, 2006, 7:04am

Hello Dominic,

i use guarm 4.1.0 under W2000

arm-elf-gcc 4.1.0

arm-elf-gdb 6.4.0

arm-elf-insight 6.4.0

best regards

Martin

Martin_Ludwig · August 2, 2006, 5:05pm

Hello Dominic,

i made a test with insight

and add the last three lines to the gdb file

target remote localhost:3333

monitor reset

monitor sleep 500

monitor poll

monitor soft_reset_halt

monitor arm7_9 sw_bkpts enable

monitor mww 0xFFE00000 0x1000213D

monitor mww 0xFFE00004 0x20003E3D

monitor mww 0xFFE00020 0x00000001

monitor mdw 0xFFE00000 1

monitor mdw 0xFFE00004 1

break main

load

continue

then i can debug.

All seems well but after some step commands

openocd hangs

i must use the taskmanager to kill the process.

any idea

best regards

Martin

Martin_Ludwig · August 8, 2006, 7:51am

i made a few tests more last days.

different OS XP / 2000. Installation on the maschine itself not in a vmware.

always the same problems.

the newly build rc82 has a new problem : no telnet no gdb connection possible.

the only thing that has not been tested is a slow pc. my test-psÂ´s are from 2 upto 3 GHz Pentium / AMD with 2 GB Memory. May it depend on this ?

i will look for an old pc to test.

best regards

martin

Martin_Ludwig · August 17, 2006, 4:37pm

Hallo,

iÂ´ve made a few tests more

when debugging openocd V86 on windows os i can

see that, after some telnet step commands - number is random

(same happens when i use insight)

openocd hangs in a call to FT_read in function ft2232_read.

FT_read from the FTD2XX.DLL never comeÂ´s back.

parameters to the call seemÂ´s to be correct.

i use the dll from amontec and the newest one from ftdi. allways the same.

it appears under different os w2k, xp prof and different machines

is anyone here who has an idea.

Martin

mifi · August 17, 2006, 5:08pm

Hello Martin,

strange idea:

Have you test it with an USB2.0 hub too, between the PC and JTAGkey?

Best regards,

Michael

AMONTEC · August 17, 2006, 6:50pm

Martin,

GROUND LOOP ! Verify !

Do you have a laptop?

If yes, could you please try to run your laptop on batery and try to debug your target.

Other question:

Do you have a stable regulated VREF on the pin 1 of the 20-pin-header of the Amontec JTAGkey ?

Do you have the ground connected to pin 20 of the 20-pin-header of the Amontec JTAGkey ?

Regards,

Laurent

http://www.amontec.com

Martin_Ludwig · August 17, 2006, 9:15pm

Thank you both for your hints,

i will try tomorrow.

i have a laptop too and in the beginning i use it for my tests. i donÂ´t know

if i have used it with battery only. i will check it.

should it be so easy ? the old ground loop problem like in my early days building power amplifiers ?

ethernut board power is a wall power supply, so where can be the loop ?

as i see the circuit of ethernut it seems to be a stable power, but i will look at it with my scope again.

i wonder why the amontec demo prog works maybe iÂ´ve tested not often enough.

i wonder too why the FT-read doesnÂ´t come back. i think in every communication-routines there must be a timeout.

the good of this is that iÂ´ve learned a lot about cygwin, svn

best regards

Martin

Martin_Ludwig · August 18, 2006, 5:08pm

hello,

problem still remains. has nothing todo with ground loop. iÂ´ve tested with my laptop with battery mode.

Another test with usb hub - same but seems to be more instable.

iÂ´ve measured the signals with logicanalyzer and a good storage scope (some ns max resolutions).

signals are allways clear - a bit noisy like in all digital pcb small spikes with 20 mV on the lines.

For the moment i give up - think next week i will buy a wiggler and a parport-card for my pc to continue the tests with it.

best regards

martin

i will never give up and i will never surrender.

Martin_Ludwig · August 26, 2006, 11:14am

Hello

next step in my jtag adventure.

iÂ´ve got an olimex wiggler adpater and - all went well with my equipment.

(i must use another pc because the adapter needs a legacy parport)

First time i can see a stable debugging system with insight but even slow.

Problem with insight : that i canÂ´t start it without the commands

break main

load

continue

in the cfg file

is solved by the lastest version out of YAGARTO (thanks to michael). With this i can use the run Button and it works fine.

On the same maschine - same kabels, same testboard, same software i try again to use amontec jtagkey. problems are still there !

I only use telnet but the same in insight -

After some STEP commands openocd hangs due to the never come back

FT_read from the ftdi driver.

With my analayzer i can see that on the TMS line sometimes a positiv glitch (~1 Âµs) appears exactly at the down-edge of TCK and when TDI

even has a down edge in the same moment. I donÂ´t know if the problem

may append on this, but it is the only difference between the puls-diagramms parport / usb. The timing of the glitch doesnÂ´t append on the speedvalue in openocd.

i think i will send it back to amontec for testing, maybe the adapter has

a problem.

because i must use an usb-adapter (wiggler was only for testing) in future

i need a solution for this.

BTW has anyone tested the olimex-usb adapter. iÂ´ve seen the cfg file

in the newest openocd release.

regards

martin

AMONTEC · August 28, 2006, 5:10am

Hi Martin,

This is certainly not a glitch but a software issue in the ft2232 code.

1us is not a glitch for JTAGkey but a software pulse, your JTAGkey is working successfully.

How many tck rising edges do you have while your TMS stays in the pulse 1us ?

Is the number of steps the same before the 1us pulse is generated (all time)?

Also, could you please sent an view of your timing diagram, with the complet output debug file of the openocd server.

Best regards,

Laurent Gauch

Dominic · August 28, 2006, 9:28am

Glitches on the falling edge of TCK shouldn’t cause problems. IIRC, I’ve seen these myself on the FT2232. The JTAG TAP controller samples signals on the rising edge of TCK, and expects them to change on the falling edge.

Of course, TCK shouldn’t have a rising edge during the TMS glitch - but I guess that’s what you’re seeing?

The Olimex ARM-USB-OCD is very similar to the JTAGkey, as it uses the same controller (FT2232), and should behave exactly the same way. The only differences are in the way reset signals are handled.

Are you able to compile the OpenOCD yourself? Making testing builds for windows is inconvenient for me, as I only run Linux, so it would speed up solving your problem if you try some changes yourself.

There’s still debug code in the FT2232 driver that’s just commented out, but can be enabled with the DEBUG_USB_COMMS and DEBUG_USB_COMMS #defines in ft2232.c. Additional debug information can be enabled in jtag.h by uncommenting the #define for DEBUG_JTAG_IO.

If possible, it would be nice if you could fetch the latest sources from SVN (svn checkout http://svn.berlios.de/svnroot/repos/openocd/trunk), make the changes to ft2232.c and jtag.h, and then compile the OpenOCD:

./bootstrap

./configure --enable-ft2232_ftd2xx --with-ftd2xx=/cygwin/path/to/D2XX --enable-parport

make

You’ll need a Cygwin installation and the D2XX driver package from ftdichip.com. Place it in a directory with no spaces, like C:\D2XX, and use a “Cygwin-Path”, like /cygdrive/c/D2XX, not the Windows notation.

Let me know if you need help with comiling the OpenOCD.

Regards,

Dominic

Martin_Ludwig · August 28, 2006, 4:29pm

Hello Dominic,

i had done it some days ago with the rc86 and do a bit of modern debugging (printfÂ´s in the code) .

With this i had seen that it always hangs in a call to the FTRead function from

the ftdi dll after some step commands with telnet.

i wonder why the function never comes back - because even if an error occurs there must be a timeout. with wiggler all is ok.

mysterious thing.

best regards

Martin

Dominic · August 28, 2006, 5:06pm

Could you run again with the above mentioned defines enabled, and send the resulting logfile (run with “-l -d ”) to Dominic.Rath gmx.de?

That debug output should contain every command sent to the FT2232, allowing me to see whether there’s a leftover bug in the OpenOCD code.

Regards,

Dominic

mifi · August 28, 2006, 6:27pm

Hello Martin,

should I compile a DEBUG version of OpenOCD for windows

for you?

Best regards,

Michael

Topic		Replies	Views
OpenOCD and Amontec JTAGKey on Linux MicroMod arm-lpc	3	2445	November 28, 2006
tms470, Amontec JTAGkey and OpenOCD MicroMod arm-lpc	18	8973	June 13, 2007
Openocd STR912 JTAG key MicroMod arm-lpc	0	1109	January 28, 2008
Problems communicating Amontec JTAG key. MicroMod arm-lpc	3	1353	February 23, 2011
Amontec JTAGKey + STM32 + OpenOCD = No go MicroMod arm-lpc	0	1044	May 1, 2012

OpenOCD and Amontec JTagkey and ARM7 not working

Related topics