OpenWrt Forum Archive

Topic: JTAG on BCM63138 in TG799vac XTREAM

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

Hi,

Just wondering if anyone has experienced something similar - I have a Technicolor "TG799vac XTREAM" and I'm trying to JTAG it. Unlike the normal TG799vac this one runs a BCM63138 SoC with a dual core Cortex A9 ARM CPU and a nice 20pin ARM JTAG header on the board.

I've soldered on some wires and double and triple checked they are correct, and then I've hooked it up to OpenOCD running on a RPI. Strangely, OpenOCD finds nothing on the chain (0x0 response) when only TDO, TDI, TCK and TMS are connected. However, as as soon as I connect TRST (t-reset), it finds the following on the chain:

Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 10 kHz
Info : TAP derp1.dap does not have IDCODE
Info : TAP derp2.dap does not have IDCODE
Info : TAP auto0.tap does not have IDCODE
Info : TAP auto1.tap does not have IDCODE
Info : JTAG tap: auto2.tap tap/device found: 0x800030fb (mfg: 0x07d (Media Vision), part: 0x0003, ver: 0x8)
Info : JTAG tap: auto3.tap tap/device found: 0xf7b3a1ff (mfg: 0x0ff (<invalid>), part: 0x7b3a, ver: 0xf)
Error: derp1.dap: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Invalid ACK (0) in DAP response
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Invalid ACK (0) in DAP response
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Invalid ACK (0) in DAP response
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Invalid ACK (0) in DAP response

However, this is strange because it does not actually issue a Reset yet, so it shouldn't be doing any pull-up of TRST - making it odd that this is required to find the chain (unless I've misunderstood when it issues a pull-up).

Anyone have any similar experiences/suggestions? Could JTAG be disabled on the main CPU? Is it normal/an error to discover cpus without any IDCODE?

Further investigation has lead me to my current theory that 2x2 of these JTAG entries are the BCM63138 CPU and the Quantenna dual core 5ghz wifi chip. However, I believe both of them are in some way "locked" for JTAG through some pin in the BGA being pulled high/low or something similar. My reasoning is:

  • Following the traces for TDO, TDI, TMS and TCK leads uninterrupted to some BGA pins on the Broadcom cpu, so I don't believe there are any purposefully interrupted traces to prevent debugging.

  • Other BCM chips are known to have configuration pins that can disable/enable JTAG or change the JTAG mode to eJTAG, etc.

One confusing point is that both TDO and TDI lead to the Broadcom SoC, while I would have expected this to be configured in a "chain" between the Broadcom and the Quantenna SoC.

However for the time being I am stuck as it seems impossible to find the Data Sheet for BCM63138 as Broadcom keeps these locked up under NDA tighter then Hillary's emails.

(Last edited by eastwind on 4 Jul 2017, 15:27)

The discussion might have continued from here.