On 19 February 2015 at 03:16, Grazvydas Ignotas <notasas@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
