[SOLVED] Timeout waiting for SYSCOMP & DBGACK

Ok, I have posted a few times abotu getting openOCD to work. I am getting somewhere but I am still stuck in the sitution whereby I cannot debug at all, or load code into the ram. Only thing I can do is program the chip via SAM-BA. And using the ‘test’ jumper on my olimex board is not only tiresome but I fear there really is a limited number of times I can do this.

Chip: AT91SAM7256

Board: SAM7P256 (olimex)

OpenOCD: 0.3.1

Eclipse with yogarto tools and GDB. (installed successfully using yogarto’s instructions, as well as Jim Lynch’s wonderful tutorial.)

JTAG: JTAGkey clone. (fully tested).

There are many tutorials and examples on the web, both Jim Lynch’s, and one provided by yogarto on his site. However, there is a LOT of variation between config files, openOCD commands, and chip commands. I originally used openOCDre141 and followed Jim Lynch’s instructions to the letter, but gave up when I got the dreaded ‘timeout waiting for SYSCOMP & DBGACK, last DGB_status: 1’ error.

What I have managed to get working:

  • After trying and modifying 5 different config files I settled on a no frills one which simply has the commands for setting up the JTAGkey and the target.
#define our ports
telnet_port 4444
gdb_port 3333

#commands specific to the Amontec JTAGKey
interface ft2232
ft2232_device_desc "Amontec JTAGkey"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
jtag_khz 25
jtag_nsrst_delay 200
jtag_ntrst_delay 200

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only srst_pulls_trst

source [find target/at91sam7sx.cfg]

As you can see, I am only setting up the JTAGkey, with a SLOW speed and calling upon the target config file provided in the openOCD release.

Using command prompt in windows, I can load up openocd with this config file and it connects nicely. I use another command prompt window to start telnet localhost on port 4444, this connects and openocd responds.

Now, just messing about, I can reset, halt, resume, resume at a specific address (at least I assume it does, I have no way of checking), poll, and set/clear lock bits. I have even (!!) manged to load a *.bin image into the flash at 0x00100000. This was a simple LED blink routine from J.Lynch which worked when I repowered the board (note: the reset button must have been disabled.).

Ok, so, looks like I was winning? nope. Any attempt to use the ‘mww’ instruction to write to the config memory fails. For example, after I loaded up openOCD, then telnet, I performed the following:

reset

halt

resume

soft_reset_halt

mww 0xfffffd08 0xa5000001

the last one ‘should’ enable the user reset. I really don’t care if it actually does or not, but I get the ‘timeout waiting for SYSCOMP & DBGACK, last DGB_status: 1’ error again. After that, a reset doesn’t seem to do anything. Any other command causes a horrific crash for openOCD, with telnet spilling its guts all over my screen. These include, halt, resume, soft_reset_halt, poll, almost anything.

Now, looking at all these tutorials, the ‘mww’ command is used to write various bytes to config resgisters on the chip, to disable the watchdog, enable user reset, configure the flash memory controller etc… and these are called inm the ‘reset init’ routine in openOCD’s target config file…as well as the commands one is ‘supposed’ to use in the debug configurations in eclipse (using yogarto GDB). So of course, debugging causes the same problem. It seems any form of ‘init’ code to configure the chip (PLL, watch dog, reset etc…) causes this crash, and I cannot find the problem at all.

I have tried different config files, stripping them down to the basics and the hardware works (the JTAGkey AND a wiggler). But this ‘mww’ instruction seems to just knock the cihp out, leaving it dead hardware until power is cycled.

Its pretty cool using telnet to halt and resume the chip, as well as check out a few status registers, but aside from that, its not happening. Because ‘halt’ and ‘resume’ work, I trust that openOCD really is communicating with the board nicely, but it would be nice to actually be able to do more.

I can give as much detail as you wish, just wasn’t sure whether to include everything (debug logs, software versions, the colour of my t-shirt) in the first post.

BuriedCode.

Hi,

For Amontec JTAGkey dongles, you should use our very new new Microsoft Certified JTAG USB drivers.

Download JTAG key USB drivers from 
http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip

This new JTAG key USB driver is signed by Microsoft Windows WHQL

Microsoft Windows 2000

Microsoft Windows XP 32 bits - 64 bits

Microsoft Windows Server 2003 32 bits - 64bits

Microsoft Windows Vista 32 bits - 64 bits

Microsoft Windows 7 32 bits - 64 bits

Microsoft Windows Server 2008 32 bits - 64 bits

This Driver package is for all Amontec JTAG key dongles

see http://www.amontec.com/jtagkey.shtml

Amontec JTAG key 2nd generation : USB hi-speed 30Mhz JTAG RTCK

Amontec JTAGkey-2P

Amontec JTAGkey-2

Amontec JTAG key 1st generation : USB full-speed 6Mhz JTAG no RTCK

Amontec JTAGkey (-Tiny)

This new driver comes with a lot of new performances and bug fix. This can help to have a better GDB USB JTAG connection using JTAGkey dongles.

Let me know if this work for you.

Regards,

Laurent Gauch

http://www.amontec.com

Note : The 30Mhz JTAG frequency allowed by Amontec JTAGkey-2 and Amontec JTAGkey-2P was successfully used and tested on Atmel AT91SAM7256 EK board.

Download JTAG key USB drivers from

http://www.amontec.com/download/amontec … 091124.zip

Ok, well I have found the problem. And it was hardware…and yes I feel sheeping/foolish.

There was a tiny short in my homemade programmer (we’re talking tiny strand of copper), which meant the reset line was permenantly held low :confused: I only recently added LED’s to it do indicate status, and noticed it was always lit, regardless of what commands were sent. < - idiots don’t always check continuity or shorts.

I should have realised that I get the ‘timeout’ message after a reset-init, which in the ‘init’ routine in the config file, enables the ‘user reset’ - meaning the reset pin is enabled. Thus, once this pin is enabled, and with the programmer holding the pin low, suddenly forces the chip to be held in reset…for as long as the programmer is connected. Any subsequent commands sent to the chip from openOCD don’t get a correct response because…well…its held in reset state.

I should have known it was hardware…bizare problems almost always are. Oh well, lesson learned.

BuriedCode.