OpenWrt Forum Archive

Topic: Help needed regarding JTAG connection to the router

The content of this topic has been archived on 25 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,
I am trying to JTAG MT7620A router which has 8 pin out of the board. The pins are- TRST, TCK, GND, TMS, TDI, VCC, TDO, RST. My JTAG device is FTDI2332 based, 20 pin, ARM-USB-OCD from Olimex. The router's onboard Vcc pin (jtag) is 3.3v when JTAG debugger Vcc is 5v. Unlike the 20 pin JTAG configuration, there is no Vcc (ref) pin onboard. Should I connect board's Vcc to the JTAG device's Vref pin (pin 2)?

Naturally, I couldn't find any cfg file for this particular SoC. Is there any available openocd cfg file for MT7620A? Any reference or hints on how to carry on? Any suggestion or precaution from your experience?

P.S. I don't wanna burn/damage anything, so I'm not going through trial-and-error. Your suggestions are very important to me.

Hi,

please take a look at these articles to learn more about JTAG:

http://wiki.openwrt.org/doc/hardware/port.jtag
http://www.linux-mips.org/wiki/JTAG

If you want to do it safe, you can leave the VCC pin disconnected and power your board using its main power supply instead.

The following pins must be connected to have a working JTAG interface, all the other pins are optional:

TCK, TMS, TDO, TDI + one ground pin (you can use any of them if there are more than one)

The nTRST pin (if present) is a negative reset pin which means you need to supply logical ones in order to keep your device out of the reset state while having the JTAG interface connected.

If you have a Raspberry Pi, you might want to take a look at my fork of the tjtag-pi project which includes support for the nTRST pin:

https://github.com/kissg1988/tjtag-pi2

It's very simple to use it. I could debrick an old but still working SMC WEBT-G device using this great tool. Here's pic to see how my connection looked like:

http://kepfeltoltes.hu/140921/tjtag-pi_ … es.hu_.jpg

BTW, openocd is a great tool for debugging, it worked with my device (MIPS 4KEc compatible CPU + EJTAG 2.6) so it's very likely you'll be able to use it with yours, too. I don't find the configuration I used, though... sad

I could use the built-in configuration for MIPS32 processors, I just had to slightly modify it to make it work with my device, not sure what and how exactly, though.

Here is a verbose reading about my experience if you are interested (translated by Google):

https://translate.google.com/translate? … edit-text=

(Last edited by geryhun on 12 Dec 2014, 16:20)

geryhun wrote:

BTW, openocd is a great tool for debugging, it worked with my device (MIPS 4KEc compatible CPU + EJTAG 2.6) so it's very likely you'll be able to use it with yours, too. I don't find the configuration I used, though... sad

I could use the built-in configuration for MIPS32 processors, I just had to slightly modify it to make it work with my device, not sure what and how exactly, though.

Here is a terse reading about my experience if you are interested (translated by Google):

https://translate.google.com/translate? … edit-text=

cool! Thanks for sharing your experience. I read the general jtag guidelines from openwrt wiki and from several articles I found online through google. It seems that the relatively well documented jtag device used for openwrt uses parallel port for connection. But I have only Segger J-link and FT2332 based Olimex arm-usb-ocd in my hand. So, it will be convenient to use openocd instead. FYI, my router has MIPS 24Kc based MT7620A SoC.

I connected the olimex jtag to the router and used all the pins. I connected Vcc from the board to the Vcc(ref) pin of jtag, pin 1. Without any configuration, when I connected it to the computer, the router reset and remain halt (or infinite reset loop, not sure), and disconnecting the jtag device made the router start again. On the other hand connecting the j-link to the router showed erratic behavior on the router side (pics @ http://imgur.com/a/oaz7E), nor did jlink software recognize the CPU. So, I am going to stick to olimex jtag as long as I can't figure out the issue with jlink.

I should confess that my hardware debugging experience is limited within ARM series only, and I have little knowledge on MIPS. About openocd - I found MIPS32 files and sample of MIPS 4k debug cfg files. However, I am confused if the default MIPS32 files are going to support MIPS 24Kc. I'm trying to figure that out. A quick search through programming guide for MT7620A and the data sheet didn't help much either. The open resource on EJTAG is so little that it seems, unlike ARM, hardware debugging is optional for MIPS.

I will be glad to share my whole experience in debugging this router once I succeed. But it seems a long journey (or no journey) for me. Any suggestion and help is appreciated. smile

mmrasheed wrote:

I connected the olimex jtag to the router and used all the pins. I connected Vcc from the board to the Vcc(ref) pin of jtag, pin 1. Without any configuration, when I connected it to the computer, the router reset and remain halt (or infinite reset loop, not sure), and disconnecting the jtag device made the router start again.

This seems to be an issue with the TRST line. I'm not an expert of hardware debugging, but I'd advise to check your cabling and also make sure your probe is compatible with the device you are trying to debug. There are many JTAG standards and they are not necessarily compatible with each other. Also, some boards might work with positive logic on TRST line. If that's the case with your device, then simply disconnect the TRST pin (if possible) to see if that helps. What's your router's model anyway?

I should confess that my hardware debugging experience is limited within ARM series only, and I have little knowledge on MIPS. About openocd - I found MIPS32 files and sample of MIPS 4k debug cfg files. However, I am confused if the default MIPS32 files are going to support MIPS 24Kc. I'm trying to figure that out.

I'm pretty sure they will, all modern MIPS-based chips should use the same EJTAG 2.6 standard, meaning that the MIPS32 target config should work with your board, provided that openocd has the correct drivers for the probe you are using.

If all else fails, I'd still recommend to try the JTAG connection with a Raspberry Pi - it's the simplest way to have debug access to your board and it's confirmed to work fine, just make sure your jumper wires aren't too long (10-15 cm at most).

According to this datasheet, your board has an nTRST pin so your probe must keep the processor out of the reset state as explained in my earlier comment.

(Last edited by geryhun on 12 Dec 2014, 19:59)

geryhun wrote:

This seems to be an issue with the TRST line. I'm not an expert of hardware debugging, but I'd advise to check your cabling and also make sure your probe is compatible with the device you are trying to debug. There are many JTAG standards and they are not necessarily compatible with each other. Also, some boards might work with positive logic on TRST line. If that's the case with your device, then simply disconnect the TRST pin (if possible) to see if that helps. What's your router's model anyway?

This board has 2 RST pins marked as- TRST and RST. I just tested the RST pins, and it's actually SRST pin which is holding the system into reset mode. Thanks for mentioning the data sheet, another interesting point that I forgot to mention is- the eJTAG pins are muxed with EPHY_LED pins in this SoC. There is a register (SYSCFG0: System Configuration Register 0) which needs to be configured to change from phy led to jtag mode. I'm not sure at where and how I need to change this register's value.

Interestingly, while searching about ejtag, I came across a debug project ejtagproxy which mentions Olimex arm-usb-ocd as once of the compatible JTAG debugger. On the other hand Segger j-link debugger lists PIC32, which comes with eJTAG v2.6 support. So, that should work with this SoC as well. Only things missing are the config files for the target board in openocd and trial-and-error to make it work.

I am experimenting on a chinese made router, model no. oye-0001 from oyewifi.com. It has MT7620A SoC, 16MB flash and 128 MB RAM.

mmrasheed wrote:

This board has 2 RST pins marked as- TRST and RST. I just tested the RST pins, and it's actually SRST pin which is holding the system into reset mode. Thanks for mentioning the data sheet, another interesting point that I forgot to mention is- the eJTAG pins are muxed with EPHY_LED pins in this SoC. There is a register (SYSCFG0: System Configuration Register 0) which needs to be configured to change from phy led to jtag mode. I'm not sure at where and how I need to change this register's value.

Now, that's a good question. Without JTAG access you are not likely be able to control the CPU at all, except if you have serial access or there are some hardware switches (jumpers, DIP switches etc) on the board. Or, the simplest case, the board has some software flashed by default which can be used to set the register's value. smile

Only things missing are the config files for the target board in openocd and trial-and-error to make it work.

Take a look at this thread:

http://lists.denx.de/pipermail/u-boot/2 … 41384.html

This config is for an Atheros AR71XX SoC but it has the same MIPS CPU model as your device:

ar71xx.cfg:
# Atheros AR71xx MIPS 24Kc SoC.
# tested on PB44 refererence board
 
adapter_nsrst_delay 100
jtag_ntrst_delay 100
 
reset_config trst_and_srst
 
set CHIPNAME ar71xx
 
jtag newtap $CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 1
 
set TARGETNAME $CHIPNAME.cpu
target create $TARGETNAME mips_m4k -endian big -chain-position $TARGETNAME
 
$TARGETNAME configure -event reset-halt-post {
    #setup PLL to lowest common denominator 300/300/150 setting
    mww 0xb8050000 0x000f40a3    ;# reset val + CPU:3 DDR:3 AHB:0
    mww 0xb8050000 0x800f40a3    ;# send to PLL
 
    #next command will reset for PLL changes to take effect
    mww 0xb8050008 3        ;# set reset_switch and clock_switch (resets SoC)
}
 
$TARGETNAME configure -event reset-init {
    #complete pll initialization
    mww 0xb8050000 0x800f0080    ;# set sw_update bit
    mww 0xb8050008 0        ;# clear reset_switch bit
    mww 0xb8050000 0x800f00e8       ;# clr pwrdwn & bypass
    mww 0xb8050008 1        ;# set clock_switch bit
    sleep 1                         ;# wait for lock
 
    # Setup DDR config and flash mapping
    mww 0xb8000000 0xefbc8cd0       ;# DDR cfg cdl val (rst: 0x5bfc8d0)
    mww 0xb8000004 0x8e7156a2       ;# DDR cfg2 cdl val (rst: 0x80d106a8)
 
    mww 0xb8000010 8        ;# force precharge all banks
    mww 0xb8000010 1         ;# force EMRS update cycle
    mww 0xb800000c 0                ;# clr ext. mode register
    mww 0xb8000010 2         ;# force auto refresh all banks
    mww 0xb8000010 8        ;# force precharge all banks
    mww 0xb8000008 0x31             ;# set DDR mode value CAS=3
    mww 0xb8000010 1         ;# force EMRS update cycle
    mww 0xb8000014 0x461b           ;# DDR refresh value
    mww 0xb8000018 0xffff           ;# DDR Read Data This Cycle value (16bit: 0xffff)
    mww 0xb800001c 0x7              ;# delay added to the DQS line (normal = 7)
    mww 0xb8000020 0
    mww 0xb8000024 0
    mww 0xb8000028 0
}
 
# setup working area somewhere in RAM
$TARGETNAME configure -work-area-phys 0xa0600000 -work-area-size 0x20000
 
# serial SPI capable flash
# flash bank <driver> <base> <size> <chip_width> <bus_width>

Except the initialization code, the settings here are pretty generic so they might work for your board, too.

(Last edited by geryhun on 12 Dec 2014, 23:29)

The discussion might have continued from here.