tms470, Amontec JTAGkey and OpenOCD

I am trying to use a Amontec JTAGkey to connect to a TMS470 ARM processor.

I am using openocd-2007re141.

when trying to connect I receive the following(first line types, others from log file):

Info:       openocd.c:86 main(): Open On-Chip Debugger (2007-04-16 19:30 CEST)
Warning: arm7_9_common.c:685 arm7_9_assert_reset(): srst resets test logic, too
Error:   armv4_5.c:186 armv4_5_mode_to_number(): invalid mode value encountered
Error:   arm7_9_common.c:1019 arm7_9_debug_entry(): cpsr contains invalid mode value - communication failure
Error:   target.c:1137 handle_target(): couldn't poll target, exiting

The debug log file contains:

Debug:   jtag.c:1335 jtag_init(): -
Debug:   ft2232.c:1242 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'jtagkey' layout (0403:cff8)
Debug:   ft2232.c:1331 ft2232_init_ftd2xx(): current latency timer: 2
Debug:   ft2232.c:1597 jtagkey_init(): 80 08 1b
Debug:   ft2232.c:1655 jtagkey_init(): 82 09 0f
Debug:   ft2232.c:249 ft2232_speed(): 86 03 00
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:1220 jtag_examine_chain(): JTAG device found: 0x3100e02f (Manufacturer: 0x017, Part: 0x100e, Version: 0x3
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   openocd.c:104 main(): jtag init complete
Debug:   embeddedice.c:218 embeddedice_read_reg_w_check(): 4
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST released
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   arm7_9_common.c:658 arm7_9_assert_reset(): target->state: unknown
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Warning: arm7_9_common.c:685 arm7_9_assert_reset(): srst resets test logic, too
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   ft2232.c:947 jtagkey_reset(): trst: 1, srst: 1, high_output: 0x00, high_direction: 0x0f
Debug:   ft2232.c:947 jtagkey_reset(): trst: 1, srst: 1, high_output: 0x00, high_direction: 0x0f
Debug:   arm7_9_common.c:724 arm7_9_deassert_reset(): target->state: reset
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST released
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   ft2232.c:947 jtagkey_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f
Debug:   openocd.c:108 main(): target init complete
Debug:   openocd.c:112 main(): flash init complete
Debug:   openocd.c:116 main(): NAND init complete
Debug:   openocd.c:120 main(): pld init complete
Debug:   gdb_server.c:1347 gdb_init(): gdb service for target arm7tdmi at port 3333
Debug:   embeddedice.c:218 embeddedice_read_reg_w_check(): 1
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST released
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   arm7_9_common.c:622 arm7_9_poll(): DBGACK set, dbg_state->value: 0x9
Debug:   embeddedice.c:314 embeddedice_write_reg(): 0: 0x00000005
Debug:   embeddedice.c:314 embeddedice_write_reg(): 12: 0x00000000
Debug:   arm7_9_common.c:991 arm7_9_debug_entry(): target entered debug from ARM state
Error:   armv4_5.c:186 armv4_5_mode_to_number(): invalid mode value encountered
Error:   arm7_9_common.c:1019 arm7_9_debug_entry(): cpsr contains invalid mode value - communication failure
Error:   target.c:1137 handle_target(): couldn't poll target, exiting

The config file I’m using looks like:

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey A"
ft2232_layout jtagkey
#ft2232_layout usbjtag
ft2232_vid_pid 0x0403 0xcff8

jtag_speed 3
jtag_nsrst_delay 500
jtag_ntrst_delay 500

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

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#target configuration
daemon_startup reset
#target  
#target arm7tdmi
target arm7tdmi big run_and_halt 0 arm7tdmi-s_r4

run_and_halt_time 0 30

#working_area 0 0x40000000 0x40000 nobackup

#flash configuration
#flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 12000 calc_checksum
#flash bank cfi 0x80000000 0x400000 2 2 0

I have connected to the board using a J-Link ARM using the IAR tools.

I suspect I’ve made a mistake in the config file.

Could someone help me correct my error(s).

Thanks.

hi.

I just had a problem that generated a" CSPR contains invalid mode value" and changing the jtag speed from 1 to 10 fixed it for now.

Regards,

JD

Hi,

Changing the jtag speed did not make a difference for me.

However I have more hints.

I have 3 boards in front of me.

Board 1 is a IAR demo board with a TMS470R1B1M.

Board 2 is our board also with a TMS470R1B1M.

Board 3 is our board with a TMS470R1A128.

The Jlink works with all three boards.

The JTAGkey connects with the TMS470R1A128 but not with the TMS470R1B1M.

Has anyone here used the TMS470R1B1M?

Thanks in advance.

Hi,

Same schematic for your board 2 and board 3 ?

If not, what is the differences between the boards, thinking pull-up / pull-down resitors on SRST and TRST signal. On-board power-on reset circuit …

The TI TMS470R1x have the same on-chip ARM7 core, with the same JTAG interface.

Laurent

Hi,

I’ve examined the schematics boards 2 and 3.

Both have pull ups on TCK, TMS and TDI.

Both have a pull down on TRST.

All pull up / pull downs are 10K.


The power on resets to the processor are similar.

Hi,

I checked the datasheets for tms470r1a128 and tms470r1b1m but couldn’t find a difference w/ regard to debugging. You could try with a drastically decreased JTAG frequency, use a jtag_speed setting of 50 or so.

If that doesn’t help please send a complete log file (run with “-d -l log.txt”) to Dominic Rath gmx de

Regards,

Dominic

Dominic,

Increasing the jtag_speed didn’t help.

I have sent both my config file and the log file output to you as requested.

Thanks

Mark

Hi,

How is the SRST connected to the power-on reset circuit → pull-up / pull-down ? Note the SRST from Amontec JTAGkey + OpenOCD is open-drain → a pull-up is needed on SRST (Pull-down will not works, since only zero will be driven).

After what:

try

jtag_speed 30

jtag_nsrst_delay 2000

jtag_ntrst_delay 2000

If this not help, the next step should be to take traces of TCK SRST TRST trigging SRST.

Take the trace with Board 1 and JLINK and take a second trace (same setup) with Amontec JTAGkey.

Laurent

http://www.amontec.com

Hi,

Before checking the JTAG IOs, please verify the Power signal Vref and GND.

You MUST have :

  • a regulated Vref (1.5V to 5.5V) from your board to the pin 1 of the Amontec JTAGkey (regulated means : no serial resistors between the on-board power regulator and the pin 1 of the Amontec JTAGkey).

  • Green led of Amontec JTAGkey must be ON.

  • a strong GND Ground on pin 20 of the Amontec JTAGkeyl

Let us know.

Laurent

http://www.amontec.com

Hi,

JTAG pin 1 and 2 are connected to 3.3V.

JTAG pins 4,6,8,10,12,14,16,18,20 are all tied to GND.

JTAG pin 11,15,17 and 19 are open.

The Green LED is ON.

When I run openocd the other LED flashes once.


The longer delays on nsrst and ntrst do not make a difference.


None of the three boards I’m using has the JTAG nRST line connected to the tms470r1b1m. Should it be? The example schematics we used did not show it connected.

Hallo Mark,

thanks for sending the log. Everything seems to be fine until the OpenOCD tries to halt the target.

I just realized that there is one major difference between the A128 and the B1M - the latter contains a “JTAG Security Modul”, that is used to prevent unauthorized access to the target. The datasheet has little information how this works, and refers to a "TMS470R1x JTAG Security Module (JSM) Reference Guide (literature number SPNU245), but I couldn’t find that user guide anywhere on TI.com.

I found an IAR support note that tells users to update to a newer version of the J-Link driver if they’re experiencing problems with the TMS470, and Abatron’s BDI2000 also allows the TMS470 to be specified explicitly, unlike other ARM7TDMI targets.

I can only guess that the JTAG security module requires special care to be taken, but without further information this is going to be hard to debug.

Regards,

Dominic

Hi,

So, your physical JTAG connection is good.

Maybe, you are in the case where the firewall of theTMS470R1B1M is blocking the on-chip JTAG debug port.

http://focus.ti.com/lit/ug/spnu243/spnu243.pdf

Laurent

http://www.amontec.com

from http://focus.ti.com/lit/ug/spnu243/spnu243.pdf page 9

<<

Flash programming using TI’s flash utilities. Flash programming is

common during code development and testing. Once the user supplies the

necessary password, the flash utilities disable the security logic before

attempting to program the flash. The flash utilities can disable the code

security logic in new devices without any authorization, since new devices

come with an erased flash. However, reprogramming devices (that already

contain custom passwords) require passwords to be supplied to the flash

utilities in order to enable programming.

laurent

http://www.amontec.com

Dominic and Laurent ,

Interesting… This looks like the problem.

I also found the reference to the JTAG security feature in the TI document SPNU243.

It appears the real information is in SPNU245 with I also could not find online.

I’ve requested a copy from them. We’ll see if they wish to share.

Does this mean that I could put code in the FLASH that would enable the JTAG at reset time? I’ll look at this on Wednesday.

Thanks for the assistance.

Mark.

To all interested,

Placing the following code in flash to execute at boot time unlocks the jtag:

  int dummy;
  dummy = MSMPWL3;
  dummy = MSMPWL2;
  dummy = MSMPWL1;
  dummy = MSMPWL0;

Now after a reset “openocd” connects and “sdk4arm Insight” connects to that.

I also found that using the low level JLink.exe debug interface leaves the device locked.

Doing the following unlocks the device:

First I connect to the device and try to read 8 bytes. It fails.

Then I read the 4 MSMPWL locations.

Lastly I am able to read memory.

SEGGER J-Link Commander V3.70a ('?' for help)
Compiled May 15 2007 21:03:47
DLL version V3.70a, compiled May 15 2007 21:03:44
Firmware: J-Link compiled May 10 2007 13:05:02 ARM Rev.5
Hardware: V5.20
S/N : 10005870
OEM : IARKS
VTarget = 3.196V
JTAG speed: 30 kHz
Found 1 JTAG device, Total IRLen = 4:
 Id of device #0: 0x3100E02F
Found ARM with core Id 0x3100E02F (ARM7)
J-Link>mem 0,8
Could not read memory.
J-Link>mem 0xffec,1
Could not read memory.
J-Link>mem 0xffe8,1
Could not read memory.
J-Link>mem 0xffe4,1
Could not read memory.
J-Link>mem 0xffe0,1
0000FFE0 = 00
J-Link>mem 0,8
00000000 = 0D 00 00 EA 00 00 00 00
J-Link>

Is this something that could be added to openocd in the future?

Mark

Good news from you, Mark.

For resuming: reading the 4 specific password registers (MSMPWL3-0) of the TMS470R1B1M allows to enable the JTAG port.

Great to know!

For me, this is too much “Device Specific” to add this in OpenOCD.

Last question : what value do you read in the 4 password registers “FF FF FF FF” ?

If yes, what happens if you write a password and then do a connect with OpenOCD (reading the 4 register password)? Do you connect → I think you do not?

Regards,

Laurent

http://www.amontec.com

Laurent,

The boot code placed in flash reads 4 words each of 0xFFFFFFFF.

Since I have not set the passkey registers all I need to do is read the MSMPWL3-0 registers. I do not need to write the password back.

The same goes for reading the registers over the JLINK, except the results are not returned over the interface.

Once I do the read I am able to connect with OpenOCD and use Insight.

Mark

Good to know.

Thanks Mark.

Laurent

Hi,

I think that this problem isn’t solved yet because I get the same error, but I use an STR710 ARM.

Debug:   jtag.c:1335 jtag_init(): -
Debug:   ft2232.c:1242 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'oocdlink' layout (0403:6010)
Debug:   ft2232.c:1331 ft2232_init_ftd2xx(): current latency timer: 2
Debug:   ft2232.c:1597 jtagkey_init(): 80 08 1b
Debug:   ft2232.c:1655 jtagkey_init(): 82 06 0f
Debug:   ft2232.c:249 ft2232_speed(): 86 0a 00
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:1220 jtag_examine_chain(): JTAG device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   openocd.c:104 main(): jtag init complete
Debug:   embeddedice.c:218 embeddedice_read_reg_w_check(): 4
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST released
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   arm7_9_common.c:658 arm7_9_assert_reset(): target->state: unknown
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Warning: arm7_9_common.c:685 arm7_9_assert_reset(): srst resets test logic, too
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST asserted
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   ft2232.c:947 jtagkey_reset(): trst: 1, srst: 1, high_output: 0x00, high_direction: 0x0f
Debug:   ft2232.c:947 jtagkey_reset(): trst: 1, srst: 1, high_output: 0x00, high_direction: 0x0f
Debug:   arm7_9_common.c:724 arm7_9_deassert_reset(): target->state: reset
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST released
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   ft2232.c:947 jtagkey_reset(): trst: 0, srst: 0, high_output: 0x06, high_direction: 0x0f
Debug:   openocd.c:108 main(): target init complete
Debug:   openocd.c:112 main(): flash init complete
Debug:   openocd.c:116 main(): NAND init complete
Debug:   openocd.c:120 main(): pld init complete
Debug:   gdb_server.c:1347 gdb_init(): gdb service for target arm7tdmi at port 3333
Debug:   embeddedice.c:218 embeddedice_read_reg_w_check(): 1
Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: TRST released
Debug:   jtag.c:1126 jtag_reset_callback(): -
Debug:   arm7_9_common.c:622 arm7_9_poll(): DBGACK set, dbg_state->value: 0xb
Debug:   embeddedice.c:314 embeddedice_write_reg(): 0: 0x00000005
Debug:   embeddedice.c:314 embeddedice_write_reg(): 12: 0x00000000
Debug:   arm7_9_common.c:991 arm7_9_debug_entry(): target entered debug from ARM state
Error:   armv4_5.c:186 armv4_5_mode_to_number(): invalid mode value encountered
Error:   arm7_9_common.c:1019 arm7_9_debug_entry(): cpsr contains invalid mode value - communication failure
Error:   target.c:1137 handle_target(): couldn't poll target, exiting

The strange thing is that sometimes I can debug, but not every day! I get this error really unpredictable. After I made my board there was this error, then a day later I was really surprised that everything works. And now three days later the error returned.

Also sometimes after the error has disappeared and debugging seems to work, from the OpenOCD side, there is a mysterious behavior. I can load the code via arm-elf-insight but after the continue command the debugger receives a SIGINT because of a breakpoint but, there is nothing. Then the code gets not executed.

My opinion is that these two problems cause each other.

As my previous speaker mentioned, changing the JTAG speed or increasing sleep time doesn’t help at all.