I been doing a little more investigation as to why reset run, reset init,
and reset halt don¹t work with a jlink dongle and the Atmel AT91SAM9G20-EK
evaluation board. In the case of a simple reset command issued from the
telnet session this causes the following:
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Sep 24 2008 12:00:45
Info : JLink caps 0x19ff7bbf
Info : JLink hw version 80000
Info : JLink max mem block 9736
Info : Vref = 3.229 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f,
part: 0x7926, ver: 0x0)
Info : JTAG Tap/device matched
Info : accepting 'telnet' connection from 0
Error: jlink_usb_message failed with result=1)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f,
part: 0x7926, ver: 0x0)
Info : JTAG Tap/device matched
Error: jlink_usb_message failed with result=1)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : WARNING: unknown debug reason: 0x0
Error: invalid mode value encountered 0
Error: cpsr contains invalid mode value - communication failure
Based on some initial testing it looks like the what the code thinks the
state of the JTAG state machine is verses what it is inside the processor
are two different things following reset.
There are some other relevant details about this board worthy to note.
First this particular board only utilizes the system reset (SRST) signal.
The test reset for the jtag port (TRST) is not physically connected to the
emulator port on the PCB. Without pulling up the datasheet, I am going to
assume therefore that actuation of SRST is also yanking the TRST signal
internally.
In the process of debugging I temporarily commented out the following steps
in jlink_reset:
// if (trst == 0)
// {
// jlink_simple_command(EMU_CMD_HW_TRST1);
// jtag_sleep(5000);
// jlink_end_state(TAP_RESET);
// jlink_state_move();
// }
After recompiling, I was able to get reset run to work properly and not
clobber the J-link afterwards (reset halt and reset init still have other
issues, however).
This is the first time I have really started to dig in the ARM architecture
and there are certainly some holes in my understanding of this family. Can
someone help enlighten me what the intent of this code is and how it plays
into the larger family of ARM processors?
Based on reading through other posts I am quickly starting to realize the
SRST/TRST is a messy thorn with ARM processors and I have no doubt it is
critical to something. Nevertheless understanding the logic behind it, may
help me solve my problem.
Thanks,
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
