Andreas Fritiofson <andreas.fritiofson@...> writes: > > > > On Thu, Oct 31, 2013 at 5:02 AM, Brian Jones <brianjones738 <at> gmail.com> 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 em357set _CHIPNAME em357set _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_Blasterecho "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 jtagkeyft2232_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 > OpenOCD-devel@... > https://lists.sourceforge.net/lists/listinfo/openocd-devel > Hi all, I am new to OpenOCD. I too need to debug an EM357 and although SiLabs have given me free access to their Ember software they insist on me paying a rediculously high price for an ember ISA3.
Having failed to get a Keil Ulink2 working I have just sent off for an Olimex ARM-USB-OCD-H. Did Brian Jones get it working in the end ? If it is of interest there are some lockup problems with revisions A and B of this silicon. http://www.silabs.com/Support%20Documents/TechnicalDocs/EM35x-Errata.pdf Many thanks in advance John ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
