JTAG-ing - Anyone able to advise?

This is my current bet, a la AzBox requiring R309 to be shorted to
enable the JTAG. My bet for the NMP-1000 is short R209, which is in a
very similar position to R309 on the AzBox. However, to be sure I've
asked QNAP support ...

On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive
wrote:

or perhaps I need to set a jumper somewhere on the
NMP board to make it respond to JTAG
--
================================================== =======
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:

http://epetitions.direct.gov.uk/petitions/71556
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

In uk.comp.os.linux Java Jive wrote:
On 23 Jan 2015 20:48:50 +0000 (GMT), Theo Markettos
wrote:

Try shorting TDI to TDO and see if there's any difference in the error
message. That'll indicate if those two pins are working.

A good idea in principle, but it's difficult to see how to do that in
practice because, unlike the pins on the TUMPA, the pads don't go
through to the other side of the NMP board, and it's very difficult to
trace the connections to a suitable point to place a probe - partly,
although we still have the picture of the board without the header
mounted that I linked previously ...
http://www.macfh.co.uk/Temp/QNAP_NMP-1000_Board.png
... because the header itself obscures important detail, but mainly
because everything is so damnedly small - I can only see anything
worthwhile with a x10 lens, and I'm not prepared to wait for evolution
to grow me an extra pair of hands so that I can hold the board with
one hand, the lens with another, and probes for a resistance meter
with two more ...

You don't need the board connected to short the pins together, it's simply a
check that the JTAG cable is working (it should show 'no devices found' in
that case).

If I connect VTAR - VREF, an LED (red) lights on the TUMPA, and
zJTAG behaves a little differently as outlined in the next paragraph,
but otherwise I don't observe any difference. Likewise RST-nSRST
doesn't seem to make any difference either.

OK, so you do need VREF.

Although zJTAG outputs a message "Please confirm VREF signal
connected!", its behaviour suggests that this is solely so that it can
sense whether the target board is running as it (zJATG) starts to run
- if the board is already switched on it hangs (but confusingly
without a message) waiting for you to switch the board off before it
proceeds to the prompt to switch it on. I suppose this is because it
wants to catch the board as it first boots.

I've now tried, and got not very far with:
OpenOCD v0.8.0 (Linux)
OpenOCD v0.8.0 (Windows 7)
zJTAG (Windows XP)

The results are appended below.

As they are different depending on whether the board is switched off
(ID = all 1s) and on (ID = all 0s) , I hope that means that the JTAG
header connections and the TUMPA itself are correct and working, but
I'm stumped as to how to get a more meaningful response out of the
board itself. Perhaps it's a question of knowing how to configure
OpenOCD correctly, or perhaps I need to set a jumper somewhere on the
NMP board to make it respond to JTAG, but for the moment, I'm
completely stuck.

Worth probing the TDI and TDO pins with a multimeter and seeing whether the
voltages change at all (better a scope if you have one). You should see
TCK, TMS and TDI on the chip change when you run the programming software.

Can anyone help with configuring OpenOCD, and/or particularly the
configuration error message from it ...

-chain-position required when creating target

... for which a search finds nothing really useful?

JTAG chains the devices on the board together - TDO from one goes to TDI of
the next. You need to specify which device in the chain you have. However
it looks like you have either a broken chain, or a chain of zero devices (if
you short TDO to TDI). If the chip is successfully connected you'll have
one or more devices and need to select which one.

It's quite easy to get TDI and TDO mixed up - eg the programmer probably
outputs on TDI since it expects to feed a TDI input on a chip.
If it doubt try them both ways.

You should be able to read the chip ID at least, but from there it's still
an open question whether you can get any further with the open source tools.

Theo

On 28 Jan 2015 18:22:58 +0000 (GMT), Theo Markettos
wrote:

You don't need the board connected to short the pins together, it's simply a
check that the JTAG cable is working (it should show 'no devices found' in
that case).

Yes, the attempt at fetching an ID returns all zeroes ...

C:\TEMP"C:\Program Files\ZJTAG\zjtag.exe" -probeonly

==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================

Set I/O speed to 30000 KHz

USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!

Probing bus ... Done

Detected IR chain Length is 1

CPU Chip ID: 00000000000000000000000000000000 (00000000)
*** Unknown or NO CPU Chip ID Detected ***

*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.

If I connect VTAR - VREF, an LED (red) lights on the TUMPA, and
zJTAG behaves a little differently as outlined in the next paragraph,
but otherwise I don't observe any difference. Likewise RST-nSRST
doesn't seem to make any difference either.

OK, so you do need VREF.

I suspect it's only for zJTAG so that it knows whether the target
device is on or not. OpenOCD appears to be indifferent.

Worth probing the TDI and TDO pins with a multimeter and seeing whether the
voltages change at all (better a scope if you have one). You should see
TCK, TMS and TDI on the chip change when you run the programming software.

Not having got as far as running programming software yet, I tried
doing this as the ID was queried, but, having just the normal quota of
two hands, it was difficult to get keep the probes stable with one
while I ran the software with the other, and the results were
inconclusive.

JTAG chains the devices on the board together - TDO from one goes to TDI of
the next. You need to specify which device in the chain you have. However
it looks like you have either a broken chain, or a chain of zero devices (if
you short TDO to TDI). If the chip is successfully connected you'll have
one or more devices and need to select which one.

It's quite easy to get TDI and TDO mixed up - eg the programmer probably
outputs on TDI since it expects to feed a TDI input on a chip.
If it doubt try them both ways.

Straight through connection ...
TDI - TDI
TDO - TDO
.... gives all 1s as the device ID if there is no power to the target
board, all 0s if there is power, while crossed over ...
TDI - TDO
TDO - TDI
.... gives all 1s as the device ID in both situations.

From which I conclude that in this case straight through is correct,
as that scheme is responsive to change.

You should be able to read the chip ID at least, but from there it's still
an open question whether you can get any further with the open source tools.

Well, I can't the read the chip ID, and, having comprehensively
checked all the connections using the meter, and having been led to
believe by its output that the TUMPA is working correctly, I'm now
reasonably certain that the reason for my failure thus far is the
following ...

On Sun, 25 Jan 2015 14:06:12 +0000, Java Jive
wrote:

or perhaps I need to set a jumper somewhere on the
NMP board to make it respond to JTAG

On Mon, 26 Jan 2015 04:04:26 +0000, Java Jive
wrote:

This is my current bet, a la AzBox requiring R309 to be shorted to
enable the JTAG. My bet for the NMP-1000 is short R209, which is in a
very similar position to R309 on the AzBox. However, to be sure I've
asked QNAP support ...

I've discovered some more, but not as much as I hoped ...

To begin with, QNAP have gone coy on me, no reply to my request for
information about enabling the JTAG despite a follow-up reminder. So
yesterday, I tried shorting R209 and it made ... no difference. I was
gutted, I'd been so sure that it would work, but it appears JTAG is
still not enabled, and still there's no meaningful ID coming back.

However, consequently examining more closely the photos of other
boards which are on the net, for example the most documented seems to
be the Azbox ...
http://img571.imageshack.us/img571/6427/93122218.jpg
.... led me to realise that anyway the tracks from R309 on the Azbox,
which lead off to the area around rows 11 and 12 of the CPU pins, were
very unlikely to go to the same pins as those from R209 on the
NMP-1000, which are further down the side of the processor and go to
the area around rows 15 and 16.

So I searched for a CPU pinout and eventually found this ...
http://hwdb.mipt.cc/SMP8634/Pinout
.... which revealed that the name of pin D11, JTAG_UART#, is the only
one to mention JTAG. Therefore, I think it can be presumed safely
that one of the tracks from R309 on the Azbox PCB goes to this pin.

Consequently, I also presume that if this pin is held to one of Vss or
GND, JTAG is enabled, but if the other, disabled. PCB designers can
thus choose:
:-) Permanently enable
:-( Permanently disable
:-! Enable via jumper or soldered jump

Three questions now remain:
1) To enable JTAG, should D11 be shorted be to Vss or GND?
1) Ought a resistor be used, and if so, what value?
2) Where are the equivalent points on the NMP-1000 PCB?

1 & 2)
Of the various sites quoting this jump for the Azbox, most seem to be
auto-translations of other pages, often themselves auto-translations
of still yet others, making it difficult to work out which page(s)
were originals. Some seem to have derived from a page on a Russian
language German site www.pristavka.de, of which the original no longer
exists. Others refer to this as a possible original ...

https://translate.google.co.uk/trans...yrOAIkveVkkQzZ
QOOobMIrhA
.... and still yet others to a Brazilian page, for which I haven't
found a definite URL. Subsequent generations of translations appear
to be (Spanish & Italian, the second is translated and edited from the
first, which itself derived from pristavka.de) ...

https://translate.google.co.uk/trans...ia-jtag.12602/

https://translate.google.co.uk/trans...ag-t10174.html
.... etc, etc. However, although some versions use resistors to make
the jump, others not, none of these pages mention whether the pin is
being pulled high or low!

However, finally I did discover available on the web a circuit diagram
for Pioneer kit using this CPU (15MB+ download) ...
http://www.go-gddq.com/upload/2014-0...1416497981.pdf
.... and on p46 it shows D11 as being wired as follows (ASCII art
warning - you may need a fixed font for this to display properly):

V+3D
| R1851 = NM (I presume 'not made' = jumper like the Azbox)
---------------------------------0 D11 on CPU
| R1852 = 10k
GND

So it seems D11's being pulled high when the jumper is made, and this
is what enables JTAG functionality on the chip

3) Ooeer missus, can't see a damned thing - not all the connections
go through the board, and the relevant one is within the fourth rank
in from the outer edge, so, even if I removed the heatsink, it would
still be obscured by the body of the CPU itself.

B***er, stuck again.

Time to chase QNAP again ...
--
================================================== =======
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:

http://epetitions.direct.gov.uk/petitions/71556
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

In uk.comp.os.linux Java Jive wrote:
On 28 Jan 2015 18:22:58 +0000 (GMT), Theo Markettos
wrote:
OK, so you do need VREF.

I suspect it's only for zJTAG so that it knows whether the target
device is on or not. OpenOCD appears to be indifferent.

VREF is power to the programmer - it sets up the level shifter to give the
right voltage levels. Without it, you may have no signals.

Straight through connection ...
TDI - TDI
TDO - TDO
... gives all 1s as the device ID if there is no power to the target
board, all 0s if there is power, while crossed over ...
TDI - TDO
TDO - TDI
... gives all 1s as the device ID in both situations.

From which I conclude that in this case straight through is correct,
as that scheme is responsive to change.

Right, sounds like the hardware is mostly OK.

Three questions now remain:
1) To enable JTAG, should D11 be shorted be to Vss or GND?
1) Ought a resistor be used, and if so, what value?
2) Where are the equivalent points on the NMP-1000 PCB?

It's possible. Though normally JTAG ports don't need enabling. They can be
disabled permanently though (sawn off during packaging, or by blowing
internal fuses after programming).

V+3D
| R1851 = NM (I presume 'not made' = jumper like the Azbox)
---------------------------------0 D11 on CPU
| R1852 = 10k
GND

So it seems D11's being pulled high when the jumper is made, and this
is what enables JTAG functionality on the chip

Seems so. JTAG_UART# would imply UART mode when low, so perhaps JTAG mode
when high?

3) Ooeer missus, can't see a damned thing - not all the connections
go through the board, and the relevant one is within the fourth rank
in from the outer edge, so, even if I removed the heatsink, it would
still be obscured by the body of the CPU itself.

The only thing I can suggest is to scope TDI and TDO into the chip and check
that there's good signals on TDI, TCK and TMS, and see if anything comes out of TDO.

Time to chase QNAP again ...

Go easy on them, you don't get a whole lot of support for consumer kit like
this...

Theo

On Sat, 31 Jan 2015 23:28:56 +0000, Java Jive
wrote:

On 28 Jan 2015 18:22:58 +0000 (GMT), Theo Markettos
wrote:

You don't need the board connected to short the pins together, it's simply a
check that the JTAG cable is working (it should show 'no devices found' in
that case).

Yes, the attempt at fetching an ID returns all zeroes ...

C:\TEMP"C:\Program Files\ZJTAG\zjtag.exe" -probeonly

==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================

Set I/O speed to 30000 KHz

USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!

Probing bus ... Done

Detected IR chain Length is 1

CPU Chip ID: 00000000000000000000000000000000 (00000000)
*** Unknown or NO CPU Chip ID Detected ***

*** Possible Causes:
1) Router/Modem is not Connected.
2) Router/Modem is not Powered On.
3) Improper JTAG Cable.
4) Unrecognized CPU Chip ID.

If I connect VTAR - VREF, an LED (red) lights on the TUMPA, and
zJTAG behaves a little differently as outlined in the next paragraph,
but otherwise I don't observe any difference. Likewise RST-nSRST
doesn't seem to make any difference either.

OK, so you do need VREF.

I suspect it's only for zJTAG so that it knows whether the target
device is on or not. OpenOCD appears to be indifferent.

Worth probing the TDI and TDO pins with a multimeter and seeing whether the
voltages change at all (better a scope if you have one). You should see
TCK, TMS and TDI on the chip change when you run the programming software.

Not having got as far as running programming software yet, I tried
doing this as the ID was queried, but, having just the normal quota of
two hands, it was difficult to get keep the probes stable with one
while I ran the software with the other, and the results were
inconclusive.

Have you not considered installing Voice Recognition software?
--
J B Good

Java Jive wrote:

C:\TEMP"C:\Program Files\ZJTAG\zjtag.exe" -probeonly

==============================================
zJTAG EJTAG Debrick Utility v1.0
==============================================

Set I/O speed to 30000 KHz

USB TAP device has been initialized. Please confirm VREF signal
connected!
Press any key to continue... ONCE target board is powered on!

Probing bus ... Done

Detected IR chain Length is 1

CPU Chip ID: 00000000000000000000000000000000 (00000000)
*** Unknown or NO CPU Chip ID Detected ***

Seeing you have fun with your TUMPA reminded me I'd bought a TUMPA-lite,
I recently replaced my old faithful WRT54GS with a WNDR3800, so I don't
mind fiddling with the old router.

Soldered the pins to the TUMPA, got drivers loader for it.

Had difficulty with braid and solder sucker cleaning out the JP1/JP2
headers on the router.

Soldered pins to JP1 for a TTL-level serial port on the router, wired it
up and checked that ttyS0 worked OK for Linux.

Soldered pins to JP2 for JTAG, wired that up and checked zjtag talked to
the router OK.

Did you try the /L1:3 option to set the clock divider? Mine won't
"speak" without it, I also need /cable:3 for a TUMPA-lite, but you
probably can leave that as default.

Yes, that was one of the first things I tried as described up thread,
though in my case the correct parameter seems to be /L1:149.

On Sun, 01 Feb 2015 17:43:59 +0000, Andy Burns
wrote:

Did you try the /L1:3 option to set the clock divider? Mine won't
"speak" without it, I also need /cable:3 for a TUMPA-lite, but you
probably can leave that as default.
--
================================================== =======
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:

http://epetitions.direct.gov.uk/petitions/71556
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Java Jive wrote:

that was one of the first things I tried as described up thread,
though in my case the correct parameter seems to be /L1:149.

OK, I've not been following closely, but your pasted example failure
didn't show the /L1 option.

On 01 Feb 2015 01:14:35 +0000 (GMT), Theo Markettos
wrote:

VREF is power to the programmer - it sets up the level shifter to give the
right voltage levels. Without it, you may have no signals.

Noted for future reference.

Incidentally, I've discovered while re-testing that I wasn't correct
when I said that RST - nsRST had no effect. When that connection is
made, the ID output is always all 1s.

Right, sounds like the hardware is mostly OK.

Yes, I'm pretty well convinced of this now.

So it seems D11's being pulled high when the jumper is made, and this
is what enables JTAG functionality on the chip

Seems so. JTAG_UART# would imply UART mode when low, so perhaps JTAG mode
when high?

Ah that sounds familiar, but I've searched so many pages over this
recently, that my memory, which is aging anyway, is in something of a
whirl. Perhaps it was this I remember, though I think I remember a
more complete description (Azbox again - this contributor apparently
didn't know about R309 although it was mentioned indirectly up thread,
and, yes indeed, it's stated as being pulled high):

http://www.usbjtag.com/vbforum/archi...hp?t-7046.html

"I also remember reading that the jtag header also functions as a
secondary UART for logging. There may be another jumper which
enables JTAG or UART2."

Also ...


http://www.usbjtag.com/vbforum/showt...emium&page= 2
"Please note, after JTAG program the original boot, you need to
remove JTAG to power on the box. When JTAG software is running
and JTAG connected, the box will not power on. That is expected
since JTAG is still talking to the box and thus regular boot up
sequence is not executed."

3) Ooeer missus, can't see a damned thing - not all the connections
go through the board, and the relevant one is within the fourth rank
in from the outer edge, so, even if I removed the heatsink, it would
still be obscured by the body of the CPU itself.

The only thing I can suggest is to scope TDI and TDO into the chip and check
that there's good signals on TDI, TCK and TMS, and see if anything comes out of TDO.

Used to have a second-hand Tektronics 'scope - which I'd swapped for
a cowboy jacket, my local electronics guy was keen on C&W! Although
it had some typical second-hand quirks, it proved useful over several
years, until one time I went to use it and found it dead, and
unfortunately I've never been able to afford to replace it.

Time to chase QNAP again ...

Go easy on them, you don't get a whole lot of support for consumer kit like
this...

If only I could shake, oh ever so gently you may be sure, someone by
the neck until the necessary information was forthcoming! However, to
be fair, they have been very helpful, considering they don't
officially support the device any more.

I'll probably have another try tonight or tomorrow. Bit tired
tonight, walking back up the drive from my afternoon walk, I noticed
that a tree had half-uprooted in the recent gales, we had another last
night, and was threatening the wall between my property and the next,
so I spent an unscheduled frantic hour or two hand-sawing the most
threatening branches off. More to do tomorrow.
--
================================================== =======
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:

http://epetitions.direct.gov.uk/petitions/71556
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Because I was testing shorting TDI & TDO and therefore not constrained
by the speed of the target NMP-1000 board.

On Sun, 01 Feb 2015 17:54:08 +0000, Andy Burns
wrote:

OK, I've not been following closely, but your pasted example failure
didn't show the /L1 option.
--
================================================== =======
UK Residents: If you feel can possibly support it
please sign the following ePetition
before closing time of 30/03/2015 23:59:

http://epetitions.direct.gov.uk/petitions/71556
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html