On Thu, Oct 31, 2013 at 5:02 AM, Brian Jones <[email protected]>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 sorry you went through that trouble for nothing. The new ftdi adapter
does *not* use libftdi. It uses libusb-1.0, so you need that instead.
Either you already have it or you didn't enable the new ftdi adapter driver
in the configure step. (you should add --enable-ftdi). Also, if you compile
your own, it's almost always better to use the bleeding edge (git HEAD)
instead of the latest release. OpenOCD is a fast moving project and many
fixes and features get merged every week.
>
> 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)
>
So, JRST == TRST then.
>
> I don't have an RTCK pin connected... is this an issue?
>
I don't think it's even exists on your target, so no.
>
> 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".)
>
TRST is an optional pin and OpenOCD doesn't use it by default. It might be
safer for you during testing to simply disconnect it from the target. If
you have it connected it should go to JRST.
nRESET is another common name for nSRST and should be connected to
BusBlaster's "Bi-directional reset pin" (You say TSRST above, that's an odd
name, did you mean nSRST as in the link above?).
If the em357 is anything like the stm32f1x (which the config file suggests)
the reset line (nRESET) is not necessary, as long as any current firmware
isn't using sleep modes or similar. It shouldn't hurt to have it though.
> ----
>
> 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
>
If you connect nSRST, you should add here
reset_config srst_only separate srst_nogate srst_open_drain
connect_assert_srst
to make OpenOCD use it. The last part my require a more recent version than
0.7.0, I don't remember.
> ----
>
> 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
>
If you needed to change this, you probably didn't --enable-ftdi as per
above, so the ftdi adapter driver is not available. Please use the file as
it is, it should not need any changes as long as ftdi is built in.
> #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
