OpenOCD and Amontec JTagkey and ARM7 not working

Development Boards MicroMod
21

Hi Martin,

I receiving your diagram view of your JTAG signal.

Also, I can confirm you the 1us pulse is only present on the falling edge of the tck → this will not affect the TAP of your processor.

Your JTAGkey is working perfectly !

(Note we, at Amontec, have tried to generate million of tck without triggering any spike on TMS nor TDI around a tck rising-edge!)

  1. Do you have try to run the JTAGkey with the JTAG frequency speed at 6 or 7 (close to the speed of a Wiggler) ?

  2. Do you know the output frequency of the on-chip PLL (frequency of the processor)? (The JTAG should stay at 1/6 of the processor frequency no more)

If 1. and 2. are respected, we still have an error in the FT2232 layer of openocd (not in the JTAG layer, since the Wiggler works). Maybe OpenOCD is waiting on a byte from the MPSSE → buffer overflow !

Laurent

http://www.amontec.com

22

Hello Laurent,

thank you.

i´ve tested a wide range of speed factors -

nothing changes- not even the random number of steps

to run in the error. Sometimes 3 Sometimes 50. Bufferoverflow

or such maybe. i have only put to DEBUG Outputs around the

FTRead Call (Modern Debugging). In case of the error i can see the first DEBUG but not the second.

Can be that the function call hangs or openocd itself.

Openocd hangs completely, no telnet no gdb further possible.

After that i must kill openocd with taskmanager.

Best regards Martin

23

thank you all,

i´ve send dominic the log file - hope he find something out.

best regards

martin

24

Hello Martin,

the logfile you’ve sent me looks fine, i.e. the command bytes sent to the FT2232 all make sense. The last buffer is 551 bytes long (like several others before), and requests 20 bytes of readback data (that’s what other similar buffers before returned, so it should be ok) - maybe you could add:

DEBUG("requesting read of %i byte", ft2232_expect_read);

right before the line that wont return

if ((retval = ft2232_read(ft2232_buffer, ft2232_expect_read, &bytes_read)) != ERROR_OK)

and try again until stepping fails. If there’s a bug in the OpenOCD code, the number of bytes requested would be different than what the command bytes specify (I can verify that). That would explain why FT_Read doesn’t return, as the OpenOCD doesn’t use the timeouts - there isn’t much the OpenOCD can do if the FT2232 fails to deliver the requested data, but of course an error message would be nice. I’ll add this in the next version.

If the number of bytes requested in the FT_Read call matches what the command bytes specify, I suspect a bug in the FTDI libraries. Using the debug output, FTDI might be able to help us.

Best regards,

Dominic

25

If you want to try the timeout yourself, add

if ((status = FT_SetTimeouts(ftdih, 5000, 5000)) != FT_OK)
{
	ERROR("unable to set timeouts: %i", status);
	return ERROR_JTAG_INIT_FAILED;
}

after reading the latency timer:

else
{
	DEBUG("current latency timer: %i", latency_timer);
}

Regards,

Dominic

26

Hello Dominic,

i´ve tried this two things.

Openocd want´s to read sometimes 5 or 20 Bytes.

But after some step commands - really random -

when i try the timout code - programm exits then with

an error 0 Bytes read.

it seems as if openocd and the jtagkey doesn´t talk together. sometimes

this happens very early, after starting openocd - somtimes after some steps.

when it happens at start i can see that openocd puts the reset to the device

and after that hangs completely. Openocd doesn´t connect to telnet in that case.

I bought a signalyzer last week and tried it . Same behaviour. So i think it couldn´t be that the amontec key is ill.

I get an older PC < 2 GHz and test - more and quicker errors.

under all circumstances - wiggler works very well.

another question

trying to use the lastest openocd source i made a SVN Update.

Now i can´t compile. Make shows me

…

if gcc -DHAVE_CONFIG_H -I. -I. -I…/… -I…/…/src/gdb -I…/…/src/helper

./src/jtag -I…/…/src/xsvf -g -O2 -MT arm7_9_common.o -MD -MP -MF ".d

m7_9_common.Tpo" -c -o arm7_9_common.o arm7_9_common.c; \

then mv -f “.deps/arm7_9_common.Tpo” “.deps/arm7_9_common.Po”; els

f “.deps/arm7_9_common.Tpo”; exit 1; fi

arm7_9_common.c: In function `arm7_9_execute_sys_speed’:

arm7_9_common.c:542: error: parse error before ‘<<’ token

arm7_9_common.c: In function `arm7_9_execute_fast_sys_speed’:

arm7_9_common.c:579: error: parse error before ‘<<’ token

arm7_9_common.c: In function `arm7_9_read_memory’:

arm7_9_common.c:1658: error: parse error before ‘<<’ token

arm7_9_common.c:1659: error: parse error before ‘)’ token

arm7_9_common.c: At top level:

and so on

the line 542 looks strange to me. any hint how i can make it work again.

best regards martin

27

Hello Martin,

I’m really sorry, but I have absolutely no idea why the OpenOCD fails for you, especially after you’ve tried a different PC. Maybe you could provide more information about your exact setup. OS version, USB interface used, HUB used, cable length, etc.

The compilation errors you’ve seen result from a merge conflict. You’ve made some local changes to arm7_9_common.c before doing the SVN update. The svn client then tried to merge the changes from your local tree with the SVN repository, but couldn’t resolve some conflicts automatically. Open the file, go to the lines and you’ll see both your local changes and those from the repository.

Regards,

Dominic

28

Thank you Dominic,

i will look at the source.

it was the third pc ( nativ) and within the pc´s some more virtual machines.

the only thing i´ve never changed is the tested board, because i ´ve only the one in the moment. but with wiggler it works on all systems very well.

OS is W2K and XP Prof. It seems that openocd and the usb key´s lost connection from time to time.

The ending sequenze in my analyzer looks

allways fine even if the error appears.

best regards

Martin

29

Hello,

long time ago but now the problem is solved.

with the new turtelizer2 and a new ethernut3 board i tried again to debug

with insight.

at first i get the act. openocd source for testing.

installed all under winXP - all worked well.

than i tried under vmware 5.0 and w2k (all my programming i do in vm´s)

get the same problem like last year - sometimes the FT-Read failed to get the amount of bytes needed. seems to be randomly.

I found a function FT_SetLatencyTimer setting the timer always to 2ms.

FTDI dcuments say that other ftdi chips use 16 msec fixed (why??)

i set it to 10 msec and the problem is gone away.

maybe it helps someone else

Martin