Re: Enabling DBGEN signal in GP OMAP3

[Matthijs van Duin <matthijsvanduin@gmail.com>]

On 19 February 2015 at 03:16, Grazvydas Ignotas <notasas@gmail.com> wrote:
> It turns out 050, 054 and 058 (but only them) are actually documented
> in dm3730 manual and are part of Emulation Pin Manager. 058 works as
> you (and the manual) describe, however claiming and enabling EPM
> registers still doesn't enable writing to 030 :(

Ah, bummer.

> OK thanks for all the info. I've tested a spare floating pin by muxing
> it as a GPIO on my dm3730 and it works as you describe, nice.
> Hopefully this also applies to jtag pins there.

At least on the am335x disabling RXEN of the TMS pin rendered JTAG
inoperable, which means it looks like the technique will at least work
there.  I'm now working on a test to see if it really works.  Once
done it shouldn't be too hard to adapt to the dm37xx: the padconf
registers are different obviously, but the bitbang sequence will be
almost the same (just a different ICEPick register), at least if
setting debug-enable on DAP's tap control register suffices. If it
turns out you really need to write to the DAPCTL registers themselves
via JTAG, that will be a bit more work...

> Ok, sounds like I need to find and get rid of that 10k resistor, or
> connect the pad to 1.8V. It's just a shame that there doesn't seem to
> be a way to do it purely in software so that other pandora users could
> have hardware watchpoints.

You can solder-blob a path from nTRST to Vref via other input pads
(which all need to be high, but they should already be pulled up
anyway), as long as you avoid GND and the outputs (TDO and RTCK).
Though I'm not sure that's a good idea considering it looks like
there's a ground plane running between the pads...

Anyhow, I'm currently testing just with nTRST connected to Vref, and
TDO to some GPIO for monitoring.


> If you could share the programming sequence it would be great.

Working on it!

When you manage to get nTRST (and the other all relevant inputs: TMS,
TDI, TCK) high, you can first try simple tests:
(all this should be done by via INPUTENABLE of the pads):
1. nTRST low, TMS and TDI high, toggle TCK a bunch of times (at least
five rising edges) and end with TCK low.
2. nTRST high, TMS low, and start toggling TCK.  If all is well,
sooner or later (possible right away), the processor's RTCK output
should start following TCK.  If this is the case, then you can pretty
much start doing the victory-dance ;-)  When you stop toggling, make
sure you end with TCK low.
3. If you also want to see TDO in action, perform the following
sequence: TMS high, one TCK pulse (high-low), TMS low again, and start
toggling TCK: after two pulses the processor should start driving TDO
and the 32-bit JTAG ID should emerge from it, after which TDO remains
high. To exit data mode and return to idle state again, give two TCK
pulses with TMS high. TDO will go high-Z again (after the first TCK
pulse already in fact).
4. The final pin to test is TDI: repeat step 3, but occasionally
change TDI in between clock pulses. JTAG uses shift registers for
everything, so after outputting the 32-bit JTAG ID it will actually
start repeating the input you provided, but with 32 cycles delay. When
you exit data mode, the JTAG ID register will discard the data you
provided.