SparkFun Forums

[dorian]

Hello guys,

Here's the setup:
* Olimex SAM7-P64 evaluation board (external power supply)
* OOCDLink (home made replica)
* Using OpenOCD (differen versions)

On the board runs the "blinking led tutorial" SW from the Using_Open_Source_Tools_for_AT91SAM7S_Cross_Development_revision_C, what I have flashed with SAM-BA.

OOCD doesnt start correctly.

I have tried several versions (0.1.0, 0.2.0, 0.3.1, 0.4.x RC), compiled by myself with libftdi on two laptops, results are the same.
After OOCD is up, over telnet I can assert "jtag_reset 1 1" and the blinking stops, at least that part works. NSRST goes low, I mean.

Config:

Board:

interface ft2232
ft2232_device_desc "OOCDLink"
ft2232_layout oocdlink
ft2232_vid_pid 0x0403 0xbaf8
ft2232_latency 10
jtag_khz 2

jtag_nsrst_delay 200
jtag_ntrst_delay 200


Target:

at91sam7sx.cfg

Here is the worth part of the log file:

Debug: 416 797 ft2232.c:1676 ft2232_execute_scan(): DR scan, 640 bits, end in DRPAUSE
Debug: 417 797 ft2232.c:1564 ft2232_execute_statemove(): statemove end in RESET
Debug: 418 797 ft2232.c:271 clock_tms(): mpsse cmd=4b, tms_bits = 0x000000ff, bit_count=5
Debug: 419 797 ft2232.c:281 clock_tms(): tap_set_state(DREXIT2)
Debug: 420 797 ft2232.c:281 clock_tms(): tap_set_state(DRUPDATE)
Debug: 421 797 ft2232.c:281 clock_tms(): tap_set_state(DRSELECT)
Debug: 422 797 ft2232.c:281 clock_tms(): tap_set_state(IRSELECT)
Debug: 423 797 ft2232.c:281 clock_tms(): tap_set_state(RESET)
Debug: 424 797 ft2232.c:636 ft2232_send_and_recv(): write buffer (size 94):
Debug: 425 797 ft2232.c:611 ft2232_debug_dump_buffer(): 4b 06 17 39 4e 00 ff 00 00 00 ff 00 00 00 ff 00
Debug: 426 797 ft2232.c:611 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00
Debug: 427 797 ft2232.c:611 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00
Debug: 428 797 ft2232.c:611 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00
Debug: 429 797 ft2232.c:611 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00
Debug: 430 797 ft2232.c:617 ft2232_debug_dump_buffer(): 00 00 ff 00 00 3b 06 00 6b 01 01 4b 04 1f
Info : 431 1125 ft2232.c:680 ft2232_send_and_recv(): inter: 0.000000, inter2: 0.000000 end: 0.328125
Debug: 432 1125 ft2232.c:701 ft2232_send_and_recv(): read buffer (0 retries): 81 bytes
Debug: 433 1125 ft2232.c:611 ft2232_debug_dump_buffer(): 0f 87 c3 e7 0f 00 00 00 7f 00 00 00 7f 00 00 00
Debug: 434 1125 ft2232.c:611 ft2232_debug_dump_buffer(): 7f 00 00 00 7f 00 00 00 7f 00 00 00 7f 00 00 00
Debug: 435 1125 ft2232.c:611 ft2232_debug_dump_buffer(): 7f 00 00 00 7f 00 00 00 7f 00 00 00 7f 00 00 00
Debug: 436 1125 ft2232.c:611 ft2232_debug_dump_buffer(): 7f 00 00 00 7f 00 00 00 7f 00 00 00 7f 00 00 00
Debug: 437 1125 ft2232.c:611 ft2232_debug_dump_buffer(): 7f 00 00 00 7f 00 00 00 7f 00 00 00 7f 00 00 00
Debug: 438 1125 ft2232.c:617 ft2232_debug_dump_buffer(): 00
Debug: 439 1125 commands.c:248 jtag_read_buffer(): fields[0].in_value[640]: 0x0000000FE7C3870F
Info : 440 1125 core.c:915 jtag_examine_chain_display(): JTAG tap: at91sam7s.cpu tap/device found: 0xe7c3870f (mfg: 0x387, part: 0x7c38, ver: 0xe)
Warn : 441 1125 core.c:915 jtag_examine_chain_display(): JTAG tap: at91sam7s.cpu UNEXPECTED: 0xe7c3870f (mfg: 0x387, part: 0x7c38, ver: 0xe)
Error: 442 1125 core.c:915 jtag_examine_chain_display(): JTAG tap: at91sam7s.cpu expected 1 of 1: 0x07c3870f (mfg: 0x387, part: 0x7c38, ver: 0x0)
Warn : 443 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 32 0x0000000f
Warn : 444 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 64 0x0000007f
Warn : 445 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 96 0x0000007f
Warn : 446 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 128 0x0000007f
Warn : 447 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 160 0x0000007f
Warn : 448 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 192 0x0000007f
Warn : 449 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 224 0x0000007f
Warn : 450 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 256 0x0000007f
Warn : 451 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 288 0x0000007f
Warn : 452 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 320 0x0000007f
Warn : 453 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 352 0x0000007f
Warn : 454 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 384 0x0000007f
Warn : 455 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 416 0x0000007f
Warn : 456 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 448 0x0000007f
Warn : 457 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 480 0x0000007f
Warn : 458 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 512 0x0000007f
Warn : 459 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 544 0x0000007f
Warn : 460 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 576 0x0000007f
Warn : 461 1125 core.c:953 jtag_examine_chain_end(): Unexpected idcode after end of chain: 608 0x0000007f

I dont know why I'm receiving that IDCODE.
Why the command "39 4e 00" sends only 78 bytes and not 80 (20x4Byte)?

Also very interesting: before I flashed the blinking led example, with the same setup, holding down the reset button for the whole time and resetting the OOCD I have got the IDCODE 0x3f0f0f0f. After that I couldnt debug.
Now, it doesnt work anymore.

Also very interesting that I keep receiving the message:

Debug: 945 33984 target.c:952 target_call_event_callbacks(): target event 2 (gdb-halt)


So long. Any idea?
Is there any way with OOCD to check if the communication channel (OOCD -> OOCDLink -> SAM7 -> OOCDLink -> OOCD) works?
Can I send somehow commands and read back something to see that the "line" is actually OK? BYPASS?

Thanks for your help in advance.

[buriedcode]

Hi,

I'm sitll a compelte newbie when it comes to openOCD (and arm development for that matter).

I have done similar things to you, using SAM-BA to flash the device (all ok) and still trying to get my DIY jtag programmer to work.

I read that all you have 'really' done with your DIY OOCDlink is change the NSRST line, correct? As this works, its pretty obvious your openOCD software is working, and communicating with your interface hardware.
But, as you're getting different IDcode's, could is be a hardware issue with your DIY OOCDlink?

I'm really a hardware guy, and I have had no end of problems with the JTAG interface....clock skew, noise on the lines, you name it, it seems to be a pain to get 'clean' signals. (not complaining, its just my fault for using long cables, and cheap buffer cheaps). Perhaps I am off the mark here, but have you tried slowing your OOCDlink down to a crawl? slower clocks are less prone to noise and parasitic capacitance, and generally are more reliable. I guess it depends on what levelshifter/buffer your DIY JTAG link has.

That said, it looks like you are getting the same effect, at the same point in communication every time, noise and timing errors would be almost random.

*If* I manage to get my ft2232 link up and running (using 74LVX's....bit dodgy) then I'll see what I come up with as I have the same board.

Edit: just notices you had 'jtag_khz', I'm not sure if that is used by older/later versions of openOCD (I tihnk it is) but perhaps try what I have instead:

jtag_speed 5

My setup is pretty shocking, the total length of the signal (direct from the FT2232D to the target via resistors) must be about 40cm. Which does work, but at very limited speed.

[buriedcode]

Probably sohuld have put this in the above reply as an edit, but I thought I might as well just add this quick.

Just checked the OOCDlink schematic....like mine, it has no buffers. Are you using this with a JTAG cable to target..or a direct 'plugin' ala JTAGkey tiny?

I ask because I have noticed that with every FT2232 project I have done, it doesn't seem very good at driving lines, which is why almost all have a buffer, regardless of whether it requires level shifting or not (the VCCIO can run from 3-5.5V).

It seems to only 'behave' when high speed serial like JTAG/SPI are very very close to the target board...like a direct connection. Even slowing it down doesn't help 'that' much.

Essentially I'm in the exact boat as you, I can set/reset the device, using telnet 'halt' and 'resume', so OpenOCD, the driver, and the FT2232 device is working ok. But any attempt at a clocked transfer comes up with scewed results...only thing I can think off is to usea buffer,like 74HC244 as close as possible to the ft2232, along with some series resistors. That sohuld be able to drive a cable, plus its hysteresis should give good clean sharp transistions, free from noise, along with the current to give good rise/fall times.

I'll edit this post if I have success...as I'm still soldering it up

[dorian]

buriedcode, thanks for the hints.

With code modifications I can set the JTAG speed to 500Hz. It works now, but of course very slow.
Still I can fire up the telnet, issue commands like halt/step/resume.

[dorian]

i had ca. 10cm ribbon cable between board and oocdlink.
following your comments I shortened this to 1cm and separated the lines from each other.

now it "even" works with 2KHz stable.

[buriedcode]

Cool! I still think it sohuld work faster if its that close, but at least you know now that is a cable length problem (otherwise shortening the cable wouldn't have done anything). So its either noise, or cable capacitance.

I'm sure 2kHz may seem annoyingly slow, but hey, at least its running. I resorted to texas instruments voltage translators which claim to be able to run at 50mbps (although I suspect practical limits put this at around 20mbps = 20MHz JTAG clock).

As yours is a 'homemade replica', I can assume it might be a grounding/layout problem. If you have your FT2232 directly on a DIY PCB's, with ground plane and PCB traces, along with good power supply decoupling, I see no reason for the problem. However, if you have the FT2232 mounted on an adapter board, which is mounted on protoboard, the lengths of all the connections add up to give much higher parasitic capacitance, which will slow rise times down significantly.

If you're still having troubles, feel free to message me a pic of your prototype setup

Scott.

[dorian]

Finally I simple desoldered everything from the board, redesigned the circuit by putting one 74HC244 between FT2232 and the JTAG port.
It works now as it should be, stable at 1500kHz.

Problem solved.

Attachments:
OOCDLINKs 6 - board didnt work.
OOCDLinkP - the new one.

Note, these are home made stuffs, requirement is the functionality not the beauty.

[buriedcode]

Good man!

Yeah, buffer gates can work wonders - as can series resistors (preventing over shoot, and adding current limiting). 74HC125, 244, 541 (all tristate) are the first port of call when I build programmers. Maybe not latest tech, but they get the job done.

I found the old standard HC series to be the most reliable, but slightly too slow to work at the full 6Mhz the FT2232's JTAG clock runs at, I don't need that anyway AHC is another pretty good logic family.

Nice boards too I've made prototypes that look far worse lol Beauty means nothing when its epoxied inside a plastic box

Glad to hear its all ok, and thank you for posting results. I have no doubt it will help others with hardware problems

Buriedcode