Hi Brian. TDO may or may not need a pull-up. On all my JTAG connectors, I've added the resistors I mentioned, they're recommended by ARM. As I give ARM higher priority than anyone elses 'opinion', I just do what they say. ;) -But it may work for you with TDO not pulled up.
After reading your reply, I am alost certain that your "all ones" error is caused by that your ~RESET is not connected properly. Your JTAG adapter *MUST* be able to pull reset low, otherwise your chip won't pay attention to what the JTAG adapter is babbling about. 1: Connect a 10K pull-up on your ~RESET on your chip. Connect a 100nF capacitor from ~RESET to GND. 2: Connect your ~RESET (directly) from the chip to ~SRST on your JTAG. 3: Make sure that you've connected both VCC pins on your JTAG connector if you have a 20-pin connector. Connect a 100nF capacitor to GND. 4: Make sure you've connected all the GND pins on your JTAG connector as well, including GND_DETECT if you have one! 5: I believe you're good to go. If it still doesn't work, try adding the TDO pull-up. Love Jens On Thu, 31 Oct 2013 00:02:49 -0400, Brian Jones wrote: > Thank you Jens and Andreas. > > I've compiled v0.7 with the libftdi drivers, per your suggestion. > Took a little while to get a working configuration, as the latest > libftdi package didn't seem to work right out-of-the box so I'm using > 0.19 of libftdi. Anyways... > >>>> I'm hoping you can give me a hand here. I'm trying to debug a >>>> custom board (aka not a standard development board, etc) which has >>>> the EM357 chip. I'm using a Bus Blaster v3c as the OpenOCD >>>> interface, using the config file shown below. >>>> >>>> >>>> I'm connected to JRST, JTMS, JTDI, JTDO, JTCK on the EM357, in >>>> addition to having the Bus Blaster tied to GND and VREF (I think I >>>> have the right test point for this one). >> >> Make sure you have the right signal connected to JRST. The naming >> doesn't suggest whether it resets the TAP (commonly called TRST) or >> the system (commonly called SRST). If you have a voltmeter, you >> should check that VREF is at around 3 V. And continuity test the >> other wires. > > I looked at the EM357 datasheet, and it documents the pins as follows: > JTCK - internal pull-down is enabled > JTDO > JTDI - internal pull-up is enabled > JTMS - internal pull-up is enabled (notes say to set nReset low if > need to force JTAG mode around firmware) > JRST - internal pull-up is enabled (notes say: JTAG reset input from > debugger) > > I don't have an RTCK pin connected... is this an issue? > > I don't have the pull up on JTDO, but the Bus Blaster appears to have > resistors on a ton of lines. However, on further inspection of the > schematic > (http://dangerous-prototypes-open-hardware.googlecode.com/svn/trunk/Bus_Blaster/hardware/BusBlaster-v3c.sch.png), > > it appears these are only 27 Ohm Resistors, and are not pulling. Do > you think I need to add a pull up on JTDO, although most of the other > ones that need it have internals? > > It doesn't mean too much to me, but the Bus Blaster pin compatibility > guide (for v1, probably similar for v3?) is here, and it mentions > nTRST and nSRST: > http://dangerousprototypes.com/docs/Bus_Blaster_v1_buffer_overview#Pin_connection_compatibility. > > Having said that, I'm thinking that the issue may be I'm missing the > nRESET pin. I've found the pinout on the PCB for it now, but don't > know what port on the Bus Blaster to connect it to. Or do I just pull > it up but not connect it? The manual says it is active-low reset > (obviously, based on the name), but it has an internal pull-up. Do I > need a lead to it? If so, which one? (On the Bus Blaster > documentation, it says TRST is an output pin " Reset output" and > TSRST is an input output pin labeled "Bi-directional reset pin".) > > ---- > > Per your suggestions, my config file is now: > > $ cat openocd.cfg > source [find interface/ftdi/dp_busblaster.cfg] > set CHIPNAME em357 > set _CHIPNAME em357 > set _BSTAPID 0x169a862b > source [find target/stm32f1x.cfg] > adapter_khz 10 > > ---- > > I've also had to make a bunch of changes to dp_busblaster.cfg -- it > looks like the calls there are old? > $ cat openocd/scripts/interface/ftdi/dp_busblaster.cfg > # Dangerous Prototypes - Bus Blaster > # > # The Bus Blaster has a configurable buffer between the FTDI FT2232H and the > # JTAG header which allows it to emulate various debugger types. It comes > # configured as a JTAGkey device. > # http://dangerousprototypes.com/docs/Bus_Blaster > > echo "WARNING!" > echo "This file was not tested with real interface, but is assumed to > work as this" > echo "interface uses the same layout as configs that were verified. > Please report your" > echo "experience with this file to openocd-devel mailing list, so it > could be marked" > echo "as working or fixed." > > interface ft2232 > #interface ftdi > #ftdi_device_desc "Dual RS232-HS" > #ftdi_vid_pid 0x0403 0x6010 > ft2232_device_desc "Dual RS232-HS" > ft2232_layout jtagkey > ft2232_vid_pid 0x0403 0x6010 > > #ftdi_layout_init 0x0c08 0x0f1b > #ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400 > #ftdi_layout_signal nSRST -data 0x0200 -noe 0x0800 > > >> Another question is what is running on the CPU. If it's loaded with > some arbitrary firmware, it might put the MCU into sleep mode which > would make it hard or impossible to connect to it while it's running. > The firmware could even reconfigure the JTAG pins to regular GPIOs. > In those cases, the only option is to make sure that SRST (not TRST) > is controlled by OpenOCD so that it can be pulled down during target > examination and halted before the first instruction. More recent > OpenOCD have better support for this procedure. > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
