Re: [Openocd-development] Incorrect chain detection for SoC...

[Georg A. <ac...@in...>]

On Thu, Sep 25, 2008 at 11:05:39PM -0400, Duane Ellis wrote:
> Georg Acher wrote:
> >Hi,
> >I'm currently working on a settop-box chip from Conexant. It contains two
> >ARMs, a 1176 and a 926. The 1176 is the one I'm targeting for flashing over
> >JTAG (no debugging or other fancy stuff).
> >  
> Sounds kind of neat.
> 
> Have you used any other JTAG tools with this chip? specifically "urjtag"
> It might do something different - and print some messages out a bit 
> different.

I used it, and there's a difference: At least it detects three devices at
the end of the chain correctly:

IR length: 21
Chain length: 5
Device Id: 00100000100100100110000000100111 (0x0000000020926027)   Cnxt 926
  Unknown manufacturer!
Device Id: 00101011100100000000111100001111 (0x000000002B900F0F)   Arm ETB
  Manufacturer: ARM
Cannot open /usr/local/share/urjtag/arm/PARTS
  Unknown part!
Device Id: 00010111101101110110000000100111 (0x0000000017B76027)   Cnxt 1176
  Unknown manufacturer!
Device Id: 0 (0x0000000000000000)                                  ? 
Device Id: 00010010010001010000000000100111 (0x0000000012450027)   Security stuff
  Unknown manufacturer!
Error: Unable to detect JTAG chain end!
chain.c(133) Part 0 without active instruction
chain.c(184) Part 0 without active instruction
chain.c(133) Part 0 without active instruction

The last two devices are still strange (swapped according to the Lauterbach
output) and shifted still by one bit. But maybe the shift is actually a
problem in the Lauterbach tool, as the manufacturer should be 13 and 27
makes no sense here.

But this lead me to the conclusion that the wiggler parport has no analog
problems (aside from the perfectly digital levels at the scope). So I've
looked into jtag/bitbang.c and read that comment in bitbang_scan():

" Because there is no way to read the signal exactly at the rising edge, read
  after the rising edge."

Sounds strange to me. If you want to read the value of a signal changing
with a rising clock edge, the only reliable way is to read it *before* the
edge.

So I moved the "if (type != SCAN_OUT) {}" to the beginning of the loop
(before the clock change), and now it looks exactly like urjtag:

0x20926027 (Manufacturer: 0x013, Part: 0x0926, Version: 0x2)
0x2b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
0x17b76027 (Manufacturer: 0x013, Part: 0x7b76, Version: 0x1)
Device does not have IDCODE
0x12450027 (Manufacturer: 0x013, Part: 0x2450, Version: 0x1)
Device does not have IDCODE
<hundreds of other such devices snipped>

Better, but the ARM11 detection still doesn't work :-(

arm11_in_handler_SCAN_N(): 'arm11 target' JTAG communication error SCREG SCAN OUT 0x00 (expected 0x10)

So the quest continues... 

But maybe the wrong order of the read is the cause for the problems that
exist with the mx31 and parport adapters.

-- 
         Georg Acher, ac...@in...         
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias