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
